1. Introduction (简介)

原始的OAuth 2.0授权框架 (OAuth 2.0 Authorization Framework) [RFC6749] 规范并不强制要求访问令牌 (Access Token) 使用任何特定格式. 虽然这对许多重要场景仍然完全适用, 但市场使用情况表明, 许多商业OAuth 2.0实现选择使用一种可由资源服务器 (Resource Server) 直接解析和验证的格式来签发访问令牌, 而无需授权服务器 (Authorization Server) 进一步参与. 这种方法在授权服务器和资源服务器不位于同一位置、不由同一实体运营或以其他方式被某些边界分隔的拓扑中尤其常见. 在撰写本文时, 许多商业实现利用了JSON Web Token (JWT) [RFC7519] 格式.

许多特定于供应商的JWT访问令牌共享相同的功能布局, 使用JWT声明 (Claim) 来传递支持一组常见用例所需的信息: 令牌验证、以作用域 (Scope) 和权限 (Entitlement) 形式传输授权信息、携带关于主体 (Subject) 的身份信息等等. 差异主要局限于用于表示相同实体的声明名称和语法, 这表明通过标准化一组通用的声明和验证规则可以很容易地实现互操作性.

访问令牌与特定信息关联的假设不仅出现在商业实现中. OAuth 2.0系列中的各种规范 (如资源指示符 (Resource Indicator) [RFC8707]、OAuth 2.0持有者令牌使用 (Bearer Token Usage) [RFC6750] 等) 假定访问令牌中存在作用域机制 (Scoping Mechanism), 例如受众 (Audience). 与内省 (Introspection) 相关的规范系列也间接表明访问令牌预期携带或至少与之关联的一组基本信息.

本规范旨在提供一个标准化且可互操作的配置文件 (Profile), 作为专有JWT访问令牌布局的替代方案. 除了定义一组必需和可选的声明外, 该配置文件还清楚地说明了授权请求参数如何确定签发的JWT访问令牌的内容、授权服务器如何发布与其签发的JWT访问令牌相关的元数据, 以及资源服务器应如何验证传入的JWT访问令牌.

最后, 本规范提供了安全性和隐私性考虑, 旨在防止在简单使用JWT格式表示访问令牌时可能发生的常见错误和反模式.

请注意: 尽管本文档和[RFC7523]都在OAuth 2.0框架上下文中使用JSON Web Token, 但这两个规范在意图和机制上都有所不同. [RFC7523]定义了如何使用JWT持有者令牌 (JWT Bearer Token) 来请求访问令牌, 而本文档描述了如何以JWT格式编码访问令牌.

1.1. Requirements Notation and Conventions (需求符号和约定)

本文档中的关键词 "MUST" (必须), "MUST NOT" (禁止), "REQUIRED" (必需), "SHALL" (应), "SHALL NOT" (不应), "SHOULD" (应该), "SHOULD NOT" (不应该), "RECOMMENDED" (推荐), "NOT RECOMMENDED" (不推荐), "MAY" (可以) 和 "OPTIONAL" (可选) 应按照BCP 14 [RFC2119] [RFC8174]中的描述进行解释, 当且仅当它们以全大写形式出现时, 如此处所示.

1.2. Terminology (术语)

JWT access token (JWT访问令牌): 以JWT格式编码并符合本规范中描述的要求的OAuth 2.0访问令牌.

本规范使用OAuth 2.0授权框架 (The OAuth 2.0 Authorization Framework) [RFC6749] 定义的术语 "access token" (访问令牌)、"refresh token" (刷新令牌)、"authorization server" (授权服务器)、"resource server" (资源服务器)、"authorization endpoint" (授权端点)、"authorization request" (授权请求)、"authorization response" (授权响应)、"token endpoint" (令牌端点)、"grant type" (许可类型)、"access token request" (访问令牌请求)、"access token response" (访问令牌响应) 和 "client" (客户端).