insecure front-channel use of private_key_jwt client authentication

Issue #1164 closed
Brian Campbell created an issue

“At a minimum openid-connect-federation needs to acknowledge that it's misusing private_key_jwt and do something to mitigate the security problem.”

Please see but particularly the comments at and

Comments (9)

  1. Michael Jones
    • changed status to open

    This has received substantial on-list discussion and I believe Roland Hedberg has a plan of action.

  2. Brian Campbell reporter

    draft -12 is now using the request object as one option. However, it requires ‘sub’ saying “The claim sub MUST contain the entity ID of the OpenID Connect provider.” I assume that’s a mistake and should have said it’s the the client identifier? That’d make more sense and is what the content of the example has. The same presumably erroneous text is there for ‘iss’ too.

    But WHY is sub required? The same data would already be carried in the ‘iss’ claim and the ‘client_id’ claim and the ‘client_id’ parameter. Worse the ‘sub’ claim means that the request JWT could likely be used as a private_key_jwt in a token confusion type attack as discussed in and subsequent comments. So the problem at the heart of this issue is still present.

  3. Brian Campbell reporter

    Also -12 references an old and expired PAR draft and has “URL of the Authorization Server's Authorization Endpoint or the Authorization Server's entity_id” (note ‘entity_id’ isn’t used anywhere else) for the ‘aud’ of private_key_jwt, which isn’t consistent with the below text from :

    “Note that there's some potential ambiguity around the appropriate audience value to use when JWT client assertion based authentication is employed. To address that ambiguity the issuer identifier URL of the AS according to [RFC8414] SHOULD be used as the value of the audience. In order to facilitate interoperability the AS MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.“

  4. Roland Hedberg

    Regarding the entity statement use for automatic client registration we now specify that ‘sub’ MUST NOT be part of the statement and that ‘aud’ MUST be the ASs authorization endpoint URL.

  5. Log in to comment