2. JWT 访问令牌头部和数据结构

2.1. Header

JWT 访问令牌必须被签名. 虽然 JWT 访问令牌可以使用任意签名算法, 但推荐使用非对称密码算法, 因为这可以简化资源服务器获取验证信息的过程 (参见第 4 节). JWT 访问令牌禁止使用 "none" 作为签名算法. 更多细节参见第 4 节.

符合本规范的授权服务器和资源服务器必须在其支持的签名算法中包含 RS256 ([RFC7518] 中定义).

本规范注册 "application/at+jwt" 媒体类型, 可用于表明内容是 JWT 访问令牌. JWT 访问令牌 MUST 在 "typ" 头部参数中包含此媒体类型, 以明确声明该 JWT 表示符合此配置文件的访问令牌. 按照 [RFC7515] 第 4.1.9 节对 "typ" 的定义, RECOMMENDED 省略 "application/" 前缀. 因此, 所使用的 "typ" 值 SHOULD 为 "at+jwt". 关于防止实现此配置文件的资源服务器将 OpenID Connect ID Tokens (由 [OpenID.Core] 第 2 节定义) 接受为访问令牌的重要性, 详见安全考虑事项一节.

2.2. Data Structure

JWT 访问令牌数据结构使用以下 claim.

iss REQUIRED - as defined in Section 4.1.1 of [RFC7519]. iss 必需 - 如 [RFC7519] 第 4.1.1 节所定义, 表示签发该 JWT 访问令牌的 issuer.

exp REQUIRED - as defined in Section 4.1.4 of [RFC7519]. exp 必需 - 如 [RFC7519] 第 4.1.4 节所定义, 表示令牌过期时间.

aud REQUIRED - as defined in Section 4.1.3 of [RFC7519]. See Section 3 for indications on how an authorization server should determine the value of "aud" depending on the request. aud 必需 - 如 [RFC7519] 第 4.1.3 节所定义. 授权服务器如何根据请求确定 "aud" 值, 参见第 3 节.

sub REQUIRED - as defined in Section 4.1.2 of [RFC7519]. In cases of access tokens obtained through grants where a resource owner is involved, such as the authorization code grant, the value of "sub" SHOULD correspond to the subject identifier of the resource owner. In cases of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of "sub" SHOULD correspond to an identifier the authorization server uses to indicate the client application. See Section 5 for more details on this scenario. Also, see Section 6 for a discussion about how different choices in assigning "sub" values can impact privacy. sub 必需 - 如 [RFC7519] 第 4.1.2 节所定义. 对于涉及资源所有者的授权授予 (例如 authorization code grant) 所获得的访问令牌, "sub" 值应当对应资源所有者的主体标识符. 对于不涉及资源所有者的授权授予 (例如 client credentials grant) 所获得的访问令牌, "sub" 值应当对应授权服务器用于表示客户端应用的标识符. 此场景的更多细节参见第 5 节. 不同 "sub" 值分配选择对隐私的影响见第 6 节.

client_id REQUIRED - as defined in Section 4.3 of [RFC8693].

iat REQUIRED - as defined in Section 4.1.6 of [RFC7519]. This claim identifies the time at which the JWT access token was issued. iat 必需 - 如 [RFC7519] 第 4.1.6 节所定义. 该 claim 标识 JWT 访问令牌的签发时间.

jti REQUIRED - as defined in Section 4.1.7 of [RFC7519].

2.2.1. Authentication Information Claims

本节列出的 claim 可以在涉及资源所有者的授权授予上下文中签发, 用于反映认证服务器在向客户端返回授权响应之前强制执行的认证类型和强度. 对于从同一授权响应派生出的所有访问令牌, 这些值是固定且保持一致的, 无论访问令牌是直接在响应中获得 (例如通过 implicit flow), 还是经过一次或多次令牌交换后获得 (例如使用 refresh token 获取新的访问令牌, 或通过 [RFC8693] 过程将一个访问令牌交换为另一个访问令牌).

auth_time OPTIONAL - as defined in Section 2 of [OpenID.Core].

acr OPTIONAL - as defined in Section 2 of [OpenID.Core].

amr OPTIONAL - as defined in Section 2 of [OpenID.Core].

2.2.2. Identity Claims

在涉及资源所有者的授权授予上下文中, 商业授权服务器通常会直接在访问令牌中包含资源所有者属性, 以便资源服务器可以直接将其用于授权或其他目的, 而无需再往返访问 introspection ([RFC7662]) 或 UserInfo ([OpenID.Core]) 端点. 在客户端和资源服务器属于同一实体且是同一解决方案一部分的场景中, 这种做法尤其常见, 例如第一方客户端调用自己的后端 API.

本配置文件不引入让客户端直接请求 JWT 访问令牌中出现特定 claim 的机制, 因为授权服务器可以结合客户端的 client_id 以及请求中包含的 "scope" 和 "resource" 参数, 判断特定资源服务器需要哪些附加 claim.

如果要在 JWT 访问令牌中包含某个附加身份属性, 且其语义已由 [RFC7519] 引入的 "JSON Web Token (JWT)" IANA 注册表中的条目充分描述, 则该属性 SHOULD 使用对应的 claim 名称进行编码. 注意, JWT IANA 注册表包括 [OpenID.Core] 第 5.1 节中的 claim.

授权服务器可以返回现有规范中未定义的任意属性, 前提是对应 claim 名称具有抗冲突性, 或者这些访问令牌仅打算在私有子系统中使用. 详情参见 [RFC7519] 第 4.2 和 4.3 节.

在 JWT 访问令牌中包含资源所有者属性的授权服务器需要谨慎处理, 并确认满足所有隐私要求, 相关讨论见第 6 节.

2.2.3. Authorization Claims

如果授权请求包含 scope 参数, 对应签发的 JWT 访问令牌应当包含 [RFC8693] 第 4.2 节定义的 "scope" claim.

"scope" claim 中的每个单独 scope 字符串都必须对 "aud" claim 指示的资源有意义. 关于 scope 字符串与 "aud" claim 所指资源之间关系的更多考虑, 参见第 5 节.

2.2.3.1. Claims for Authorization Outside of Delegation Scenarios

Many authorization servers embed authorization attributes that go beyond the delegated scenarios described by [RFC7519] in the access tokens they issue. Typical examples include resource owner memberships in roles and groups that are relevant to the resource being accessed, entitlements assigned to the resource owner for the targeted resource that the authorization server knows about, and so on.

An authorization server wanting to include such attributes in a JWT access token SHOULD use the "groups", "roles", and "entitlements" attributes of the "User" resource schema defined by Section 4.1.2 of [RFC7643] as claim types.

Authorization servers SHOULD encode the corresponding claim values according to the guidance defined in [RFC7643]. In particular, a non-normative example of a "groups" attribute can be found in Section 8.2 of [RFC7643]. No specific vocabulary is provided for "roles" and "entitlements".

Section 7.2.1 of this document provides entries for registering "groups", "roles", and "entitlements" attributes from [RFC7643] as claim types to be used in this profile.

---