Skip to content

OAuth 2.0 Authorization Server Issuer Identification

Internet Engineering Task Force (IETF)             K. Meyer zu Selhausen  
Request for Comments: 9207                                     Hackmanit  
Category: Standards Track                                        D. Fett  
ISSN: 2070-1721                                                  yes.com  
                                                              March 2022

Abstract

本文書は、iss と呼ばれる新しいパラメータを規定する。このパラメータは、OAuth の認可フローの認可レスポンスにおいて、Authorization Server の発行者識別子を明示的に含めるために用いられる。iss パラメータは、「mix-up attacks」に対する有効な対策として機能する。

Status of This Memo

本文書は Internet Standards Track の文書である。

本文書は Internet Engineering Task Force (IETF) の成果物である。本文書は IETF コミュニティの合意を表している。公開レビューを受け、Internet Engineering Steering Group (IESG) により公開が承認された。Internet Standards に関する詳細は RFC 7841 の Section 2 にある。

本文書の現在の状況、正誤表、およびフィードバックの提供方法に関する情報は、以下から入手できる。\ https://www.rfc-editor.org/info/rfc9207.

Copyright (c) 2022 IETF Trust および本文書の著者として特定された者。All rights reserved.

本文書は、本文書の公開日に有効な BCP 78 および IETF Trust の「IETF Documents に関する Legal Provisions」\ (https://trustee.ietf.org/license-info) の適用を受ける。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認すること。本文書から抽出された Code Components は、Trust Legal Provisions の Section 4.e に記載された Revised BSD License の本文を含めなければならず、また Revised BSD License に記載されているとおり無保証で提供される。

Table of Contents

1. Introduction

OAuth 2.0 Authorization Framework [RFC6749] は、別々の主体の管理下にある複数の独立した Authorization Server とクライアントが相互にやり取りできるようにする。いくつかの OAuth の grant type では、resource owner の user agent を利用して、Authorization Server のレスポンスを OAuth クライアントへ届ける。このパターンの一例が、authorization code grant の authorization response である。

[RFC6749] の Section 4.1.2 で規定された authorization response には、そのレスポンスを発行した Authorization Server の識別情報が含まれていない。したがって、resource owner's user agent からレスポンスを受け取るクライアントは、そのレスポンスおよびそこに含まれる秘密情報を、そもそも誰が発行したのかを確実に判断できない。レスポンスの出所について確実性が欠けていることにより、「mix-up attacks」と呼ばれる種類の攻撃が可能になる。

Mix-up attacks は、複数の Authorization Server とやり取りするすべての OAuth クライアントにとって潜在的な脅威である。これらの Authorization Server のうち少なくとも 1 つが攻撃者の支配下にある場合、攻撃者は mix-up attack を仕掛けて、他の Authorization Server のいずれかが発行した Authorization Code や Access Token を取得できる。攻撃者がクライアントがサポートする Authorization Server を支配できる経路は複数ある。たとえば、Authorization Server が侵害される場合があるし、あるいは攻撃者が dynamic client registration [RFC7591] を用いるなどして、自身の Authorization Server を登録することもできる。

1 つの Authorization Server としかやり取りしない OAuth クライアントは、mix-up attacks の影響を受けない。しかし、そのようなクライアントが将来 2 つ目の Authorization Server のサポートを追加することを決めた場合、脆弱となり、mix-up attacks への対策を適用する必要が生じる。

Mix-up attacks は、正当な Authorization Server または Resource Server の代わりに、Authorization Code または Access Token を攻撃者へ送信するようクライアントをだまして、Authorization Code または Access Token を盗み取ることを目的とする。これは、OAuth によってアクセス管理されるリソースの機密性と完全性に対する深刻な脅威である。mix-up attack クラスの詳細な説明および異なる亜種は、「OAuth 2.0 Security Best Current Practice」[OAUTH-SECURITY-TOPICS] の Section 4.4 にあるほか、この攻撃クラスを最初に強調した元の研究である「On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect」[arXiv.1508.04324] および「A Comprehensive Formal Security Analysis of OAuth 2.0」[arXiv.1601.01229] にも記載されている。

本文書は、authorization response における iss という新しいパラメータを定義する。iss パラメータにより、Authorization Server は、自身の識別情報を authorization response に明示的に含められる。クライアントは、iss パラメータの値を、（たとえばメタデータから取得した）自分がやり取りしていると考えている Authorization Server の issuer identifier と比較できる。iss パラメータによってクライアントは Authorization Server の識別に確実性を得られ、Authorization Code や Access Token のようなクレデンシャルを意図した受領者にのみ送ることが可能になる。

Mix-up attacks に対する iss パラメータの有効性は、「A Comprehensive Formal Security Analysis of OAuth 2.0」[arXiv.1601.01229] において分析され、形式的に証明されている。

1.1. Conventions and Terminology

本文書中のキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、ここに示すようにすべて大文字で出現する場合に限り、BCP 14 [RFC2119] [RFC8174] に記載されたとおりに解釈される。

本仕様は、OAuth 2.0 Authorization Framework [RFC6749] で定義された「access token」「authorization code」「authorization code grant」「authorization server」「resource server」「authorization response」「grant type」「client」という用語を使用する。「issuer identifier」という用語は、OAuth 2.0 Authorization Server Metadata [RFC8414] により定義される。

2. Response Parameter iss

エラーレスポンスを含むクライアントへの authorization response において、本仕様をサポートする Authorization Server は、レスポンスに iss パラメータを含めることで自身の識別情報を示さなければならない。

iss パラメータの値は、[RFC8414] で定義された、authorization response を作成した Authorization Server の issuer identifier である。その値は、「https」スキームを使用し、query または fragment の構成要素を含まない URL でなければならない。

2.1. Example Authorization Response

次の例は、issuer identifier が https://honest.as.example である Authorization Server からの 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

次の例は、同じ Authorization Server からのエラーレスポンスを示す（余分な改行とインデントは表示目的のみ）:

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

2.3. Providing the Issuer Identifier

本仕様をサポートする Authorization Server は、クライアントが iss パラメータを効果的に検証できるように、issuer identifier を提供しなければならない。

[RFC8414] に従ってメタデータを公開する Authorization Server については、次の規則が適用される:

  • サーバのメタデータ内の issuer の値に含まれる issuer identifier は、iss パラメータの値と同一でなければならない。
  • サーバは、Section 3 で定義されたメタデータパラメータ authorization_response_iss_parameter_supported を true に設定することで、iss パラメータのサポートを示さなければならない。

Authorization Server は、さらに別の仕組みによって issuer identifier をクライアントへ提供してもよいが、それは本仕様の対象範囲外である。

2.4. Validating the Issuer Identifier

本仕様をサポートするクライアントは、iss パラメータが存在する場合、受信した authorization response から iss パラメータの値を抽出しなければならない。次にクライアントは、[RFC6749] の Appendix B に従い、その値を「application/x-www-form-urlencoded」形式からデコードし、authorization request を送信した Authorization Server の issuer identifier と比較しなければならない。この比較は、[RFC3986] の Section 6.2.1 で定義された単純な文字列比較を用いなければならない。値が期待される issuer identifier と一致しない場合、クライアントは authorization response を拒否しなければならず、authorization grant を進めてはならない。エラーレスポンスについて、クライアントは、そのエラーが意図した Authorization Server に由来すると仮定してはならない。

より正確には、[RFC8414] の OAuth メタデータをサポートする Authorization Server とやり取りするクライアントは、iss パラメータの値をサーバのメタデータ文書の issuer の値と比較しなければならない。OAuth メタデータを使用しない場合、クライアントは、返された iss の値が現在のフローにおける期待値であるかどうかを判断するために、配備固有の方法（たとえば静的な設定）を用いなければならない（Section 4 も参照）。

クライアントが、本仕様をサポートする Authorization Server と、本仕様をサポートしない Authorization Server の両方とやり取りする場合、各 Authorization Server が iss パラメータをサポートしているかどうかについて、状態を保持しなければならない。クライアントは、そのクライアント設定に従い iss パラメータをサポートしている Authorization Server から、iss パラメータを含まない authorization response を受け取った場合、そのレスポンスを拒否しなければならない。クライアントは、iss パラメータのサポートを示していない Authorization Server から iss パラメータを含む authorization response を受け取った場合、そのレスポンスを破棄することが望ましい。しかし、メタデータでサポートを示していないにもかかわらず iss パラメータを提供する正当な Authorization Server が存在し得る。そのようなレスポンスを受け入れるかどうかは、ローカルのポリシーまたは設定で決定でき、具体的な指針は本仕様の対象範囲外である。

一般に、本仕様をサポートするクライアントは、iss パラメータを含まない authorization response を受け入れてもよいし、それらを拒否して、authorization response に iss パラメータを提供する Authorization Server のみを排他的にサポートしてもよい。そのようなレスポンスをいつ受け入れるかは、ローカルのポリシーまたは設定で決定でき、具体的な指針は本仕様の対象範囲外である。

authorization endpoint から ID Token が返される OpenID Connect (OIDC.Core) のフローでは、iss パラメータの値は常に ID Token の iss claim と同一でなければならない。

[RFC6749] の Section 4.1.2 は、すでに、本仕様をサポートしないクライアントが、認識できない iss パラメータを無視しなければならないことを義務付けている。

注: 「JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)」[JARM] は、すべての authorization response パラメータを JSON Web Token (JWT) の中で運ぶ仕組みを定義している。この JWT には、Section 2.4 で記載されたとおりに検証されるなら同等の保護を提供する iss claim が含まれる。したがって、JARM が使用される場合、JWT の外側に追加の iss パラメータは不要である。

