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

【问题标题】：May an OAuth 2.0 access token be a JWT?OAuth 2.0 访问令牌可以是 JWT 吗？
【发布时间】：2015-06-24 23:43:21
【问题描述】：

据我所知，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 作为访问令牌成为一个坏主意？

【问题讨论】：

标签： oauth oauth-2.0 access-token jwt

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

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

【讨论】：

如果您需要在发生灾难性事件时撤销访问权限，您可以更改密码对吗？
更改密码会撤销所有用户的所有 JWT 令牌。我认为撤销一个用户的 JWT 令牌变得更加困难，因为它没有存储在任何地方。
不改密将问题推到密钥分发机制的时效性
现在有一个扩展 OAuth2 的 RFC，带有一个令牌撤销端点：tools.ietf.org/html/rfc7009 另一个是一周前出现的，用于令牌自省：tools.ietf.org/html/rfc7662
吊销的诀窍是使用刷新令牌。刷新令牌由授权服务器与您的 JWT 访问令牌同时提供，但具有更长的生命周期，并且 - 至关重要的是 - 只能在对授权服务器的请求中使用以获取新的访问令牌（无需用户交互）。例如。 AS 发出一个持续 5 小时的刷新令牌和一个持续 5 分钟的访问 JWT。您将获得 5 分钟的请求，没有缓慢的 AS 调用，并有机会每 5 分钟撤销一次（当访问令牌过期并且刷新令牌用于从 AS 请求新令牌时）

【解决方案3】：

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

【讨论】：