Zenn
Open2

RFC 9207 OAuth 2.0 Authorization Server Issuer Identification

OAuth
OIDC
yapooyapoo

RFC 9207 - OAuth 2.0 Authorization Server Issuer Identification

本仕様は arXiv.1601.01229 や OAuth 2.0 Security Best Current Practice [1] に記載されている攻撃である IdP Mix-Up Attacks への対策として導入されたものであるから、まずはこの攻撃についてまとめる。

IdP Mix-Up Attacks

この攻撃は以下を前提条件とする

  • クライアントは認可コードフローまたはインプリシットフローを利用している
  • クライアントは複数の認可サーバーに登録しており、そのうちの一つが攻撃者の管理下にある
    • 攻撃者の認可サーバーを A-AS (Attacker Authorization Server)、その他の認可サーバーを H-HS (Honest Authorization Server) とする
  • クライアントは認可エンドポイントで指定するリダイレクト URI を複数の認可サーバーで共通なものにしており、認可コードやアクセストークンを発行した認可サーバーの区別は state パラメータやクライアントがブラウザとの間に作るセッションによって行う

このとき、攻撃者は以下の方法で H-AS の発行した認可コードやアクセストークンを取得することができる。

肝はシーケンス図の 2 の時点でブラウザと A-AS の間のセッションが作られているので、6 でクライアントは受け取った認可コードやアクセストークンを H-AS ではなく A-AS 由来のものと誤認してしまうことである。よってクライアントは 7 でこれらを A-AS に送信してしまい、攻撃者による取得が成功する。

脚注

  1. 2024-05-12 時点でドラフト ↩︎

yapooyapoo

認可レスポンスの iss パラメータ

IdP Mix-Up Attacks への対応として、認可レスポンス (リダイレクト URI へのリダイレクト) にパラメータ iss で issuer (OAuth 2.0 Authorization Server Metadata [1] で定められたもの) を返却する。

クライアントはリダイレクト URI で受け取った iss パラメータが、認可エンドポイントのリクエスト先の issuer と一致していることを確認すれば良い。

以下は Section 2.1 に記載の認可レスポンスの例である

HTTP/1.1 302 Found
Location: https://client.example/cb?
  code=x1848ZT64p4IirMPT0R-X3141MFPTuBX-VFL_cvaplMH58
  &state=ZWVlNDBlYzA1NjdkMDNhYjg3ZjUxZjAyNGQzMTM2NzI
  &iss=https%3A%2F%2Fhonest.as.example

以下は Section 2.2 に記載のエラーレスポンスの例である

HTTP/1.1 302 Found
Location: https://client.example/cb?
  error=access_denied
  &state=N2JjNGJhY2JiZjRhYzA3MGJkMzNmMDE5OWJhZmJhZjA
  &iss=https%3A%2F%2Fhonest.as.example
脚注

  1. RFC 8414 ↩︎