3. Authorization Server Metadata

Authorization Server が本仕様をサポートしていることを示すために、Authorization Server メタデータ [RFC8414] に次のパラメータが導入される:

  • authorization_response_iss_parameter_supported: Section 2 で定義されたとおり、authorization response に iss パラメータを提供するかどうかを示す Boolean パラメータ。省略された場合、既定値は false である。

4. Security Considerations

クライアントは、Section 2.4 に記載されたとおりに iss パラメータを正確に検証しなければならず、複数の Authorization Server が同一の issuer identifier を使用することを許してはならない。特に、Authorization Server の詳細をクライアントで手動設定できる場合、クライアントは、受け入れる iss の値が Authorization Server ごとに一意であることを確実にしなければならない。

iss パラメータにより、クライアントは、ある Authorization Server が、特定の token endpoint および userinfo endpoint [OIDC.Core] のような他の endpoint と組み合わせて OAuth フローで使用されることを「想定している」かどうかを判断できる。OAuth メタデータを使用する場合、iss パラメータは issuer を識別し、したがって他の endpoint を指し示す該当の OAuth メタデータ文書を特定する。OAuth メタデータを使用しない場合、クライアントは、たとえば、設定された Authorization Server ごとに静的に設定された期待 iss 値を用いることができる。

authorization response に含まれる issuer identifier は、改ざんに対して暗号学的に保護されていない。一般に、（[JARM] で規定される）JWT のような仕組みを用いて authorization response の完全性を保護できる。しかし mix-up attacks では、クライアントは通常、侵害されていない Authorization Server から authorization response を受け取る。もし攻撃者が、クライアントが受け取る前にこの authorization response を改ざんできるのであれば、攻撃者は Authorization Code へ直接アクセスできることになる。攻撃者は Authorization Code を盗むために mix-up attack を実行する必要がない。したがって、mix-up attacks に対抗するために authorization response の完全性保護は不要である。

