4. Validating JWT Access Tokens (JWTアクセストークンの検証)

検証データの取得を容易にするために、認可サーバーは非対称アルゴリズムを使用してJWTアクセストークンに署名することが推奨されます (RECOMMENDED)。

認可サーバーは、OAuth 2.0認可サーバーメタデータ (OAuth 2.0 Authorization Server Metadata) [RFC8414] を使用して、"jwks_uri" 経由で署名鍵をリソースサーバーに公開し、"issuer" メタデータ値を介して期待される "iss" クレーム値を公開すべきです (SHOULD)。あるいは、OpenID Connectを実装する認可サーバーは、同じ目的でOpenID Connect ディスカバリー (Discovery) [OpenID.Discovery] ドキュメントを使用できます (MAY)。認可サーバーがOAuth 2.0認可サーバーメタデータとOpenID Connectディスカバリーの両方をサポートしている場合、提供される値は2つの公開方法間で一貫していなければなりません (MUST)。

認可サーバーは、OpenID Connect IDトークンとJWTアクセストークンに署名するために異なる鍵を使用することを選択できます (MAY)。本仕様は、JWTアクセストークンの署名に使用される特定の鍵を識別するメカニズムを提供しません。認可サーバーは、認可サーバー (AS) メタデータまたはOpenID Connectディスカバリーを介して公開された任意の鍵を使用してJWTアクセストークンに署名できます。セキュリティへの影響に関する詳細なガイダンスについては、セクション5を参照してください。

JWTアクセストークンを受信するリソースサーバーは、次の方法で検証しなければなりません (MUST)。

リソースサーバーは、"typ" ヘッダー値が "at+jwt" または "application/at+jwt" であることを確認し、他の値を持つトークンを拒否しなければなりません (MUST)。
JWTアクセストークンが暗号化されている場合、登録時にリソースサーバーが指定した鍵とアルゴリズムを使用して復号化します。登録時に認可サーバーと暗号化がネゴシエートされ、受信したJWTアクセストークンが暗号化されていない場合、リソースサーバーはそれを拒否すべきです (SHOULD)。
認可サーバーの発行者識別子 (通常はディスカバリー中に取得される) は、"iss" クレームの値と正確に一致しなければなりません (MUST)。
リソースサーバーは、"aud" クレームにリソースサーバー自身が期待する識別子に対応するリソース指標値が含まれていることを検証しなければなりません (MUST)。"aud" に有効なオーディエンスとして現在のリソースサーバーのリソース指標が含まれていない場合、JWTアクセストークンは拒否されなければなりません (MUST)。
リソースサーバーは、JWT "alg" ヘッダーパラメータで指定されたアルゴリズムを使用して、[RFC7515] に従ってすべての受信JWTアクセストークンの署名を検証しなければなりません (MUST)。リソースサーバーは、"alg" の値が "none" であるJWTを拒否しなければなりません (MUST)。リソースサーバーは、認可サーバーが提供する鍵を使用しなければなりません (MUST)。
現在時刻は、"exp" クレームで表される時刻より前でなければなりません (MUST)。実装者は、クロックスキューを考慮するために、通常は数分以内の小さな余裕を提供できます (MAY)。

リソースサーバーは、[RFC6750] のセクション3.1で説明されているようにエラーを処理しなければなりません (MUST)。特に、上記の検証チェックのいずれかが失敗した場合、認可サーバーの応答にはエラーコード "invalid_token" を含めなければなりません (MUST)。この要求は、JWTアクセストークンが "Bearer" 以外の認証スキームを使用することを妨げるものではないことに注意してください。

JWTアクセストークンにセクション2.2.3で説明されている認可クレームが含まれている場合、リソースサーバーは、現在の呼び出しを認可するか拒否するかを決定するために、それらを利用可能な他のコンテキスト情報と組み合わせて使用すべきです (SHOULD)。リソースサーバーがこれらのチェックを実行する方法の詳細は、このプロファイル仕様の範囲外です。