Skip to content 
OAuth Working Group                                           M.B. Jones
Internet-Draft                                    Self-Issued Consulting
Updates: 7521, 7522, 7523, 9126 (if approved)                B. Campbell
Intended status: Standards Track                           Ping Identity
Expires: 23 January 2026                                    C. Mortimore
                                                                  Disney
                                                               F. Skokan
                                                                    Okta
                                                            22 July 2025

Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants

draft-ietf-oauth-rfc7523bis-03

Abstract

本仕様は、OAuth 2.0 Client Assertion Authentication および Assertion-based Authorization Grants における audience 値の要件を更新するものであり、複数の OAuth 2.0 仕様におけるこれら audience 値の従来の要件において特定されたセキュリティ脆弱性に対処するものである。

Status of This Memo

本 Internet-Draft は、BCP 78 および BCP 79 の規定に完全に準拠して提出されている。

Internet-Draft は Internet Engineering Task Force (IETF) の作業文書である。他のグループも作業文書を Internet-Draft として配布する場合があることに注意されたい。現在の Internet-Draft のリストは https://datatracker.ietf.org/drafts/current/ にある。

Internet-Draft は最大 6 ヶ月間有効なドラフト文書であり、いつでも他の文書によって更新、置換、または廃止される可能性がある。Internet-Draft を参照資料として使用すること、または「進行中の作業 (work in progress)」以外として引用することは不適切である。

本 Internet-Draft は 2026 年 1 月 23 日に失効する。

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

本書は、BCP 78 および本書の発行日において有効な IETF Documents に関する IETF Trust の法的規定 (https://trustee.ietf.org/license-info) の対象となる。

これらの文書には、本書に関する権利と制限が記載されているため、注意深く確認されたい。本書から抽出されたコードコンポーネントは、Trust 法的規定のセクション 4.e に記載されている Revised BSD License テキストを含まなければならず、Revised BSD License に記載されているように保証なしで提供される。

Table of Contents

1. Introduction

複数の OAuth 2.0 仕様において、Authorization Server に送信されるトークン（「アサーション」としても知られる）が使用されている。これらのトークンには、トークンの対象となる受信者を識別することを意図した audience 値が含まれている。トークンが JSON Web Token (JWT) [JWT] である場合、audience 値は aud (audience) claims に含まれる。

OpenID Federation 仕様 [OpenID.Federation] のプレファイナル版のセキュリティ分析を行っていた際、シュトゥットガルト大学のセキュリティ研究者である Pedram Hosseyni、Ralf Küsters 博士、Tim Würtele は、Authorization Server に送信されるトークンの audience 値の曖昧さに起因し、複数の OpenID および OAuth 仕様に影響を与える脆弱性を発見した。この脆弱性は、2025 年 1 月にこの目的のために招集された暫定会議において、脆弱性の説明 [private_key_jwt.Disclosure] と共に OAuth Working Group に開示された。攻撃について記述した彼らの論文は [Audience.Injection] である。

本仕様は、特定されたセキュリティ脆弱性に対処するために、影響を受ける OAuth 仕様を更新する。具体的には、OAuth 2.0 Authorization Server に送信されるトークンの audience 値における従来の曖昧さを排除する。

行われた更新の概要を述べると、[RFC8414] で定義されている Authorization Server の issuer identifier URL を、JWT クライアント認証アサーションの audience の唯一の値として使用することを要求するものである。さらに、Authorization Server は、自身の issuer identifier を唯一の audience 値として含まない JWT クライアント認証アサーションを拒否する。[RFC8725] で定義されている、影響を受ける各種類のトークンの明示的な型 (type) も定義され、これらの更新より前に公開された仕様に従って生成されたトークンと、これらを取り入れたトークンとの区別を容易にする。影響を受ける各仕様に対する具体的な更新内容は以下の通りである。

1.1. Notational Conventions

本文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174] に記載されているように解釈されるべきものである（すべて大文字で表記されている場合のみ）。

1.2. Terminology

すべての用語は、以下の仕様で定義されている通りである："The OAuth 2.0 Authorization Framework" [RFC6749]、"Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521]、および "JSON Web Token (JWT)" [JWT]。

2. Updates to RFC 7521

本セクションは、"Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521] を更新し、その audience 要件を厳格化する。

[RFC7521] の Section 5.1 (Assertion Metamodel) における Audience パラメータの説明を以下のように置き換える：

Audience

アサーションを処理することを意図されたパーティを識別する値。[RFC8414] で定義される Authorization Server の issuer identifier を使用して、Authorization Server がアサーションの有効な意図された audience であることを示すことができる。

3. Updates to RFC 7522