Mix-up attacks に対しては、他にも代替の対策がある。authorization response がすでに別の手段で Authorization Server の issuer identifier を含んでおり、その識別子が Section 2.4 に示したとおりに確認される場合、iss パラメータの使用および検証は不要であり、省略してもよい。たとえば、authorization endpoint から ID Token を返す OpenID Connect の response type（例: response_type=code id_token）や [JARM] を使用する場合がこれに当たる。ただし、クライアントが複数の issuer identifier を含む authorization response を受け取った場合、これらの issuer identifier が一致しないときは、そのレスポンスを拒否しなければならない。代替対策の詳細は本仕様の対象範囲外である。

Mix-up attacks は、複数の Authorization Server とやり取りするクライアントにのみ関係する。しかし、1 つの Authorization Server とだけやり取りするクライアントであっても、将来 2 つ目の Authorization Server をサポートすることがある。複数の Authorization Server をサポートすることで、mix-up attacks に対して脆弱になり、対策を適用する必要が生じる。

5. IANA Considerations

5.1. OAuth Authorization Server Metadata

IANA は、[RFC8414] により確立された [IANA.OAuth.Parameters] の「OAuth Authorization Server Metadata」レジストリに、以下の値を登録した。

  • Metadata Name: authorization_response_iss_parameter_supported
  • Metadata Description: authorization response に iss パラメータを提供するかどうかを示す Boolean 値。
  • Change Controller: IETF
  • Specification Document(s): RFC 9207 の Section 3

