1. 引言
原始 OAuth 2.0 Authorization Framework [RFC6749] 规范并未强制规定访问令牌的任何特定格式. 虽然这对许多重要场景仍然完全适用, 但市场使用情况表明, 许多商业 OAuth 2.0 实现选择以资源服务器可直接解析和验证的格式签发访问令牌, 无需授权服务器进一步参与. 在授权服务器和资源服务器不共址, 不由同一实体运行, 或以其他方式被某种边界隔开的拓扑中, 这种方法尤其常见. 在撰写本文时, 许多商业实现使用 JSON Web Token (JWT) [RFC7519] 格式.
许多供应商特定的 JWT 访问令牌共享相同的功能布局, 使用 JWT claim 传达支持一组常见用例所需的信息: 令牌验证, 以 scope 和 entitlement 形式传递授权信息, 携带关于主体的身份信息等. 差异大多局限于用于表示相同实体的 claim 名称和语法, 这表明通过标准化一组通用 claim 和验证规则可以较容易地实现互操作性.
访问令牌与特定信息相关联这一假设并不只出现在商业实现中. OAuth 2.0 系列中的各种规范 (例如 resource indicators [RFC8707], OAuth 2.0 bearer token usage [RFC6750] 等) 都假定访问令牌中存在限定范围的机制, 例如 audience. 与 introspection 相关的一组规范也间接表明, 访问令牌预期会携带或至少关联一组基础信息.
本规范旨在提供一个标准化且可互操作的配置文件, 作为今后专有 JWT 访问令牌布局的替代方案. 除定义一组通用的强制和可选 claim 外, 该配置文件还明确说明授权请求参数如何决定所签发 JWT 访问令牌的内容, 授权服务器如何发布与其签发的 JWT 访问令牌相关的 metadata, 以及资源服务器应如何验证传入的 JWT 访问令牌.
最后, 本规范提供安全和隐私考虑事项, 用于防止在以朴素方式使用 JWT 格式表示访问令牌时可能发生的常见错误和反模式.
请注意: 虽然本文档和 [RFC7523] 都在 OAuth2 框架上下文中使用 JSON Web Tokens, 但这两个规范在意图和机制上均不同. [RFC7523] 定义如何使用 JWT Bearer Token 请求访问令牌, 而本文档描述如何以 JWT 格式编码访问令牌.
1.1. 需求记法和约定
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 只有在以此处所示的全大写形式出现时, 才应按照 BCP 14 [RFC2119] [RFC8174] 中的描述解释.
1.2. 术语
JWT access token: 以 JWT 格式编码并符合本规范所述要求的 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".