5. Security Considerations (セキュリティに関する考慮事項)
ここで説明されているJWTアクセストークンのデータレイアウトは、[OpenID.Core] で定義されているid_tokenのものと非常に似ています。このプロファイルで要求される明示的な型付け (Explicit Typing) は、[RFC8725] の推奨事項に沿っており、リソースサーバーがJWTアクセストークンとOpenID Connect IDトークンを区別するのに役立ちます。
認可サーバーは、クライアントがリソースサーバーを混乱させる可能性のある方法で "sub" クレームの値に影響を与えるシナリオを防ぐべきです。たとえば、認可サーバーがクライアントクレデンシャルグラント (Client Credentials Grant) を使用して発行されたアクセストークンの "sub" 値としてclient_idを使用することを選択した場合、認可サーバーはクライアントが任意のclient_id値を登録することを防ぐべきです。これにより、悪意のあるクライアントが高権限リソースオーナーのsubを選択し、"sub" 値に依存するリソースサーバー上の認可ロジックを混乱させることを許してしまうためです。詳細については、[OAuth2.Security.BestPractices] のセクション4.14を参照してください。
クロスJWT混同 (Cross-JWT Confusion) を防ぐために、認可サーバーは、同じ発行者が異なるリソースに対して発行するアクセストークンを一意に識別するために、"aud" クレーム値として異なる識別子を使用しなければなりません (MUST)。クロスJWT混同の詳細については、[RFC8725] のセクション2.8を参照してください。
認可サーバーは、曖昧な認可グラントにつながる可能性のある要求を処理する際に特別な注意を払うべきです。たとえば、要求に複数のリソース指標が含まれている場合、認可サーバーは、結果として得られるJWTアクセストークンに含まれる各スコープ文字列 (存在する場合) が、"aud" クレームにリストされているリソースの中の特定のリソースに明確に関連付けられることを確認すべきです。この状況やその他の曖昧な状況を認識して軽減する方法の詳細は、シナリオに大きく依存するため、このプロファイルの範囲外です。
認可サーバーは、特定の鍵の漏洩の結果から保護する方法として、OpenID Connect IDトークンとJWTトークンの署名に異なる鍵を使用することに依存できません。リソースサーバーは、特にJWTアクセストークンの検証に使用すべき鍵を知る方法がないため、ASメタデータまたはOpenID Connectディスカバリーで公開されている任意の鍵で実行された署名を受け入れる必要があります。その結果、攻撃者は、公開されている鍵のいずれかを侵害するだけで、リソースサーバーが有効として受け入れるJWTを生成して署名できます。