要約

  • RFC 9207がOAuthクライアントに与えるのは限定された受領証である。認可応答の発行者が、その要求のために保存した発行者と完全に一致しなければ、コードを次のendpointへ送る前に処理を打ち切る。
  • issが識別するのは認可サーバーの文脈である。利用者の認証、認可コードの有効性、トークン発行、audienceやscope、リソースサーバーの判断は別の証拠を必要とする。
  • 運用では、要求状態、期待する発行者、メタデータ、受信した発行者、比較結果、コード交換、トークン検証、リソース判断、復旧を別々に記録しなければならない。

危険なコールバックは、異常には見えない。

ブラウザーは登録済みのリダイレクトURIに戻る。stateはクライアントが作成した値と一致する。応答に含まれる認可コードは、誠実な認可サーバーが発行した本物である。パスワードは盗まれておらず、コードも偽造されていない。それでも複数の認可サーバーを扱うクライアントは、本物のコードを攻撃者が管理するtoken endpointへ送るという致命的な経路選択をし得る。

明らかな偽物が一つあるのではない。別々にはもっともらしい二つの記録が、誤って接続されている。最初の記録は、クライアントが要求を始めたときに選んだつもりの認可サーバーを示す。もう一つは利用者のブラウザーを経由して戻った認可応答である。OAuth 2.0の元の応答は、誰がその応答を生成したかを明記していなかった。汎用callbackや悪意あるメタデータが境界を消せば、有効なcredentialが別の運用者の管理面へ移る。

RFC 9207は、この隙間を意図的に小さな要素で塞ぐ。2022年3月にIETF Standards Track文書として公開されたOAuth 2.0 Authorization Server Issuer Identificationは、Karsten Meyer zu SelhausenとDaniel Fettの共同著作である。仕様をサポートする認可サーバーは、成功応答にもエラー応答にもissを入れる。クライアントはその値を、この要求を送った認可サーバーについて保存した発行者識別子と比較する。

一致しなければ応答を拒否し、認可grantを先へ進めてはならない。

フィールドの権限はそこまでであり、その狭さに価値がある。

コールバックには送信者がなかった

OAuthは役割を意図的に分離する。リソース所有者はuser agentを使い、クライアントは認可サーバーにgrantを求める。クライアントは後でtoken endpointへコードを提示し、最後にaccess tokenをリソースサーバーで使う。独立したサービスを組み合わせられる一方、ブラウザーが到着したという事実だけでは安全に決められない経路選択が生まれる。

RFC 6749の認可応答にはコードがあり、要求にstateがあれば同じ値が戻る。stateは重要だ。応答をuser agentの認証済み状態に結び付け、CSRF対策を支える。しかし、「この応答をどの認可サーバーが発行したか」には答えない。

認可サーバーが一つだけなら、代わりのendpoint群がないため差は見えにくい。二つ目を追加すると、クライアントは「保留中のOAuthフローがある」以上の状態を保存しなければならない。そのフローがどの発行者に属するかを記録する必要がある。現在のOAuthセキュリティBest Current PracticeであるRFC 9700は、複数認可サーバーを扱うクライアントにmix-up防止を求め、要求ごとの想定発行者をuser agentへ結び付ける。

Daniel Fettの公開経歴は問題の継続性を示すが、共同仕様を個人の発明物語へ変える根拠ではない。本人のサイトは、identityとWeb protocol securityを専門とし、OAuthとOpenID Connectに取り組むセキュリティコンサルタントだと説明する。2026年9月のIETF記録はRFC 9207を含む四つのRFCを掲げていた。これは研究文脈であり、単独著作や実装支配の証明ではない。

一つの発行者が一組のendpointを指す

発行者識別子は表示名ではない。RFC 8414ではqueryやfragmentを含まないHTTPS URLである。そこから認可サーバーのメタデータ文書を取得し、authorization endpoint、token endpoint、鍵の場所などを確認できる。同じhost上でもpathによって複数の発行者を分けられる。

守るべき対象はこの組み合わせである。利用者が誠実な認可ページを見ていても、クライアントの構成が攻撃者のtoken endpointと組み合わされていることはあり得る。RFC 9700は、authorization endpointのURLだけを保存しても不十分だと警告する。攻撃者は正規の認可URLを自分のサーバーのものだと宣言し、交換先だけを自分の管理下へ向けられる。発行者は、クライアントが使う予定のendpoint群全体を識別する。

RFC 9207はブラウザー経由の応答をその群へ戻す。RFC 8414メタデータを使う場合、応答のissはメタデータのissuerと同一でなければならず、サーバーはauthorization_response_iss_parameter_supportedでサポートを示せる。クライアントは受信値をform encodingからdecodeし、要求に保存した値と単純な文字列比較を行う。

意味が近いだけでは足りない。pathの違い、余分なslash、同じhost上の別発行者は「ほぼ同じ」ではない。人間向けの名前照合ではなく、決定的な経路選択だからである。