本セクションは、"Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7522] を更新する。これにより、SAML Authorization Grant における audience 要件を厳格化し、クライアント認証への SAML アサーションの使用を廃止（非推奨に）する。

[RFC7522] の Section 2.2 (Using SAML Assertions for Client Authentication) におけるテキストと例を以下のように置き換える：

クライアント認証には SAML Bearer Assertions を使用しないことが推奨される (RECOMMENDED)。

[RFC7522] の Section 3 (Assertion Format and Processing Requirements) の項目 2 における Audience 要素の説明を以下のように置き換える：

Assertion は、Authorization Server を意図された audience として識別する <Audience> 要素を持つ <AudienceRestriction> 要素を含む <Conditions> 要素を含まなければならない (MUST)。クライアントは、Assertion の audience が、送信先の Authorization Server にとって適切であることを保証する責任がある。これは、Authorization Server の issuer identifier、Authorization Server の token endpoint URL、または SAML Entity ID であってもよい (MAY)。"Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0" [OASIS.saml-core-2.0-os] の Section 2.5.1.4 は、<AudienceRestriction> および <Audience> 要素を定義している。Authorization Server は、意図された audience として自身のアイデンティティを含まないいかなるアサーションも拒否しなければならない (MUST)。

4. Updates to RFC 7523

本セクションは、"JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7523] を更新し、その audience 要件を厳格化する。

[RFC7523] の Section 3 (JWT Format and Processing Requirements) において、audience 値について記述している項目 3 を以下のように置き換える：

JWT は、Authorization Server を意図された audience として識別する値を含む aud (audience) claims を含まなければならない (MUST)。以下の 2 つのケースが区別される：

a. Authorization Grant の場合、クライアントは JWT アサーションの audience が、送信先の Authorization Server にとって適切であることを保証する責任がある。Authorization Server は、その issuer identifier またはその token endpoint URL のいずれかによって識別されてもよい (MAY)。

b. クライアント認証の場合、aud (audience) claims 値は、Authorization Server の issuer identifier [RFC8414] を唯一の値として使用しなければならない (MUST)。Authorization Server は、本仕様で使用するための issuer identifier を持っていなければならない (MUST)。[RFC7523] で指定された aud 値とは異なり、意図された Authorization Server の issuer identifier 以外の値を JWT の audience として使用してはならない (MUST)。これには、Authorization Server の token endpoint URL を audience 値として使用してはならない (MUST NOT) ことも含まれる。Authorization Server は、その issuer identifier を唯一の audience 値として含まないいかなる JWT も拒否しなければならない (MUST)。

アプリケーションプロファイルで別段の指定がない限り、アプリケーションは RFC 3986 [RFC3986] の Section 6.2.1 で定義されている単純文字列比較法 (Simple String Comparison method) を使用して audience 値を比較しなければならない (MUST)。

[RFC7523] の Section 3.2 (Client Authentication Processing) に、以下の要件を追加する：

クライアント認証 JWT は、typ ヘッダーパラメータ値 client-authentication+jwt または本仕様をプロファイルする仕様によって定義された、より具体的で明示的な型 (type) 値を使用して、明示的に型付けされるべきである (SHOULD)。

[RFC7523] の Section 4 (Authorization Grant Example) において、以下の文：

The intended audience of the JWT is https://jwt-rp.example.net, which is an identifier with which the authorization server identifies itself.

を以下のように置き換える：

The intended audience of the JWT is https://authz.example.net, which is the authorization server's issuer identifier.

同セクションにおいて、JWT Claims Set の例を以下のように置き換える：

{
  "aud": "[https://authz.example.net](https://authz.example.net)",
  "iss": "[https://jwt-idp.example.com](https://jwt-idp.example.com)",
  "sub": "mailto:mike@example.com",
  "iat": 1731721541,
  "exp": 1731725141,
  "[http://claims.example.com/member](http://claims.example.com/member)": true
}

Figure 1: Example JWT Claims Set

[RFC7523] の Section 5 (Interoperability Considerations) における参加者に要求される合意事項のリストにおいて、「audience identifiers」に関する合意は、クライアント認証 JWT にはもはや不要である。

以下のサブセクションにある追加の例を、[RFC7523] の Section 4 の後に追加する。

4.1. Client Authentication JWT Example

以下の例は、クライアント認証 JWT とそれを使用したトークンリクエストがどのようなものかを示している。

この例では、https://client.example/ として識別される OAuth client によって発行および署名された JWT を示している。JWT の意図された audience は https://authz.example.net であり、これは Authorization Server の issuer identifier である。JWT は Authorization Server の token endpoint (https://authz.example.net/token.oauth2) へのトークンリクエストの一部として送信される。

