2. JWT Access Token Header and Data Structure (JWT访问令牌头部和数据结构)
2.1. Header (头部)
JWT访问令牌必须 (MUST) 进行签名. 尽管JWT访问令牌可以使用任何签名算法, 但推荐 (RECOMMENDED) 使用非对称加密, 因为它简化了资源服务器获取验证信息的过程 (参见第4节). JWT访问令牌禁止 (MUST NOT) 使用 "none" 作为签名算法. 更多详细信息请参见第4节.
符合本规范的授权服务器和资源服务器必须 (MUST) 在其支持的签名算法中包含RS256 (如[RFC7518]中定义).
本规范注册了 "application/at+jwt" 媒体类型, 可用于指示内容是JWT访问令牌. JWT访问令牌必须 (MUST) 在 "typ" 头部参数中包含此媒体类型, 以明确声明该JWT表示符合此配置文件的访问令牌. 根据[RFC7515]第4.1.9节中 "typ" 的定义, 推荐 (RECOMMENDED) 省略 "application/" 前缀. 因此, 使用的 "typ" 值应该 (SHOULD) 是 "at+jwt". 有关防止OpenID Connect ID Token (如[OpenID.Core]第2节所定义) 被实现此配置文件的资源服务器接受为访问令牌的重要性的详细信息, 请参见安全考虑部分.
2.2. Data Structure (数据结构)
以下声明用于JWT访问令牌数据结构.
iss 必需 (REQUIRED) - 如[RFC7519]第4.1.1节所定义.
exp 必需 (REQUIRED) - 如[RFC7519]第4.1.4节所定义.
aud 必需 (REQUIRED) - 如[RFC7519]第4.1.3节所定义. 有关授权服务器应如何根据请求确定 "aud" 值的说明, 请参见第3节.
sub 必需 (REQUIRED) - 如[RFC7519]第4.1.2节所定义. 在通过涉及资源所有者 (Resource Owner) 的许可获取的访问令牌的情况下 (例如授权码许可 (Authorization Code Grant)), "sub" 的值应该 (SHOULD) 对应于资源所有者的主体标识符. 在通过不涉及资源所有者的许可获取的访问令牌的情况下 (例如客户端凭证许可 (Client Credentials Grant)), "sub" 的值应该 (SHOULD) 对应于授权服务器用于指示客户端应用程序的标识符. 有关此场景的更多详细信息, 请参见第5节. 另外, 有关在分配 "sub" 值时不同选择如何影响隐私的讨论, 请参见第6节.
client_id 必需 (REQUIRED) - 如[RFC8693]第4.3节所定义.
iat 必需 (REQUIRED) - 如[RFC7519]第4.1.6节所定义. 此声明标识JWT访问令牌的签发时间.
jti 必需 (REQUIRED) - 如[RFC7519]第4.1.7节所定义.
2.2.1. Authentication Information Claims (认证信息声明)
本节列出的声明可以 (MAY) 在涉及资源所有者的授权许可上下文中签发, 并反映认证服务器在向客户端返回授权响应之前在访问令牌中强制执行的认证类型和强度. 它们的值是固定的, 并在从给定授权响应派生的所有访问令牌中保持不变, 无论访问令牌是直接在响应中获取的 (例如, 通过隐式流 (Implicit Flow)) 还是在一次或多次令牌交换之后 (例如, 使用刷新令牌 (Refresh Token) 获取新的访问令牌或通过[RFC8693]程序将一个访问令牌交换为另一个).
auth_time 可选 (OPTIONAL) - 如[OpenID.Core]第2节所定义.
acr 可选 (OPTIONAL) - 如[OpenID.Core]第2节所定义.
amr 可选 (OPTIONAL) - 如[OpenID.Core]第2节所定义.
2.2.2. Identity Claims (身份声明)
在涉及资源所有者的授权许可上下文中, 商业授权服务器通常会直接在访问令牌中包含资源所有者属性, 以便资源服务器可以直接使用它们进行授权或其他目的, 而无需进一步访问内省 (Introspection) ([RFC7662]) 或UserInfo ([OpenID.Core]) 端点. 这在客户端和资源服务器属于同一实体并且是同一解决方案的一部分的场景中尤其常见, 就像第一方客户端 (First-Party Client) 调用其自己的后端API的情况.
本配置文件不引入任何机制让客户端直接请求在JWT访问令牌中包含特定声明, 因为授权服务器可以通过将客户端的client_id以及请求中包含的 "scope" 和 "resource" 参数考虑在内来确定特定资源服务器需要哪些额外的声明.
如果要在JWT访问令牌中包含任何其他身份属性, 其语义在[RFC7519]中引入的 "JSON Web Token (JWT)" IANA注册表中的条目有明确描述, 则应该 (SHOULD) 使用相应的声明名称进行编码. 请注意, JWT IANA注册表包含[OpenID.Core]第5.1节中找到的声明.
授权服务器可以 (MAY) 返回任何现有规范中未定义的任意属性, 只要相应的声明名称具有抗冲突性, 或者访问令牌仅用于私有子系统内. 详细信息请参见[RFC7519]第4.2节和第4.3节.
在JWT访问令牌中包含资源所有者属性的授权服务器需要谨慎行事并验证所有隐私要求是否得到满足, 如第6节所述.
2.2.3. Authorization Claims (授权声明)
如果授权请求包含scope参数, 则相应签发的JWT访问令牌应该 (SHOULD) 包含如[RFC8693]第4.2节所定义的 "scope" 声明.
"scope" 声明中的所有单个作用域字符串必须 (MUST) 对 "aud" 声明中指示的资源有意义. 有关作用域字符串与 "aud" 声明所指示资源之间关系的更多考虑, 请参见第5节.
2.2.3.1. Claims for Authorization Outside of Delegation Scenarios (委托场景之外的授权声明)
许多授权服务器在其签发的访问令牌中嵌入了超出[RFC7519]描述的委托场景的授权属性. 典型示例包括资源所有者在与正在访问的资源相关的角色 (Role) 和组 (Group) 中的成员身份、授权服务器知道的为目标资源分配给资源所有者的权限 (Entitlement) 等.
希望在JWT访问令牌中包含此类属性的授权服务器应该 (SHOULD) 使用[RFC7643]第4.1.2节定义的 "User" 资源模式的 "groups"、"roles" 和 "entitlements" 属性作为声明类型.
授权服务器应该 (SHOULD) 根据[RFC7643]中定义的指导来编码相应的声明值. 特别是, 可以在[RFC7643]第8.2节中找到 "groups" 属性的非规范性示例. 没有为 "roles" 和 "entitlements" 提供特定的词汇表.
本文档第7.2.1节提供了用于将[RFC7643]中的 "groups"、"roles" 和 "entitlements" 属性注册为声明类型以在此配置文件中使用的条目.