2. JWT Access Token Header and Data Structure (JWTアクセストークンのヘッダーとデータ構造)

2.1. Header (ヘッダー)

JWTアクセストークンは署名されなければなりません (MUST)。JWTアクセストークンは任意の署名アルゴリズムを使用できますが、非対称暗号の使用が推奨されます (RECOMMENDED)。これは、リソースサーバーの検証情報取得プロセスを簡素化するためです (セクション4を参照)。JWTアクセストークンは署名アルゴリズムとして "none" を使用してはなりません (MUST NOT)。詳細についてはセクション4を参照してください。

本仕様に準拠する認可サーバーとリソースサーバーは、サポートされる署名アルゴリズムの中にRS256 ([RFC7518] で定義) を含めなければなりません (MUST)。

本仕様は "application/at+jwt" メディアタイプ (Media Type) を登録します。これは、コンテンツがJWTアクセストークンであることを示すために使用できます。JWTアクセストークンは、このプロファイルに準拠するアクセストークンを表すJWTであることを明示的に宣言するために、"typ" ヘッダーパラメータにこのメディアタイプを含めなければなりません (MUST)。[RFC7515] のセクション4.1.9における "typ" の定義により、"application/" プレフィックスを省略することが推奨されます (RECOMMENDED)。したがって、使用される "typ" 値は "at+jwt" であるべきです (SHOULD)。このプロファイルを実装するリソースサーバーがOpenID Connect IDトークン ([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で定義されています。認可コードグラント (Authorization Code Grant) などのリソースオーナー (Resource Owner) が関与するグラントを通じて取得されたアクセストークンの場合、"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) 経由) でも、1回以上のトークン交換の後 (例: リフレッシュトークン (Refresh Token) を使用して新しいアクセストークンを取得する、または [RFC8693] の手順を介して1つのアクセストークンを別のものと交換する) でも、特定の認可応答から派生するすべてのアクセストークンで同じままです。

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アクセストークンには、[RFC8693] のセクション4.2で定義されている "scope" クレームを含めるべきです (SHOULD)。

"scope" クレーム内のすべての個別のスコープ文字列は、"aud" クレームで示されるリソースに対して意味を持たなければなりません (MUST)。スコープ文字列と "aud" クレームによって示されるリソースとの関係に関する詳細な考慮事項については、セクション5を参照してください。

2.2.3.1. Claims for Authorization Outside of Delegation Scenarios (委譲シナリオ外の認可クレーム)

多くの認可サーバーは、[RFC7519] で説明されている委譲シナリオを超える認可属性を発行するアクセストークンに埋め込みます。典型的な例には、アクセスされているリソースに関連するロール (Role) やグループ (Group) へのリソースオーナーのメンバーシップ、認可サーバーが知っているターゲットリソースのためにリソースオーナーに割り当てられた権限 (Entitlement) などが含まれます。

このような属性をJWTアクセストークンに含めたい認可サーバーは、[RFC7643] のセクション4.1.2で定義されている "User" リソーススキーマの "groups"、"roles"、および "entitlements" 属性をクレームタイプとして使用すべきです (SHOULD)。

認可サーバーは、[RFC7643] で定義されているガイダンスに従って、対応するクレーム値をエンコードすべきです (SHOULD)。特に、"groups" 属性の非規範的な例は、[RFC7643] のセクション8.2にあります。"roles" と "entitlements" については、特定の語彙は提供されていません。

本文書のセクション7.2.1は、[RFC7643] の "groups"、"roles"、および "entitlements" 属性をこのプロファイルで使用するクレームタイプとして登録するためのエントリを提供します。

---