据我所知，OAuth 2.0 规范对于
access token令牌可以表示用于检索授权的标识符 信息或者可以以可验证的方式自包含授权信息（即，由一些数据和签名组成的令牌字符串）。为了让客户端使用令牌，可能需要额外的身份验证凭据，这超出了本规范的范围。
访问令牌提供了一个抽象层，用资源服务器可以理解的单个令牌替换不同的授权结构（例如用户名和密码）。这种抽象使得可以颁发比用于获取访问令牌的授权更严格的访问令牌，并且消除了资源服务器了解各种身份验证方法的需要。
根据资源服务器的安全要求，访问令牌可以具有不同的格式、结构和使用方法（例如，加密属性）。 访问令牌属性以及用于访问受保护资源的方法超出了本规范的范围，由配套规范（例如RFC6750）定义。
（强调）
链接的 RFC6750 没有提供更多的细节。有一个 HTTP 响应正文示例，其中显示：
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
这似乎表明 access_token 可以是不透明的 ASCII 文本，例如编码的 JSON Web 令牌 (JWT)
从我的角度来看，JWT-as-access_token 似乎有一些理想的属性：
这是一个众所周知的规范，具有相当广泛的采用度和多种语言的客户端库。
它允许使用经过审查的加密库轻松签名和验证。
因为它可以解码为 JSON，所以它允许我们在令牌本身中包含有关令牌的元数据和信息。
我的问题是：首先，访问令牌是否允许是 JWT？其次，如果规范允许，是否有任何其他考虑因素会使使用 JWT 作为访问令牌成为一个坏主意？
A1：使用 JWT 作为访问令牌是规范所允许的，因为规范不限制其格式。
A2：使用 JWT 作为访问令牌背后的想法是它可以是独立的，以便目标可以验证访问令牌并使用关联的内容，而无需返回授权服务器。这是一个很好的属性，但使撤销变得更加困难。因此，如果您的系统需要立即撤销访问的功能，那么 JWT 可能不是访问令牌的正确选择（尽管您可以通过缩短 JWT 的生命周期来取得很大的进展）。
只要授权服务器和资源服务器就访问令牌的含义达成一致，它们的内容是什么并不重要。因此，您可能遇到问题的唯一原因是您在实现这两个服务器时使用了不同的库或框架。
目前，OAuth 工作组正在开发 OAuth 2.0 访问令牌的 JWT 配置文件：OAuth 2.0 访问令牌的 JSON Web 令牌 (JWT) 配置文件