5.2. OAuth Parameters Registration

IANA は、[RFC6749] により確立された [IANA.OAuth.Parameters] の「OAuth Parameters」レジストリにおいて、iss エントリを以下のとおり更新した。

  • Parameter name: iss
  • Parameter usage location: authorization request, authorization response
  • Change Controller: IETF
  • Specification Document(s): RFC 9207 の Section 2、[RFC9101]、および [RFC7519] の Section 4.1.1。

6. References

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\ Requirement Levels", BCP 14, RFC 2119,\ DOI 10.17487/RFC2119, March 1997,\ https://www.rfc-editor.org/info/rfc2119.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform\ Resource Identifier (URI): Generic Syntax", STD 66,\ RFC 3986, DOI 10.17487/RFC3986, January 2005,\ https://www.rfc-editor.org/info/rfc3986.

[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",\ RFC 6749, DOI 10.17487/RFC6749, October 2012,\ https://www.rfc-editor.org/info/rfc6749.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC\ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\ May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0\ Authorization Server Metadata", RFC 8414,\ DOI 10.17487/RFC8414, June 2018,\ https://www.rfc-editor.org/info/rfc8414.

6.2. Informative References

[arXiv.1508.04324]\ Mainka, C., Mladenov, V., and J. Schwenk, "On the security\ of modern Single Sign-On Protocols: Second-Order\ Vulnerabilities in OpenID Connect", August 2015,\ https://arxiv.org/abs/1508.04324.

[arXiv.1601.01229]\ Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive\ Formal Security Analysis of OAuth 2.0",\ DOI 10.1145/2976749.2978385, January 2016,\ https://arxiv.org/abs/1601.01229.

[IANA.OAuth.Parameters]\ IANA, "OAuth Parameters",\ https://www.iana.org/assignments/oauth-parameters.

[JARM] Lodderstedt, T. and B. Campbell, "Financial-grade API: JWT\ Secured Authorization Response Mode for OAuth 2.0 (JARM)",\ October 2018,\ https://openid.net/specs/openid-financial-api-jarm.html.

[OAUTH-SECURITY-TOPICS]\ Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,\ "OAuth 2.0 Security Best Current Practice", Work in\ Progress, Internet-Draft, draft-ietf-oauth-security-\ topics-19, 16 December 2021,\ https://datatracker.ietf.org/doc/html/draft-ietf-oauth-\ security-topics-19.

[OIDC.Core]\ Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and\ C. Mortimore, "OpenID Connect Core 1.0 incorporating\ errata set 1", November 2014,\ https://openid.net/specs/openid-connect-core-1_0.html.

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token\ (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,\ https://www.rfc-editor.org/info/rfc7519.

[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and\ P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",\ RFC 7591, DOI 10.17487/RFC7591, July 2015,\ https://www.rfc-editor.org/info/rfc7591.

[RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0\ Authorization Framework: JWT-Secured Authorization Request\ (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021,\ https://www.rfc-editor.org/info/rfc9101.

Acknowledgements

本文書への貴重なフィードバックに対し、Brian Campbell、Roman Danyliw、Vladimir Dzhuvinov、Joseph Heenan、Takahiko Kawasaki、Torsten Lodderstedt、Christian Mainka、Vladislav Mladenov、Warren Parad、Aaron Parecki、Rifaat Shekh-Yusef に感謝する。

Authors' Addresses

Karsten Meyer zu Selhausen\ Hackmanit\ Email: karsten.meyerzuselhausen@hackmanit.de

Daniel Fett\ yes.com\ Email: mail@danielfett.de