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

Question

据我所知，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 Token (JWT)

从我的角度来看，似乎将JWT作为access_token具有一些可取的属性：

• 它是一个已知的规范，被广泛采用，并且在许多语言中提供了客户端库。

• 使用经过验证的加密库可轻松进行签名和验证。

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

我的问题是：首先，access token是否可以是JWT？其次，如果按照规范允许，那么是否有任何其他考虑因素会使使用JWT作为access token成为一个坏主意？

- bjmc

Answer 1

A1：使用JWT作为访问令牌是符合规范的，因为规范没有限制其格式。

A2：使用JWT作为访问令牌的思想在于它可以自包含，使得目标系统可以验证访问令牌并使用相关内容，而无需返回授权服务器。这是一个很好的特性，但也使得撤销更加困难。因此，如果您的系统需要立即撤销访问权限的能力，则JWT可能不是访问令牌的正确选择（尽管通过缩短JWT的生命周期，您可以取得相当大的进展）。

- Hans Z.

---

如果发生灾难性事件需要撤销访问权限，您只需更改密码即可，对吗？ - theblang

更改密钥会撤销所有用户的JWT令牌。我认为撤销一个用户的JWT令牌变得更加困难，因为它没有存储在任何地方。 - user1870400

不更改密钥将问题推给密钥分发机制的及时性。 - Hans Z.

现在有一个RFC扩展OAuth2，其中包含一个令牌撤销端点：https://tools.ietf.org/html/rfc7009。还有另一个是一周前发布的，用于令牌内省：https://tools.ietf.org/html/rfc7662。 - odigity

撤销访问权限的诀窍是使用刷新令牌。刷新令牌是由授权服务器在颁发JWT访问令牌时同时提供的，但其生命周期更长，关键是只能用于向授权服务器请求新的访问令牌（无需用户交互）。例如，AS颁发一个持续5小时的刷新令牌和一个持续5分钟的访问JWT。您可以在5分钟内进行请求，而不会有缓慢的AS调用，并有机会每5分钟撤销（当访问令牌过期并且使用刷新令牌向AS请求新令牌时）。 - Rhubarb

我不知道OAuth2是否规定了这一点，但访问令牌旨在在不访问数据库的情况下进行验证，因此只有在验证刷新令牌（包括数据库访问）时才能撤销。 - Andy

Answer 2

只要授权服务器和资源服务器就访问令牌的意义达成一致，它们的内容是无所谓的。因此，唯一可能出现问题的原因是当你实现这两个服务器时使用了不同的库或框架。

- jwismar

Answer 3

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

- CloudPotato