以下は、クライアント認証 JWT のための JWT Claims Set を生成するためにエンコードされ得る JSON オブジェクトの例である：

{
  "aud": "[https://authz.example.net](https://authz.example.net)",
  "iss": "[https://client.example/](https://client.example/)",
  "sub": "[https://client.example/](https://client.example/)",
  "iat": 1752702206,
  "exp": 1752705806
}

JWT のヘッダーパラメータとして使用される以下の JSON オブジェクトの例は、JWT がクライアント認証 JWT であること、SHA-256 を用いた Elliptic Curve Digital Signature Algorithm (ECDSA) P-256 (ES256) で署名されていること、および kid 値 16 で識別される鍵で署名されたことを宣言している。

{
  "typ": "client-authentication+jwt",
  "alg": "ES256",
  "kid": "16"
}

上記の claims とヘッダーパラメータを持つ JWT を、例えば Access Token リクエストの一部として提示するために、クライアントは以下のような HTTPS リクエストを行うことができる（表示目的でのみ改行を追加している）：

POST /token.oauth2 HTTP/1.1
Host: authz.example.net
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=eyJ0eXAiOiJjbGllbnQtYXV0aGVudGljYXRpb24rand0IiwiYWx
  nIjoiRVMyNTYiLCJraWQiOiIxNiJ9.eyJhdWQiOiAiaHR0cHM6Ly9hdXRoei5leGFt
  cGxlLm5ldCIsImlzcyI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLyIsInN1YiI6IC
  JodHRwczovL2NsaWVudC5leGFtcGxlLyIsImlhdCI6IDE3NTI3MDIyMDYsImV4cCI6
  IDE3NTI3MDU4MDZ9.6KrSQUxdl9ehs[...omitted for brevity...]bwc0ZOJw

5. Updates to RFC 9126

本セクションは、"OAuth 2.0 Pushed Authorization Requests" [RFC9126] を更新し、その audience 要件を厳格化する。

[RFC9126] の Section 2 (Pushed Authorization Request Endpoint) における audience 値を説明する段落を以下のように置き換える：

この更新は、[RFC9126] で記述されていた JWT クライアントアサーションベースの認証（[RFC7523] の Section 2.2 で定義され、Section 4 で更新されたもの。認証方式名は [OpenID.Core] の Section 9 に従い private_key_jwt または client_secret_jwt とする）を採用する際に使用すべき適切な audience 値に関する潜在的な曖昧さを解決する。その曖昧さに対処するため、[RFC8414] に従う Authorization Server の issuer identifier URL を、audience の唯一の値として使用しなければならない (MUST)。Authorization Server は、自身の issuer identifier を唯一の audience 値として含まないそのような JWT を拒否しなければならない (MUST)。

JWT に対する強力な型付け（明示的な typ 値の使用）の導入は、これらの更新より前に公開された仕様に従って生成されたトークンと、これらを取り入れたトークンとを区別するためのシグナルとして機能する。しかし、主要なセキュリティ保護は、厳格化された audience 要件からもたらされる。[private_key_jwt.Disclosure] および [Audience.Injection] で記述されている攻撃は、強力な型付けだけでは防ぐことができないため、明示的な型付けの使用は、本仕様の要件に準拠した JWT を送信する意図をシグナルできるようにするための、クライアントへの提案である。このアプローチは、セキュリティシグナリングと実際の展開上の考慮事項とのバランスを取り、厳格化された audience 要件には既に準拠しているが、明示的な型付けをまだ採用していないクライアントの展開への混乱を回避する。

6. Security Considerations

以下の仕様内で記述されているセキュリティ上の考慮事項はすべて、本文書に適用される："Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521]、"Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7522]、"JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7523]、"OAuth 2.0 Pushed Authorization Requests" [RFC9126]、"The OAuth 2.0 Authorization Framework" [RFC6749]、および "JSON Web Token (JWT)" [JWT]。

本仕様は、[RFC7521]、[RFC7522]、[RFC7523]、および [RFC9126] によって以前許容されていた audience の曖昧さを悪用することから生じ得る攻撃を防ぐために、トークンの audience 要件を厳格化する。これらの攻撃については [private_key_jwt.Disclosure] および [Audience.Injection] で記述されている。

7. IANA Considerations

7.1. Media Type Registration

本セクションは、[RFC6838] で記述されている方法で、"Media Types" レジストリ [IANA.MediaTypes] に以下のメディアタイプ [RFC2046] を登録する。

