draft-ietf-oauth-iss-auth-resp-00.md

OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response

draft-ietf-oauth-iss-auth-resp-00 - OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response

Abstract

認可レスポンスに iss パラメータを含める仕様

mix-up 攻撃に対して有効

1. Introduction

Authorization Code Grant だと別々の制御下にある認可サーバと連携することが可能になってしまう

認可レスポンスには認可サーバの身元に関する情報を含まないのでクライアントは確かめようがない

レスポンスの出所についての確実性がないことが mix-up 攻撃をやりやすくしている

認可レスポンスの認可サーバの識別子を返すことで、クライアントはメタデータなどから取得した識別子と比較することができる

2. Response Parameter "iss"

この仕様をサポートする認可サーバーはエラーレスポンスを含む認可レスポンスに iss パラメータを含めなければならない

2.1. Example Authorization Response

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

2.2. Example Error Response

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

2.3. Providing the Issuer Identifier "iss"

クライアントが iss パラメータで検証できるように識別子を提供しなければならない

認可サーバがメタデータを公開している場合

メタデータの issuer と一致しなければならない
メタデータで authorization_response_iss_parameter_supported を true にして iss パラメータで検証できることを示さなければならない

この仕様以外で issuer の識別子をクライアントに提供してもいい

2.4. Validation of the Issuer Identifier "iss"

クライアントでの検証定義

認可レスポンスから iss パラメータの値を抽出する

抽出された値を URL デコードし認可サーバの issuer 識別子と単純文字列比較で比較する

一致しない場合認可レスポンスを拒否して、プロセスを進めてはならない

エラーレスポンスの場合、エラーが意図された認可サーバーから発生したと仮定してはならない

OAuth metadata が利用できない場合、固有の方法（例えば静的な設定から取得）を使用しなければならない

この仕様をサポートするクライアントは iss パラメータのない認可レスポンスを受け入れてもいいし、拒否して iss パラメータをサポートする認可サーバーのみサポートしてもいい

iss パラメータをサポートしないクライアントは iss パラメータを無視しなければならない（エラーにしてはダメ）これは RFC6749 Section 4.1.2 で決まっている。

RFC6479 はおそらく typo で OAuth 2.0 の RFC6749 と思われる

ID Token が認証エンドポイントから返された場合、ID Token 内部の iss クレームと同一であることを比較する

JARM は追加パラメータを禁止しているので JARM を使用する場合は iss パラメータを使用してはならない。そもそも JARM には iss クレームが含まれている

3. Authorization Server Metadata

authorization_response_iss_parameter_supported: 認可サーバーが iss パラメータをサポートしているかどうかの boolean 値。デフォルトは false

4. Security Considerations

iss パラメータは mix-up attack の対策として機能する

複数の認可サーバーが同じ識別子を使うことを許容してはならない

クライアントが手動で認証サーバの設定を行う場合、許容する iss の値が一意になっていることを保証しなければならない

iss パラメータによりフローで例えば Userinfo エンドポイントのようにトークンエンドポイントと一緒に利用されることを期待しているかどうかを決定できる

メタデータを取得して issuer と比較することで他のエンドポイントを確定させることができるということかな

認可レスポンスの iss パラメータは暗号的に保護されていないので一般的には JARM のようなレスポンスの完全性を保護するメカニズムが使用される可能性がある

しかし、mix-up 攻撃ではクライアントは一般的に妥協されていない（許可していないとか意図していないってことかな？）認可サーバーから認可レスポンスを受け取る

もし攻撃者が MITM のように認可レスポンスを改竄できるなら直接認可コードを取得できるので認可コードを取得するために mix-up 攻撃をする必要が無い

なので、認可レスポンスの完全保護は不要

ID Token や JARM のように他の手段で issuer 識別子を取得・検証できるなら iss パラメータを使用・検証する必要は無い。省略してもいい

しかし、複数の issuer 識別子を取得できるような認可レスポンスを受けた場合、クライアントは一致することを確認しなければならず、一致しなければ拒否しなければならない

通常 mix-up 攻撃は複数の認可サーバと連携するクライアントに行われる。1つの認可サーバーとしか連携しないクライアントは将来的に2台目の認可サーバーをサポートする可能性があり、その際に mix-up 攻撃に対して脆弱になる。対策しましょう

pinzolo/draft-ietf-oauth-iss-auth-resp-00.md