権限はローカルに残る。認可サーバーが自分を示し、メタデータがendpoint群を記述し、クライアントが選択、サポート状態、照合、abortを所有する。共通フィールドは最小限の接続面であり、各運用者の将来判断を奪わない。

一致は続行条件であり、完了証明ではない

issの意味を広げると、別の誤りが始まる。

発行者の一致はリソース所有者を認証しない。認可サーバーはまだloginを要求でき、エラーも返せる。利用者がscopeを理解して同意したことも証明しない。それは認可画面と製品ポリシーの責任である。

一致は認可コードを検証しない。正しいtoken endpointを選んだ後でも、endpointはコード、必要なclient authentication、redirect URIなどを確認する。コードは期限切れ、再利用、別クライアント向けである可能性がある。

トークン発行も証明しない。token type、audience、scope、期限、sender constraint、revocation stateは別である。リソースサーバーは提示時に自分の判断を行う。正しいトークンであっても、アプリケーションの処理成功や利用者が見た結果までは示さない。

必要な受領証は順序を持つ。クライアントが要求を作り、発行者をブラウザー状態に結び付けた記録。応答到着。応答のiss。比較とacceptまたはabort。検証済みメタデータからのendpoint選択。コードの受理または拒否。リソースサーバーでのトークン検証と権限判断。最後にアプリケーション結果と復旧証拠である。

RFC 9207が受け持つのは発行者比較である。それを「OAuth成功」と呼べば、後続の全判断を消してしまう。

フィールドは署名ではない

通常の認可応答にあるiss自体は暗号学的に保護されていない。RFC 9207は明記している。フィールドを万能な認証証明書だと誤解しなければ、矛盾ではない。

対象脅威は狭い。mix-upでは、クライアントは侵害されていない認可サーバーの応答を受けるが、コードを送るendpoint群を取り違える。攻撃者が応答をクライアント到着前に書き換えられるなら、認可コードも直接読めるため、mix-upを使う必要がない。issはこのモデルの経路混同を止めるが、あらゆる改ざん耐性を約束しない。

完全性保護が必要なら、発行者を保護された応答へ入れる方法がある。JARMはパラメータを署名JWTに格納する。authorization endpointからID Tokenを返す一部のOpenID Connectフローも、正しく検証すれば発行者を運べる。複数の発行者識別子が食い違えば、応答は拒否される。

これは最小初期仕様の実例である。曖昧さを見えるようにする最小の共通信号を定め、より強い包み方、互換性、移行速度はローカル判断に残す。RFC 9700は発行者ごとに異なるredirect URIを使い、受信場所を検証する別の防御も認める。

レガシー例外には所有者が必要だ

全サーバーが同時に更新されることはない。RFC 9207は普遍的採用を仮定せず、サーバーごとのサポート状態を扱う。

サポートすると分かっているサーバーの応答にissがなければ、クライアントは拒否する。非対応サーバーなら、issなしを受け入れるか、そのサーバーを使わないかをローカルポリシーで決める。サポートを宣言していないサーバーから突然issが来る場合も、構成不一致として明示的に扱う必要がある。

柔軟性は責任の所在を示す。複数発行者クライアントには、発行者一覧、メタデータ、endpoint群、サポート情報の出所と日付、例外、例外所有者、廃止日が要る。廃止日がなければ「互換性」は恒久的な迂回路になる。

二つ目のprovider追加もセキュリティ状態の変更である。単一発行者時代に防御が不要だった事実は、拡張後の安全を保証しない。商用開始前に要求単位の発行者状態をrunning codeへ入れなければならない。

実装が示せる受領証

メタデータを一度読んだだけでは実装結果にならない。運用試験は要求作成から始める。

要求ID、user-agent binding、選択した発行者、メタデータ版、authorizationとtokenの各endpoint、サポートflag、redirect URIを記録する。返却時にはissの有無、decode後の値、期待値、比較結果、不一致時にコード交換が抑止されたかを記録する。成功、エラー、欠落、重複、未知発行者、同一hostの異なるpathを試す。

決定的なのは負の試験だ。不一致後、認可コード、client credential、tokenを含む要求が予期しないendpointへ一件も届かないことを、クライアントとテスト先の両ログで確認する。画面にエラーを出しながらnetwork requestを送っていれば、防御は成立していない。

incidentでも証拠を混ぜない。発行者不一致は比較失敗を示すが、侵害を自動的には証明しない。token endpointの拒否はそのgrantを拒んだ記録であり、応答が攻撃由来だった証拠ではない。リソース拒否から、以前の発行者bindingが正しかったと逆算することもできない。

issが成功するのは、秘密が移動する前に一つの曖昧さを必須の判断へ変えたときである。サーバーの名は示す。しかしトークンと結果の証明は、それぞれの運用者に残る。

情報源