10. セキュリティに関する考慮事項 (Security Considerations)
柔軟で拡張可能なフレームワークとして、OAuth のセキュリティに関する考慮事項は多くの要因に依存します。以下のセクションでは、セクション2.1で説明されている3つのクライアントプロファイル（Web アプリケーション、ユーザーエージェントベースのアプリケーション、およびネイティブアプリケーション）に焦点を当てたセキュリティガイドラインを実装者に提供します。
包括的な OAuth セキュリティモデルと分析、およびプロトコル設計の背景は、[OAuth-THREATMODEL] で提供されています。
10.1. クライアント認証 (Client Authentication)
認可サーバー (Authorization Server) は、クライアント認証の目的で、Web アプリケーションクライアントとクライアント認証情報を確立します。認可サーバーは、クライアントパスワードよりも強力なクライアント認証手段を検討することが推奨されます (encouraged)。Web アプリケーションクライアントは、クライアントパスワードおよびその他のクライアント認証情報の機密性を確保しなければなりません (MUST)。
認可サーバーは、クライアント認証の目的で、ネイティブアプリケーションまたはユーザーエージェントベースのアプリケーションクライアントにクライアントパスワードまたはその他のクライアント認証情報を発行してはなりません (MUST NOT)。認可サーバーは、特定のデバイス上のネイティブアプリケーションクライアントの特定のインストールに対して、クライアントパスワードまたはその他の認証情報を発行することができます (MAY)。
クライアント認証が不可能な場合、認可サーバーは、クライアントの ID を検証するために他の手段を採用すべきです (SHOULD)。たとえば、クライアントリダイレクション URI の登録を要求するか、リソースオーナー (Resource Owner) に ID の確認を依頼します。有効なリダイレクション URI は、リソースオーナー認可を求める際にクライアントの ID を検証するには十分ではありませんが、リソースオーナー認可を取得した後に偽造クライアントに認証情報を配信することを防ぐために使用できます。
認可サーバーは、認証されていないクライアントとやり取りすることのセキュリティへの影響を考慮し、そのようなクライアントに発行された他の認証情報 (たとえば、リフレッシュトークン (Refresh Token)) の潜在的な露出を制限する措置を講じなければなりません (must)。
10.2. クライアントのなりすまし (Client Impersonation)
悪意のあるクライアントは、なりすまされたクライアントがクライアント認証情報を機密に保つことができない場合、または保つことができない場合、別のクライアントになりすまして保護されたリソースへのアクセスを取得できます。
認可サーバーは、可能な限りクライアントを認証しなければなりません (MUST)。クライアントの性質上、認可サーバーがクライアントを認証できない場合、認可サーバーは、認可レスポンスを受信するために使用されるリダイレクション URI の登録を要求しなければならず (MUST)、そのような潜在的に悪意のあるクライアントからリソースオーナーを保護するために他の手段を利用すべきです (SHOULD)。たとえば、認可サーバーは、クライアントとその起源を識別するのを支援するためにリソースオーナーを関与させることができます。
認可サーバーは、明示的なリソースオーナー認証を強制し、クライアントと要求された認可スコープおよびライフタイムに関する情報をリソースオーナーに提供すべきです (SHOULD)。現在のクライアントのコンテキストで情報を確認し、リクエストを承認または拒否するかどうかは、リソースオーナー次第です。
10.3. アクセストークン (Access Tokens)
アクセストークン認証情報 (アクセストークンと、認可サーバーによって発行された秘密) は、リソースサーバー (Resource Server) へのアクセスを取得するために使用できます。アクセストークン認証情報は、クライアント認証情報と同様に、不正なアクセスから保護しなければなりません (MUST)。
アクセストークンは通常、有効期限が限定されており、その有効期限が切れると更新できます。ただし、そのようなトークンは、攻撃者によって傍受および使用される可能性があります。セキュリティへの影響を軽減するための対策には、短いライフタイムと制限されたスコープの発行が含まれます。
10.4. リフレッシュトークン (Refresh Tokens)
認可サーバーは、リフレッシュトークン (Refresh Token) に厳格な保存要件を適用することができます (MAY)。たとえば、認可サーバーは、リフレッシュトークンのライフタイムを制限したり、リフレッシュトークンのスコープを制限したりすることができます。
認可サーバーは、リフレッシュトークンとそれが発行されたクライアントとの間にバインディングを維持しなければなりません (MUST)。リフレッシュトークンは、それが発行されたクライアントによってのみ使用されなければなりません (MUST)。認可サーバーは、リフレッシュトークンがそれが発行されたクライアントによって提示されていることを確認しなければなりません (MUST)。
10.5. 認可コード (Authorization Codes)
認可コード (Authorization Code) の送信は、機密性とクライアントの真正性を確保するために、セキュアなチャネルを介して行われるべきです (SHOULD)。
認可サーバーは、認可コードが一度だけ使用されることを保証しなければなりません (MUST)。認可コードが複数回使用された場合、認可サーバーはリクエストを拒否し、可能であれば (SHOULD)、その認可コードに基づいて以前に発行されたすべてのトークンを取り消すべきです (SHOULD)。
認可コードは短期間有効でなければなりません (MUST)。最大認可コードライフタイムは 10 分と推奨されます。
10.6. 認可コードリダイレクション URI 操作 (Authorization Code Redirection URI Manipulation)
攻撃者が認可コードを傍受した場合、攻撃者は、クライアントが使用するリダイレクション URI を攻撃者が制御する URI に置き換えようとする可能性があります。
認可サーバーは、リダイレクション URI の登録を要求し、クライアントが認可コードを交換する際にリダイレクション URI を検証することで、この攻撃を防止しなければなりません (MUST)。
10.7. リソースオーナーパスワードクレデンシャル (Resource Owner Password Credentials)
リソースオーナーパスワードクレデンシャルグラントタイプは、多くの場合、レガシーまたは移行の理由で使用されます。このグラントタイプは、リソースオーナーとクライアント間に高度な信頼関係がある場合にのみ使用すべきです (SHOULD)。
10.8. リクエストの機密性 (Request Confidentiality)
アクセストークン、リフレッシュトークン、リソースオーナーパスワード、およびクライアント認証情報は、機密性を持たせて送信してはなりません (MUST NOT)。TLS [RFC5246] をバージョン 1.2 以降で使用することが推奨されます (RECOMMENDED)。
10.9. エンドポイントの真正性の確保 (Ensuring Endpoint Authenticity)
リソースオーナーとクライアントが通信するエンドポイントの ID を検証するために、TLS サーバー認証 (RFC5246 で定義) を使用すべきです (SHOULD)。
10.10. 認証情報推測攻撃 (Credentials-Guessing Attacks)
認可サーバーは、認証情報推測攻撃から認可サーバー自体とそのクライアントを保護するために、ブルートフォース攻撃に対する保護を実装しなければなりません (MUST)。
10.11. フィッシング攻撃 (Phishing Attacks)
OAuth プロトコル設計における広範なリダイレクションの使用は、攻撃者がフィッシング攻撃を開始するために OAuth プロトコルフローを悪用する機会を生み出します。
認可サーバーは、リソースオーナーが認証先のエンティティを視覚的に検証できるように設計された認証メカニズムを使用すべきです (SHOULD)。
10.12. クロスサイトリクエストフォージェリ (Cross-Site Request Forgery)
クロスサイトリクエストフォージェリ (CSRF) は、攻撃者が被害者のユーザーエージェントに、被害者の知らないうちに意図しないリクエストを送信させる悪用手法です。
クライアントは、CSRF 攻撃から保護するために「state」リクエストパラメータを使用して、クライアント認可エンドポイントリクエストとその後のコールバック間で状態を維持しなければなりません (MUST)。
10.13. クリックジャッキング (Clickjacking)
クリックジャッキングでは、攻撃者は正当なサーバーから提供されるターゲットサイトを iframe に登録し、透明な層として iframe の上に配置します。
認可サーバーは、クリックジャッキング攻撃を防ぐために X-Frame-Options ヘッダーフィールドを使用すべきです (SHOULD)。
10.14. コードインジェクションと入力検証 (Code Injection and Input Validation)
認可サーバー、クライアント、およびリソースサーバーによって受信されるすべての入力値は、注入攻撃を防ぐために検証しなければなりません (MUST)。
10.15. オープンリダイレクター (Open Redirectors)
認可サーバー、認可エンドポイント、およびクライアントリダイレクションエンドポイントは、オープンリダイレクターとして動作するように設計してはなりません (MUST NOT)。
10.16. インプリシットフローでのアクセストークンの誤用 (Misuse of Access Token to Impersonate Resource Owner)
インプリシットグラントフローでは、攻撃者は傍受されたアクセストークンを使用して、別のクライアントになりすましてリソースオーナーになりすます可能性があります。
クライアント開発者は、アクセストークンが意図されたリソースサーバーによってのみ使用されることを確保するための対策を講じるべきです (SHOULD)。