Audience

A value that identifies the party or parties intended to process the assertion. The URL of the token endpoint, as defined in Section of OAuth 2.0 , can be used to indicate that the authorization server is a valid intended audience of the assertion. In the absence of an application profile specifying otherwise, compliant applications MUST compare the Audience values using the Simple String Comparison method defined in Section of RFC 3986 .

Audience

A value that identifies the party intended to process the assertion. The issuer identifier of the authorization server, as defined in , can be used to indicate that the authorization server is a valid intended audience of the assertion.

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 of RFC 4648 and where the padding bits are set to zero. To avoid the need for subsequent encoding steps (by "application/x-www-form-urlencoded" , 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 in the manner described in , it is left to the discretion of their implementers and deployers whether to migrate away from this feature and/or potentially tighten the audience values used in a manner parallel to the changes being made to RFC 7523 by this specification.

The Assertion MUST contain a <Conditions> element with an <AudienceRestriction> element with an <Audience> element that identifies the authorization server as an intended audience. Section 2.5.1.4 of "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0" defines the <AudienceRestriction> and <Audience> elements and, in addition to the URI references discussed there, the token endpoint URL of the authorization server MAY be used as a URI that identifies the authorization server as an intended audience. The authorization server MUST reject any Assertion that does not contain its own identity as the intended audience. In the absence of an application profile specifying otherwise, compliant applications MUST compare the Audience values using the Simple String Comparison method defined in Section of RFC 3986 . As noted in Section , the precise strings to be used as the Audience for a given authorization server must be configured out of band by the authorization server and the issuer of the Assertion.

The Assertion MUST contain a <Conditions> element with an <AudienceRestriction> element with an <Audience> element that identifies the authorization server as the intended audience. The client is responsible for ensuring that the audience of the Assertion is appropriate for the authorization server to which it is sent. This MAY be the issuer identifier of the authorization server, the token endpoint URL of the authorization server, or a SAML Entity ID. Section 2.5.1.4 of "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0" defines the <AudienceRestriction> and <Audience> elements. The authorization server MUST reject any assertion that does not contain its own identity as the intended audience.

The JWT MUST contain an "aud" (audience) claim containing a value that identifies the authorization server as an intended audience. The token endpoint URL of the authorization server MAY be used as a value for an "aud" element to identify the authorization server as an intended audience of the JWT. The authorization server MUST reject any JWT that does not contain its own identity as the intended audience. In the absence of an application profile specifying otherwise, compliant applications MUST compare the audience values using the Simple String Comparison method defined in Section of RFC 3986 . As noted in Section , the precise strings to be used as the audience for a given authorization server must be configured out of band by the authorization server and the issuer of the JWT.

The JWT MUST contain an "aud" (audience) claim containing a value that identifies the authorization server as the intended audience. Two cases are differentiated:

1. For the authorization grant, the client is responsible for ensuring that the audience of the JWT assertion is appropriate for the authorization server to which it is sent. An authorization server MAY be identified by either its issuer identifier or its token endpoint URL.
2. For client authentication, the "aud" (audience) claim value MUST use the issuer identifier of the authorization server as its sole value. The authorization server MUST have an issuer identifier to be used with this specification. The "aud" claim value MUST indicate only the issuer identifier of the intended authorization server as the audience of the JWT; this includes that the token endpoint URL of the authorization server MUST NOT be used as an audience value. The authorization server MUST reject any JWT that does not contain its issuer identifier as its sole audience value.

In the absence of an application profile specifying otherwise, applications MUST compare the audience values using the Simple String Comparison method defined in .

Client authentication JWTs SHOULD be explicitly typed by using the "typ" header parameter value "client-authentication+jwt" or another more specific explicit type value defined by a specification profiling this specification. The introduction of strong typing for JWTs (using explicit "typ" values) serves as a signal to distinguish between tokens produced in accordance with specifications published prior to these updates and those incorporating them. However, the primary security protection comes from the tightened audience requirements. The use of explicit typing enables clients to signal their compliance with the requirements herein. However, since strong typing alone does not prevent the attacks described in and , it is NOT RECOMMENDED for servers to reject JWTs that do not have explicit types. Such rejection would cause interoperability issues with clients that already conform to the tightened audience requirements but have not yet adopted explicit typing. This approach balances security signaling with practical deployment considerations, avoiding disruption to client deployments that already conform to the tightened audience requirements but have not yet adopted explicit typing.

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.

Due to historical reasons, there is potential ambiguity regarding the appropriate audience value to use when employing JWT client assertion-based authentication (defined in with private_key_jwt or client_secret_jwt authentication method names per Section 9 of ). To address that ambiguity, the issuer identifier URL of the authorization server according to SHOULD be used as the value of the audience. In order to facilitate interoperability, the authorization server MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.

Due to historical reasons, there is potential ambiguity regarding the appropriate audience value to use when employing JWT client assertion-based authentication (as defined in and as updated by with the "private_key_jwt" or "client_secret_jwt" authentication method names per Section 9 of ). To address that ambiguity, the issuer identifier URL of the authorization server according to MUST be used as the sole value of the audience. The authorization server MUST reject any such JWT that does not contain its own issuer identifier as the sole audience value. Client authentication JWTs SHOULD be explicitly typed by using the "typ" header parameter value "client-authentication+jwt" or another more specific explicit type value defined by a specification profiling this specification. The introduction of strong typing for JWTs (using explicit "typ" values) serves as a signal to distinguish between tokens produced in accordance with specifications published prior to these updates and those incorporating them. However, the primary security protection comes from the tightened audience requirements. The use of explicit typing enables clients to signal their compliance with the requirements herein. However, since strong typing alone does not prevent the attacks described in and , it is NOT RECOMMENDED for servers to reject JWTs that do not have explicit types. Such rejection would cause interoperability issues with clients that already conform to the tightened audience requirements but have not yet adopted explicit typing. This approach balances security signaling with practical deployment considerations, avoiding disruption to client deployments that already conform to the tightened audience requirements but have not yet adopted explicit typing.