4. 安全性に関する考慮事項

OAuth 2.0 システムを実装するための方法は多種多様で有効であるため、結果として、認可サーバーがトークンが現在 "active" (アクティブ) であるかどうかを判断する方法も多数あります。しかし、トークンイントロスペクションを使用するリソースサーバーはトークンの状態を判断するために認可サーバーに依存しているため、認可サーバーはトークンの状態に対して適用可能なすべてのチェックを実行しなければなりません (MUST)。例えば、これらのテストには以下が含まれます：

トークンが期限切れになる可能性がある場合、認可サーバーはトークンが期限切れになっているかどうかを判断しなければなりません (MUST)。
トークンが使用可能になる前に発行される可能性がある場合、認可サーバーはトークンの有効期間がすでに開始されているかどうかを判断しなければなりません (MUST)。
トークンが発行後に取り消される可能性がある場合、認可サーバーはそのような取り消しが行われたかどうかを判断しなければなりません (MUST)。
トークンが署名されている場合、認可サーバーは署名を検証しなければなりません (MUST)。
トークンが特定のリソースサーバーでのみ使用できる場合、認可サーバーはトークンがイントロスペクション呼び出しを行っているリソースサーバーで使用できるかどうかを判断しなければなりません (MUST)。

認可サーバーが適用可能なチェックの実行に失敗した場合、リソースサーバーはその応答に基づいて誤ったセキュリティ決定を下す可能性があります。これらのチェックのすべてがすべての OAuth 2.0 展開に適用できるわけではなく、これらのチェック (およびその他のチェック) のどれが適用されるかを決定するのは認可サーバー次第であることに注意してください。

保護されておらず、制限もされていない場合、イントロスペクションエンドポイントは、攻撃者が一連の可能なトークン値をポーリングして有効なトークンを探し出す手段を提供する可能性があります。これを防ぐために、認可サーバーは、イントロスペクションエンドポイントにアクセスする必要がある保護されたリソースの認証を要求しなければならず (MUST)、保護されたリソースがイントロスペクションエンドポイントを呼び出すために具体的に認可されていることを要求すべきです (SHOULD)。このような認証資格情報の詳細は本仕様の範囲外ですが、一般的にこれらの資格情報は、トークンエンドポイントで使用される有効なクライアント認証メカニズム、OAuth 2.0 アクセストークン、またはその他の HTTP 認可または認証メカニズムの形式をとることができます。クライアントと保護されたリソースの両方として機能する単一のソフトウェアは、トークンエンドポイントとイントロスペクションエンドポイントの間で同じ資格情報を再利用してもかまいません (MAY) が、そうすることはソフトウェアのクライアント部分と保護されたリソース部分の活動を混同する可能性があり、認可サーバーは各モードに個別の資格情報を要求してもかまいません (MAY)。

イントロスペクションエンドポイントは OAuth 2.0 トークンをパラメータとして受け取り、認可決定を行うために使用される情報で応答するため、サーバーは Transport Layer Security (TLS) 1.2 [RFC5246] をサポートしなければならず (MUST)、セキュリティ要件を満たす追加のトランスポート層メカニズムをサポートしてもかまいません (MAY)。TLS を使用する場合、クライアントまたは保護されたリソースは、[RFC6125] で指定されているように、TLS/SSL サーバー証明書チェックを実行しなければなりません (MUST)。実装のセキュリティに関する考慮事項は、「TLS および DTLS の安全な使用に関する推奨事項」 [BCP195] に記載されています。

クエリパラメータを介してアクセストークンの値がサーバー側のログに漏洩するのを防ぐために、トークンイントロスペクションを提供する認可サーバーは、イントロスペクションエンドポイントでの HTTP GET の使用を禁止し、代わりにイントロスペクションエンドポイントで HTTP POST メソッドを使用することを要求してもかまいません (MAY)。

認可サーバーの内部状態の開示を避けるために、非アクティブなトークンに対するイントロスペクション応答には、必須の "active" クレーム (値が "false" に設定されている) 以外の追加のクレームを含めるべきではありません (SHOULD NOT)。

保護されたリソースはイントロスペクションエンドポイントの応答をキャッシュしてもよいため (MAY)、このプロトコルを使用する OAuth 2.0 システムの設計者は、このようなセキュリティ情報をキャッシュすることに固有のパフォーマンスとセキュリティのトレードオフを考慮しなければなりません (MUST)。タイムアウトが短い積極的でないキャッシュは、保護されたリソースにより最新の情報を提供します (イントロスペクションエンドポイントをより頻繁にクエリする必要があるため)。これは、ネットワークトラフィックとイントロスペクションエンドポイントへの負荷の増加を犠牲にします。持続時間が長いより積極的なキャッシュは、ネットワークトラフィックとイントロスペクションエンドポイントへの負荷を最小限に抑えますが、トークンに関する古い情報のリスクがあります。例えば、保護されたリソースが認可決定を行うためにキャッシュされた応答の値に依存している間に、トークンが取り消される可能性があります。これにより、取り消されたトークンが保護されたリソースで使用される可能性がある期間が生じます。その結果、アクセスされる保護されたリソースの懸念事項と機密性、および暫定期間中にトークンが取り消されたり無効になったりする可能性を考慮して、許容可能なキャッシュ有効期間を慎重に検討する必要があります。非常に機密性の高い環境では、保護されたリソースでのキャッシュを完全に無効にして、古いキャッシュ情報のリスクを完全に排除することを選択できます。これも、ネットワークトラフィックとサーバー負荷の増加を犠牲にします。応答に "exp" パラメータ (有効期限) が含まれている場合、応答はそこに示された時間を超えてキャッシュされてはなりません (MUST NOT)。

トークンイントロスペクションを提供する認可サーバーは、この呼び出し中に提示されるトークン値を理解できなければなりません。これが発生する正確な手段は実装の詳細であり、この仕様の範囲外です。非構造化トークンの場合、これはトークンのコンテキスト情報を含むデータストアに対する単純なサーバー側データベースクエリの形式をとることができます。構造化トークンの場合、これはサーバーがトークンを解析し、その署名またはその他の保護メカニズムを検証し、トークンに含まれる情報を保護されたリソースに返す (保護されたリソースがクライアントと同様にトークンの内容を知らないようにする) 形式をとることができます。イントロスペクションプロセス中に必要な暗号化された情報を運ぶトークンの場合、認可サーバーはこの情報にアクセスするためにトークンを復号化して検証できなければならないことに注意してください。また、認可サーバーがトークンに関する情報を保存しておらず、トークン自体を解析することによってトークンに関する情報にアクセスする手段がない場合、イントロスペクションサービスを提供できない可能性があることにも注意してください。