OAuth 2.0访问令牌可以是JWT吗？

Question

据我所知，OAuth 2.0规范在访问令牌应该采取什么形式方面非常模糊：

令牌可以表示用于检索授权信息的标识符，或者可以以可验证的方式自包含授权信息（即，由一些数据和签名组成的令牌字符串）。为了让客户端使用令牌，可能需要额外的身份验证凭据，这些凭据超出了本规范的范围。

访问令牌提供了一个抽象层，将不同的授权构造（例如用户名和密码）替换为资源服务器可以理解的单个令牌。这种抽象使得发布访问令牌比用于获取令牌的授权授予更具限制性，并且消除了资源服务器理解各种身份验证方法的需要。

根据资源服务器安全要求，访问令牌可以具有不同的格式、结构和使用方法（例如，加密属性）。访问令牌属性和用于访问受保护资源的方法超出了本规范的范围，由RFC6750等配套规范定义。

（增加强调）

链接的RFC6750没有提供更多的特异性。有一个HTTP响应体示例，显示：

{
       "access_token":"mF_9.B5f-4.1JqM",
       "token_type":"Bearer",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
     }

这似乎表明access_令牌可以是不透明的ASCII文本，例如编码的JSON Web令牌（JWT）

从我的角度来看，JWT-as-access_令牌似乎有一些可取的属性：

>

这是一个已知的规范，具有相当广泛的采用范围和多种语言的客户端库。

它允许使用经过审查的加密库轻松签名和验证。

因为它可以解码为JSON，所以它允许我们在令牌本身中包含关于令牌的元数据和信息。

我的问题是：首先，允许访问令牌是JWT吗？其次，如果规范允许，是否还有其他考虑因素会使使用JWT作为访问令牌成为一个坏主意？

Answer 1

目前，OAuth工作组正在开发OAuth 2.0访问令牌的JWT配置文件：OAuth 2.0访问令牌的JSON Web令牌（JWT）配置文件

Answer 2

只要授权服务器和资源服务器就访问令牌的含义达成一致，它们的内容是什么并不重要。因此，出现问题的唯一原因是在实现这两个服务器时使用不同的库或框架。

Answer 3

A1：规范当然允许使用JWT作为访问令牌，因为规范不限制其格式。

A2：使用JWT作为访问令牌的想法是，它可以是自包含的，以便目标可以验证访问令牌并使用相关内容，而不必返回授权服务器。这是一个很好的属性，但使撤销变得更加困难。因此，如果您的系统需要立即撤销访问的能力，那么JWT可能不是访问令牌的正确选择（尽管可以通过缩短JWT的生存期来实现）。