RFC 10070: Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants | RFC Editor

This document updates RFCs 7521, 7522, 7523, and 9126 with respect to the treatment of audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10070.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Multiple OAuth 2.0 specifications use tokens (also known as "assertions") that are sent to authorization servers. These tokens contain audience value(s) that identify the intended recipient(s). When the token is a JSON Web Token (JWT) [RFC7519], the audience value(s) are contained in the "aud" (audience) claim.¶
When performing a security analysis of a pre-final version of the OpenID Federation specification [OpenID.Federation], University of Stuttgart security researchers Pedram Hosseyni, Dr. Ralf Küsters, and Tim Würtele discovered a vulnerability affecting multiple OpenID and OAuth specifications caused by ambiguities in the audience values of tokens sent to authorization servers. The vulnerability was disclosed to the OAuth Working Group in an interim meeting in January 2025 called for that purpose and a description of the vulnerability [private_key_jwt.Disclosure] was provided. A paper they published describing the attack is [Audience.Injection].¶
This specification updates the affected OAuth specifications to address the security vulnerability that was identified. Specifically, it eliminates former choices in the audience values of tokens sent to OAuth 2.0 authorization servers. Section 3.3 of [RFC8414] requires that the client having retrieved the metadata validates the returned issuer value. Other endpoint values of the metadata cannot be directly validated and, if used as the audience when sent to a different endpoint, can open an attack vector.¶
A general description of the updates made is to require that the issuer identifier URL of the authorization server, as defined in [RFC8414], be used as the sole value of the audience of the JWT client authentication assertion. Furthermore, the authorization server rejects any JWT client authentication assertion that does not contain its own issuer identifier as the sole audience value. An explicit type for the JWT client authentication assertion, as defined in [RFC8725], is also defined to facilitate distinguishing between tokens produced in accordance with specifications published prior to these updates and those incorporating them. Specific updates made to each affected specification follow.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
All terms are as defined in the following specifications: "The OAuth 2.0 Authorization Framework" [RFC6749], "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521], and "JSON Web Token (JWT)" [RFC7519].¶
This section updates "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521] to tighten its audience requirements.¶
The description of the Audience parameter in Section 5.1 of [RFC7521] (Assertion Metamodel) is replaced as follows.¶
This section updates "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7522]. It tightens its audience requirements for SAML authorization grants and it deprecates the use of SAML assertions for client authentication.¶
The text and example in Section 2.2 of [RFC7522] (Using SAML Assertions for Client Authentication) is replaced as follows.¶
To use a SAML Bearer Assertion for client authentication, the client uses the following parameter values and encodings.¶
The value of the "client_assertion_type" parameter is "urn:ietf:params:oauth:client-assertion-type:saml2-bearer".¶
The value of the "client_assertion" parameter MUST contain a single SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded using base64url, where the encoding adheres to the definition in Section 5 of RFC 4648 [RFC4648] and where the padding bits are set to zero. To avoid the need for subsequent encoding steps (by "application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the base64url-encoded data SHOULD NOT be line wrapped and pad characters ("=") SHOULD NOT be included.¶
The following example demonstrates a client authenticating using an Assertion during the presentation of an authorization code grant in an access token request (with extra line breaks for display purposes only):¶
SAML Bearer Assertions MUST NOT be used for client authentication for any new applications. Should any applications already be doing this