oauth-wg / oauth-v2-1

OAuth 2.1 is a consolidation of the core OAuth 2.0 specs
https://oauth.net/2.1/
Other
52 stars 27 forks source link

Clarify `aud` values that should be accepted in `private_key_jwt` at the token (and other) endpoints #183

Open jogu opened 4 months ago

jogu commented 4 months ago

There's some unfortunate history around the aud value that you use in private_key_jwt client authentication assertions.

RFC7523 says:

        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

The WG already tried to be a bit more specific, e.g. in PAR we say the issuer value 'SHOULD' be used and 'MUST' be accepted:

Due to historical reasons, there is potential ambiguity regarding the appropriate audience value to use when employing JWT client assertion-based authentication (defined in Section 2.2 of [RFC7523] with private_key_jwt or client_secret_jwt authentication method names per Section 9 of [OIDC]). To address that ambiguity, the issuer identifier URL of the authorization server according to [RFC8414] 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.

It seems like we could add something in OAuth 2.1 to try and help people get this working in an interoperable fashion. Somewhere in https://drafts.oauth.net/oauth-v2-1/draft-ietf-oauth-v2-1.html#section-2.4 would seem like a possible place to offer a clarification. Perhaps something along the lines of:

When using private_key_jwt, In order to facilitate interoperability, the authorization server MUST accept its issuer identifier, token endpoint URL, or the endpoint URL that the assertion is being presented to as aud values that identify it as an intended audience.

bc-pi commented 4 months ago

Apologies again for the way things are.

bc-pi commented 1 week ago

Apologies again.