private_key_jwt, client_secret_jwt audience

Issue #1213 open
Filip Skokan created an issue

https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

aud
REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Authorization Server as an intended audience. The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

The assertion, originally defined in https://tools.ietf.org/html/rfc7523#section-3

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.

When considering the different endpoints these client assertions are used to authenticate at (Token, Introspection, Revocation, PAR, CIBA, Device Authorization Grant) the SHOULD on use of the token endpoint URL as audience is REALLY confusing for both AS implementers as well as RP implementers. There has to be a clearer definition value to use, one that makes sense. It does not make sense to use the token endpoint URL when authenticating at the revocation or CIBA endpoints. To further complicate things, a client may use private_key_jwt auth at the token_endpoint under mtls_endpoint_aliases when it wants to get a mtls sender constrained access token, which audience should the client use then?…

The intention is to assert the identity of the AS (again as per RFC7523 - The authorization server MUST reject any JWT that does not contain its own identity as the intended audience.), for which we have the Issuer Identifier.

I suggest to include in the next Core 1.0 errata that

The Audience SHOULD be Issuer Identifier and MAY be the URL of the Authorization Server's Token Endpoint.

Comments (10)

  1. Michael Jones

    Given that Connect and the RFC agree that the audience should be the Token Endpoint URL, as Brian commented, it’s not an errata action to change this to another value. I agree that, if we were to do this again, we probably should have used the issuer URL.

    Also including the issuer identifier as an audience value, is likely OK, but that’s not something that’s in the spec.

  2. Filip Skokan reporter

    A summary of the 21-03-25 call on the issue.

    The attendees agreed the situation is not ideal, especially given this question pops up with every new client authenticated endpoint added to the oauth2 space, it happened for PAR, CIBA, Device Authorization Grant, is bound to happen again in the future. In retrospective the group would’ve chosen to use the Issuer Identifier value rather than the token endpoint URI.

    @Brian Campbell and @ggfletch suggested to release some form of recommendation moving forward, whether that would take the form of a new OIDC draft, or an IETF draft that would deprecate RFC7523, or an OIDF blog post, is yet to be determined.

    Nevertheless, an Authorization Server still MUST adhere to the following requirements, for which the Issuer Identifer as audience makes the most sense. The use of Token Endpoint URI is still a SHOULD, not a MUST.

    The Authorization Server MUST verify that it is an intended audience for the token.
    The authorization server MUST reject any JWT that does not contain its own identity as the intended audience.

    The attendees stressed the point that the certification suite acts in err when it rejects an assertion with the Issuer Identifier as an audience.

    If I understood the group correctly the certification suite should be adjusted to accept both token endpoint uri as well as the issuer identifier. OPs should be tested to accept both (separately, not in a single request) and issue a warning if one of them is not accepted, the warning should contain information about interoperability with other implementations being the reason for such warning. We did not come to a conclusion for the RP suite behaviour.

  3. Michael Jones

    On the 5-Apr-21 call, we agreed that it should remain an error if the Token Endpoint value isn't supported and that it should be a warning if the Issuer value isn't supported.

    If we do this, we should also produce a guidance document on this topic.

  4. Rui Engana

    Agree normalisation of audience value (issuer, token endpoint, etc.), is way to go, however, until that happen OPs need to check audience from array lists and RPs libraries need to produce assertions with multiple values as audience (issuer, token endpoint, etc.),, otherwise, assertion based authentication isn’t usable due to lack of interoperability.

    We see this across many entities in Open Banking UK that are strict in client assertion processing and not accepting audience array values.

    Also, from RFC7521 https://tools.ietf.org/html/rfc7521#section-5.1 which underpins OIDC and governs Client Assertions Metamodel it’s said.

    Audience
    A value that identifies the party or parties intended to process
    the assertion. The URL of the token endpoint, as defined in
    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 [].

  5. Log in to comment