10. セキュリティに関する考慮事項 (Security Considerations)
柔軟で拡張可能なフレームワークであるため、OAuth のセキュリティ上の考慮事項は多くの要因に依存します。以下の節では、2.1節で説明した3つのクライアントプロファイル、すなわち Web アプリケーション、ユーザーエージェントベースアプリケーション、ネイティブアプリケーションに焦点を当てたセキュリティ指針を実装者に提供します。
包括的な OAuth セキュリティモデルおよび分析、ならびにプロトコル設計の背景は [OAuth-THREATMODEL] に示されています。
10.1. クライアント認証 (Client Authentication)
認可サーバーは、クライアント認証の目的で Web アプリケーションクライアントとの間にクライアント認証情報を確立します。認可サーバーは、クライアントパスワードより強力なクライアント認証手段を検討することが推奨されます。Web アプリケーションクライアントは、クライアントパスワードおよびその他のクライアント認証情報の機密性を確保しなければなりません (MUST)。
認可サーバーは、クライアント認証の目的で、ネイティブアプリケーションまたはユーザーエージェントベースアプリケーションのクライアントにクライアントパスワードその他のクライアント認証情報を発行してはなりません (MUST NOT)。ただし、認可サーバーは、特定のデバイス上のネイティブアプリケーションクライアントの特定のインストールに対して、クライアントパスワードその他の認証情報を発行してもよいです (MAY)。
クライアント認証が不可能な場合、認可サーバーはクライアントのアイデンティティを検証する他の手段を用いるべきです (SHOULD)。たとえば、クライアントのリダイレクション URI の登録を要求する、またはリソースオーナーにアイデンティティ確認を依頼する方法があります。有効なリダイレクション URI は、リソースオーナーの認可を求める際にクライアントのアイデンティティを検証するには十分ではありませんが、リソースオーナーの認可取得後に偽造クライアントへ認証情報を配送することを防ぐために使用できます。
認可サーバーは、認証されていないクライアントとやり取りすることのセキュリティ上の影響を考慮し、そのようなクライアントに発行される他の認証情報、たとえばリフレッシュトークンの潜在的な露出を制限する措置を講じなければなりません。
10.2. クライアントのなりすまし (Client Impersonation)
悪意のあるクライアントは、なりすまし対象のクライアントがクライアント認証情報を機密に保てない、または保たない場合、別のクライアントになりすまして保護リソースへのアクセスを取得できます。
認可サーバーは可能な限りクライアントを認証しなければなりません (MUST)。クライアントの性質により認可サーバーがクライアントを認証できない場合、認可サーバーは認可レスポンスを受信するために使用されるすべてのリダイレクション URI の登録を要求しなければならず (MUST)、そのような潜在的に悪意のあるクライアントからリソースオーナーを保護するために他の手段を利用すべきです (SHOULD)。たとえば、認可サーバーは、クライアントおよびその出所の識別を支援するようリソースオーナーに関与してもらうことができます。
認可サーバーは、明示的なリソースオーナー認証を強制し、クライアントならびに要求された認可スコープおよび有効期間に関する情報をリソースオーナーに提供すべきです (SHOULD)。リソースオーナーは、現在のクライアントの文脈でその情報を確認し、要求を許可するか拒否するかを判断します。
認可サーバーは、クライアントを認証していない場合、または反復要求が元のクライアントから来ておりなりすましではないことを保証する他の手段に依存していない場合、リソースオーナーの能動的な操作なしに反復した認可要求を自動処理すべきではありません (SHOULD NOT)。
10.3. アクセストークン (Access Tokens)
アクセストークン認証情報、および機密のアクセストークン属性は、転送中および保存中に機密に保たれなければならず (MUST)、認可サーバー、そのアクセストークンが有効なリソースサーバー、およびそのアクセストークンの発行先クライアントの間でのみ共有されなければなりません。アクセストークン認証情報は、1.6節で説明する TLS と [RFC2818] で定義されるサーバー認証を用いてのみ送信されなければなりません (MUST)。
インプリシットグラントタイプを使用する場合、アクセストークンは URI フラグメント内で送信されるため、認可されていない当事者に露出する可能性があります。
認可サーバーは、認可されていない当事者が有効なアクセストークンを生成、変更、または推測できないことを保証しなければなりません (MUST)。
クライアントは、必要最小限のスコープでアクセストークンを要求すべきです (SHOULD)。認可サーバーは、要求されたスコープをどのように尊重するかを決める際にクライアントのアイデンティティを考慮すべきであり (SHOULD)、要求より少ない権限を持つアクセストークンを発行してもよいです (MAY)。
この仕様は、あるクライアントから提示されたアクセストークンがそのクライアントに対して認可サーバーから発行されたものであることを、リソースサーバーが確認する方法を提供しません。
10.4. リフレッシュトークン (Refresh Tokens)
認可サーバーは、Web アプリケーションクライアントおよびネイティブアプリケーションクライアントにリフレッシュトークンを発行してもよいです (MAY)。
リフレッシュトークンは転送中および保存中に機密に保たれなければならず (MUST)、認可サーバーと、そのリフレッシュトークンの発行先クライアントの間でのみ共有されます。認可サーバーは、リフレッシュトークンとその発行先クライアントとの束縛を維持しなければなりません (MUST)。リフレッシュトークンは、1.6節で説明する TLS と [RFC2818] のサーバー認証を用いてのみ送信されなければなりません (MUST)。
認可サーバーは、クライアントアイデンティティを認証できる場合には常に、リフレッシュトークンとクライアントアイデンティティの束縛を検証しなければなりません (MUST)。クライアント認証が不可能な場合、認可サーバーはリフレッシュトークンの不正使用を検出する他の手段を展開すべきです (SHOULD)。
たとえば、認可サーバーはリフレッシュトークンローテーションを用いることができます。この方式では、アクセストークン更新レスポンスごとに新しいリフレッシュトークンを発行します。以前のリフレッシュトークンは無効化されますが、認可サーバーには保持されます。リフレッシュトークンが漏えいし、その後攻撃者と正当なクライアントの両方に使用された場合、いずれかが無効化済みのリフレッシュトークンを提示するため、認可サーバーは侵害を検知できます。
認可サーバーは、認可されていない当事者が有効なリフレッシュトークンを生成、変更、または推測できないことを保証しなければなりません (MUST)。
10.5. 認可コード (Authorization Codes)
認可コードの送信はセキュアなチャネル上で行うべきであり (SHOULD)、URI がネットワークリソースを識別する場合、クライアントはそのリダイレクション URI に TLS の使用を要求すべきです (SHOULD)。認可コードはユーザーエージェントのリダイレクションを介して送信されるため、ユーザーエージェントの履歴や HTTP Referer ヘッダを通じて開示される可能性があります。
認可コードは平文の bearer 認証情報として機能し、認可サーバーで認可を付与したリソースオーナーと、処理を完了するためにクライアントへ戻ってきたリソースオーナーが同一であることを検証するために使われます。したがって、クライアントが自身のリソースオーナー認証に認可コードを依存させる場合、クライアントのリダイレクションエンドポイントは TLS の使用を要求しなければなりません (MUST)。
認可コードは短命かつ一回限りでなければなりません (MUST)。認可サーバーが、同じ認可コードをアクセストークンと交換しようとする複数回の試行を観測した場合、認可サーバーは、侵害された認可コードに基づいてすでに付与されたすべてのアクセストークンの取り消しを試みるべきです (SHOULD)。
クライアントを認証できる場合、認可サーバーはクライアントを認証し、その認可コードが同じクライアントに発行されたことを保証しなければなりません (MUST)。
10.6. 認可コードのリダイレクション URI 操作
認可コードグラントタイプで認可を要求する際、クライアントは "redirect_uri" パラメータでリダイレクション URI を指定できます。攻撃者がリダイレクション URI の値を操作できる場合、認可サーバーに、リソースオーナーのユーザーエージェントを攻撃者が管理する URI へ認可コード付きでリダイレクトさせることができます。
攻撃者は正当なクライアントにアカウントを作成し、認可フローを開始できます。攻撃者のユーザーエージェントがアクセス許可のため認可サーバーへ送られると、攻撃者は正当なクライアントが提供した認可 URI を取得し、クライアントのリダイレクション URI を攻撃者管理下の URI に置き換えます。その後、攻撃者は被害者をだまして操作済みリンクをたどらせ、正当なクライアントへのアクセスを認可させます。
認可サーバー上では、被害者には正当かつ信頼されたクライアントを代表する通常の有効な要求が提示され、被害者はそれを認可します。被害者はその後、攻撃者が管理するエンドポイントへ認可コード付きでリダイレクトされます。攻撃者は、その認可コードをクライアントが提供した元のリダイレクション URI でクライアントに送信して認可フローを完了します。クライアントは認可コードをアクセストークンと交換し、それを攻撃者のクライアントアカウントに結び付けます。これにより、そのアカウントは被害者が認可した保護リソースにクライアント経由でアクセスできます。
この攻撃を防ぐため、認可サーバーは、認可コードを取得するために使用されたリダイレクション URI が、認可コードをアクセストークンと交換する際に提供されたリダイレクション URI と同一であることを保証しなければなりません (MUST)。認可サーバーは public クライアントにリダイレクション URI の登録を要求しなければならず (MUST)、confidential クライアントにも要求すべきです (SHOULD)。要求でリダイレクション URI が提供された場合、認可サーバーは登録済み値に照らして検証しなければなりません (MUST)。
10.7. リソースオーナーパスワード認証情報
リソースオーナーパスワード認証情報グラントタイプは、しばしばレガシーまたは移行上の理由で使用されます。これは、クライアントがユーザー名とパスワードを保存する全体的なリスクを低減しますが、高権限の認証情報をクライアントに公開する必要性をなくすものではありません。
このグラントタイプは、このプロトコルが避けようとしているパスワードのアンチパターンを維持するため、他のグラントタイプより高いリスクを伴います。クライアントがパスワードを悪用する可能性があり、またはパスワードがログファイルその他クライアントの記録などを通じて意図せず攻撃者に開示される可能性があります。
さらに、リソースオーナーは認可プロセスを制御できません。関与は認証情報をクライアントに渡した時点で終了するため、クライアントはリソースオーナーが望むより広いスコープのアクセストークンを取得できます。認可サーバーは、このグラントタイプで発行するアクセストークンのスコープと有効期間を考慮すべきです。
認可サーバーとクライアントは、このグラントタイプの使用を最小限にし、可能な限り他のグラントタイプを利用すべきです (SHOULD)。
10.8. 要求の機密性 (Request Confidentiality)
アクセストークン、リフレッシュトークン、リソースオーナーパスワード、およびクライアント認証情報は平文で送信してはなりません (MUST NOT)。認可コードは平文で送信すべきではありません (SHOULD NOT)。
"state" および "scope" パラメータには、クライアントまたはリソースオーナーに関する機微情報を平文で含めるべきではありません (SHOULD NOT)。これらは安全でないチャネルを通じて送信されたり、安全でない形で保存されたりする可能性があるためです。
10.9. エンドポイント真正性の確保
中間者攻撃を防ぐため、認可サーバーは、認可エンドポイントおよびトークンエンドポイントへ送られるすべての要求に対して、[RFC2818] で定義されるサーバー認証付き TLS の使用を要求しなければなりません (MUST)。クライアントは、[RFC6125] で定義され、サーバーアイデンティティ認証の要件に従った形で、認可サーバーの TLS 証明書を検証しなければなりません (MUST)。
10.10. 認証情報推測攻撃
認可サーバーは、攻撃者がアクセストークン、認可コード、リフレッシュトークン、リソースオーナーパスワード、およびクライアント認証情報を推測することを防がなければなりません (MUST)。
攻撃者が生成されたトークン、およびエンドユーザーが扱うことを意図しないその他の認証情報を推測できる確率は 2^(-128) 以下でなければならず (MUST)、2^(-160) 以下であるべきです (SHOULD)。
認可サーバーは、エンドユーザーの使用を意図した認証情報を保護するために他の手段を利用しなければなりません (MUST)。
10.11. フィッシング攻撃
このプロトコルおよび類似プロトコルが広く展開されると、エンドユーザーは、パスワード入力を求められる Web サイトへリダイレクトされる慣行に慣れてしまう可能性があります。エンドユーザーが認証情報を入力する前にこれらの Web サイトの真正性を慎重に確認しない場合、攻撃者はこの慣行を悪用してリソースオーナーのパスワードを盗むことができます。
サービスプロバイダは、フィッシング攻撃がもたらすリスクについてエンドユーザーを教育し、エンドユーザーがサイトの真正性を容易に確認できる仕組みを提供するよう努めるべきです。クライアント開発者は、ユーザーエージェントとの相互作用の方法、たとえば外部ブラウザか埋め込みブラウザか、およびエンドユーザーが認可サーバーの真正性を確認できる能力について、そのセキュリティ上の影響を考慮すべきです。
フィッシング攻撃のリスクを低減するため、認可サーバーはエンドユーザーとの相互作用に使用されるすべてのエンドポイントで TLS の使用を要求しなければなりません (MUST)。
10.12. クロスサイトリクエストフォージェリ
クロスサイトリクエストフォージェリ (CSRF) は、攻撃者が被害者であるエンドユーザーのユーザーエージェントに、悪意ある URI、たとえば誤解を招くリンク、画像、またはリダイレクションとしてユーザーエージェントへ提供された URI を、信頼しているサーバーへたどらせる攻撃です。通常、その信頼は有効なセッションクッキーの存在によって成立しています。
クライアントのリダイレクション URI に対する CSRF 攻撃では、攻撃者が自分の認可コードまたはアクセストークンを注入できます。その結果、クライアントが被害者の保護リソースではなく攻撃者の保護リソースに関連付けられたアクセストークンを使用することがあります。たとえば、被害者の銀行口座情報を攻撃者が制御する保護リソースへ保存させる可能性があります。
クライアントは、そのリダイレクション URI に対して CSRF 保護を実装しなければなりません (MUST)。これは通常、リダイレクション URI エンドポイントへ送られるすべての要求に、ユーザーエージェントの認証済み状態に要求を束縛する値、たとえばユーザーエージェントの認証に使われるセッションクッキーのハッシュを含めることで実現されます。クライアントは、認可要求を行う際に、この値を認可サーバーへ配送するため "state" 要求パラメータを利用すべきです (SHOULD)。
エンドユーザーから認可が取得されると、認可サーバーは "state" パラメータ内の必要な束縛値とともに、エンドユーザーのユーザーエージェントをクライアントへリダイレクトします。この束縛値により、クライアントは束縛値をユーザーエージェントの認証済み状態と照合して要求の妥当性を検証できます。CSRF 保護に使用される束縛値は、10.10節で説明する推測不能な値を含まなければならず (MUST)、ユーザーエージェントの認証済み状態、たとえばセッションクッキーや HTML5 ローカルストレージは、クライアントとユーザーエージェントだけがアクセスできる場所、すなわち同一生成元ポリシーで保護された場所に保持されなければなりません (MUST)。
認可サーバーの認可エンドポイントに対する CSRF 攻撃では、攻撃者が、エンドユーザーを関与させたり警告したりせずに、悪意あるクライアントに対するエンドユーザーの認可を取得する結果となる可能性があります。
認可サーバーは認可エンドポイントに CSRF 保護を実装し、悪意あるクライアントがリソースオーナーの認識と明示的同意なしに認可を取得できないことを保証しなければなりません (MUST)。
10.13. クリックジャッキング (Clickjacking)
クリックジャッキング攻撃では、攻撃者は正当なクライアントを登録し、その後、認可サーバーの認可エンドポイント Web ページを透明な iframe として読み込む悪意あるサイトを構築します。この iframe は、認可ページ上の重要なボタンの真上に配置されるよう注意深く作られたダミーボタン群の上に重ねられます。エンドユーザーが誤解を招く可視ボタンをクリックすると、実際には認可ページ上の不可視ボタン、たとえば "Authorize" ボタンをクリックしていることになります。これにより攻撃者は、エンドユーザーに気づかれずに、リソースオーナーをだまして攻撃者のクライアントへアクセスを許可させることができます。
この種の攻撃を防ぐため、ネイティブアプリケーションは、エンドユーザー認可を要求する際に、アプリケーション内にブラウザを埋め込むのではなく外部ブラウザを使用すべきです (SHOULD)。比較的新しい多くのブラウザでは、認可サーバーが非標準の "x-frame-options" ヘッダを使用して iframe の回避を強制できます。このヘッダは "deny" と "sameorigin" の2つの値を取り、それぞれすべてのフレーミング、または異なるオリジンのサイトによるフレーミングをブロックします。古いブラウザでは JavaScript の frame-busting 技法を使用できますが、すべてのブラウザで有効とは限りません。
10.14. コードインジェクションと入力検証
コードインジェクション攻撃は、入力値またはその他の外部変数がアプリケーションにより無害化されずに使用され、アプリケーションロジックを変更させる場合に発生します。これにより攻撃者は、アプリケーションデバイスまたはそのデータへアクセスしたり、サービス拒否を引き起こしたり、幅広い悪意ある副作用を導入したりできます。
認可サーバーおよびクライアントは、受信したすべての値、特に "state" および "redirect_uri" パラメータの値を無害化し、可能な場合は検証しなければなりません (MUST)。
10.15. オープンリダイレクタ (Open Redirectors)
認可サーバー、認可エンドポイント、およびクライアントのリダイレクションエンドポイントは、不適切に設定されるとオープンリダイレクタとして動作する可能性があります。オープンリダイレクタとは、パラメータ値で指定された場所へ、検証なしにユーザーエージェントを自動的にリダイレクトするエンドポイントです。
オープンリダイレクタはフィッシング攻撃に使用される可能性があり、また、攻撃者が馴染みがあり信頼された宛先の URI authority コンポーネントを利用して、エンドユーザーに悪意あるサイトを訪問させるためにも使用できます。さらに、認可サーバーがクライアントにリダイレクション URI の一部だけの登録を許可している場合、攻撃者はクライアントが運用するオープンリダイレクタを使って、認可サーバーの検証を通過するが認可コードまたはアクセストークンを攻撃者管理下のエンドポイントへ送るリダイレクション URI を構築できます。
10.16. インプリシットフローでリソースオーナーになりすますためのアクセストークン誤用
インプリシットフローを使用する public クライアントについて、この仕様は、アクセストークンがどのクライアントに発行されたかをクライアントが判断する方法を提供しません。
リソースオーナーは、攻撃者の悪意あるクライアントにアクセストークンを付与して、意図的にリソースへのアクセスを委任する可能性があります。これはフィッシングその他の口実による場合があります。攻撃者が別の仕組みでトークンを盗む場合もあります。その後、攻撃者はそのアクセストークンを正当な public クライアントへ提示して、リソースオーナーになりすまそうとする可能性があります。
インプリシットフロー (response_type=token) では、攻撃者は認可サーバーからのレスポンス内のトークンを容易に差し替え、実際のアクセストークンを、以前に攻撃者へ発行されたトークンで置き換えることができます。
バックチャネルで渡されるアクセストークンに依存してクライアントのユーザーを識別するネイティブアプリケーションと通信するサーバーも、任意の盗難アクセストークンを注入できる侵害アプリケーションを攻撃者が作成することで同様に侵害される可能性があります。
リソースに対する有効なアクセストークンを提示できるのはリソースオーナーだけである、という仮定を置く public クライアントは、この種の攻撃に対して脆弱です。
この種の攻撃は、正当なクライアントにおけるリソースオーナーに関する情報を攻撃者、すなわち悪意あるクライアントに露出させる可能性があります。また、最初にアクセストークンまたは認可コードを付与したリソースオーナーと同じ権限で、攻撃者が正当なクライアント上で操作を実行できるようになります。
クライアントに対するリソースオーナー認証はこの仕様の範囲外です。認可プロセスをクライアントへの委任されたエンドユーザー認証の形式として使用する仕様、たとえばサードパーティサインインサービスは、アクセストークンがそのクライアント向けに発行されたかどうかをクライアントが判断できる追加のセキュリティ機構、たとえばアクセストークンの audience 制限なしに、インプリシットフローを使用してはなりません (MUST NOT)。