Question

据我所知，the OAuth 2.0 specification在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 Token (JWT)

从我的角度来看，似乎JWT-as-access_token具有一些理想的属性：

它是一个已知规范，具有相当广泛的采用率，并且提供多种语言的客户端库。
它允许使用经过审查的加密库轻松签名和验证。
因为它可以解码为JSON，所以它允许我们在令牌本身中包含有关令牌的元数据和信息。

我的问题是：首先，允许访问令牌是JWT吗？其次，如果根据规范是允许的，那么使用JWT作为访问令牌会有什么额外的考虑因素吗？

Answer 1

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

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

Answer 2

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

Answer 3

目前，OAuth 工作组正在为 OAuth 2.0 访问令牌制定 JWT 配置文件：JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

可以将OAuth 2.0访问令牌作为JWT吗？

3 个答案: