可能OAuth 2.0访问令牌是JWT吗？
从我所知道的情况来看，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作为访问令牌是一个坏主意？
A1：使用JWT作为访问令牌肯定是允许的，因为规范并没有限制它的格式。
A2：使用JWT作为访问令牌的想法是，它可以自包含，以便目标可以验证访问令牌并使用关联的内容，而无需返回授权服务器。 这是一个伟大的财产，但使撤销更难。 因此，如果您的系统需要立即撤销访问权限，则JWT可能不是访问令牌的正确选择（尽管通过缩短JWT的使用期限可以获得相当大的回报）。
只要授权服务器和资源服务器就访问令牌的含义达成一致，无论其内容是什么。 因此，如果您在实现这两台服务器时使用不同的库或框架，您可能会遇到问题的唯一原因。
链接地址: http://www.djcxy.com/p/8415.html