7.1.1. Registry Contents

  • Type name: application
  • Subtype name: client-authentication+jwt
  • Required parameters: なし
  • Optional parameters: なし
  • Encoding considerations: バイナリ; クライアント認証 JWT は JWT である; JWT 値は、ピリオド ('.') 文字で区切られた一連の base64url エンコードされた値（一部は空文字列の場合がある）としてエンコードされる。
  • Security considerations: 本仕様の Section 6 を参照
  • Interoperability considerations: なし
  • Published specification: 本仕様の Section 4
  • Applications that use this media type: 本仕様を使用するアプリケーション
  • Fragment identifier considerations: なし
  • Additional information:
    • Magic number(s): なし
    • File extension(s): なし
    • Macintosh file type code(s): なし
  • Person & email address to contact for further information: Michael B. Jones, michael_b_jones@hotmail.com
  • Intended usage: COMMON
  • Restrictions on usage: なし
  • Author: Michael B. Jones, michael_b_jones@hotmail.com
  • Change controller: IETF
  • Provisional registration?: No

7.2. OAuth Token Endpoint Authentication Methods

本セクションは、[IANA.OAuthParameters] の "OAuth Token Endpoint Authentication Methods" レジストリのエントリを更新する。

7.2.1. Registry Contents

  • Token Endpoint Authentication Method Name: private_key_jwt
  • Change Controller: IETF
  • Reference: [OpenID.Core] の Section 9, [[本仕様]]
  • Token Endpoint Authentication Method Name: client_secret_jwt
  • Change Controller: IETF
  • Reference: [OpenID.Core] の Section 9, [[本仕様]]

7.3. OAuth URI Registration Updates

本セクションは、[IANA.OAuthParameters] の "OAuth URI" レジストリにおける以下のエントリに対し、追加の参照として [[本仕様]] を追加するよう更新を要求する。

  • urn:ietf:params:oauth:grant-type:jwt-bearer
  • urn:ietf:params:oauth:client-assertion-type:jwt-bearer
  • urn:ietf:params:oauth:grant-type:saml2-bearer
  • urn:ietf:params:oauth:client-assertion-type:saml2-bearer

8. References

8.1. Normative References

8.2. Informative References

Appendix A. Document History

[[ RFC として公開される前に RFC Editor によって削除される予定 ]]

-03

  • 本仕様への参照を追加して OAuth Token Endpoint Authentication Methods IANA エントリを更新。
  • 強力な型付け (strong typed) された JWT を使用するクライアント要件を緩和。MUST ではなく SHOULD とした。
  • "aud" claims の型 (type) を制限しない。単一のメンバーを持つ配列であることを許可する。
  • アサーション Authorization Grant の audience が、送信先に対して意味をなすものであることを確認するようクライアントに助言する。
  • 作業のよりターゲットを絞った範囲を（期待される通りに）より適切に反映するために、概要と導入部を更新。
  • クライアント認証用 JWT の例の置き換えを削除（エンコードされた JWT ヘッダーに typ を含める価値がないため）。
  • 既存の OAuth URI 登録を更新し、関連する 4 つの URN について本仕様への参照を追加する要求を追加。
  • 新しいクライアント認証 JWT の例を修正。

-02

  • Filip Skokan を著者として追加。
  • IETF 122 でなされた Brian Campbell の提案を適用。 具体的には：
    • RFC 7523 の更新を JWT クライアント認証のケースに焦点を当てたものにした。
    • Authorization Grants の audience 値に対するクライアントの責任について記述した。破壊的な変更を最小限に抑えるため、Authorization Grants の audience が issuer identifier であることをもはや義務付けない。
    • クライアント認証への SAML アサーションの使用を廃止（非推奨に）した。

-01

  • RFC 7523 を置き換えるのではなく、更新するように作り直した。
  • RFC 9101 への更新を削除した。
  • シュトゥットガルト大学の論文 [Audience.Injection] への参照を追加した。

-00

  • 初期のワーキンググループドラフト。draft-jones-oauth-rfc7523bis-00 を置き換える。

Acknowledgements

本仕様への以下の人々の貢献に感謝の意を表したい：Brock Allen、John Bradley、Ralph Bragg、Joseph Heenan、Pedram Hosseyni、Pieter Kasselman、Ralf Küsters、Martin Lindström、Aaron Parecki、Dean H. Saxe、Arndt Schwenkschuster、および Tim Würtele。

Authors' Addresses

Michael B. Jones Self-Issued Consulting Email: michael_b_jones@hotmail.com URI: https://self-issued.info/

Brian Campbell Ping Identity Email: bcampbell@pingidentity.com

Chuck Mortimore Disney Email: charliemortimore@gmail.com

Filip Skokan Okta Email: panva.ip@gmail.com