Assertion token with dynamic audience

[trm217]

I ran into the following issues with the Assertion Tokens when using this library with Okta.
The value set by this library for the aud claim of the assertion tokens is different, than what Okta expects.
While openid-client seems to set the aud claim equal to issuer value (URL), Okta expects the aud claim to equal the full URL of the specific endpoint for which the assertion token is to be used. (e.g. "aud":"<issuer-url>/<token-endpoint-path>" rather than just "aud": "<issuer-url>")
This is documented here (see aud claim).

I am aware that the audience claim can be overridden, via the client.modifyAssertion option, however this does not allow computing the aud claim value based on the requested URL, as the only available information is the original assertion tokens header and / or payload.

Am I missing something or is the desired behavior not possible as of now with this library?
From how I understand the specification, both is in theory acceptable as both values clearly identify the issuer.

Also it seems that I am unable to define the assertionToken payload override anywhere aside from the client discovery function, is this really the only way to apply the logic?

@panva do you have any insights on this?

[panva]

The current behaviour is the only correct one as per the updated guidance on Client Authentication Assertions following fix to a recent vulnerability

https://www.ietf.org/archive/id/draft-ietf-oauth-rfc7523bis-03.html
For client authentication, the aud (audience) claim value MUST use the issuer identifier [RFC8414] of the authorization server as its sole value.

I am aware that the audience claim can be overridden, via the client.modifyAssertion option

That's why it's there. So that you can override claims that don't work for a particular provider.

Also it seems that I am unable to define the assertionToken payload override anywhere aside from the client discovery function, is this really the only way to apply the logic?

Discovery doesn't even accept this option, not sure what you're referring to.

[trm217]

I was referring to the first example here.
As I access the specific endpoints URL via the configs serverMetaData().<endpoint> accessor, I don't know the specific URLs that I want to override the aud claim of the assertion token with, when configuring the PrivateKey in the discovery method.
If I somehow was able to use apply the modifyAssertion value after already having called the discoverymethod and thus being able to access the serverMetaData, I could work arround my issue, by just setting a different modifyAssertion for the different types of requests.

[panva]

somehow

let server!: URL
let key!: client.CryptoKey | client.PrivateKey
let clientId!: string
let clientMetadata!: Partial<client.ClientMetadata> | string | undefined

let config = await client.discovery(
  server,
  clientId,
  clientMetadata,
  client.PrivateKeyJwt(key, {
    [client.modifyAssertion]: (header, payload) => {
      payload.aud = config.serverMetadata().token_endpoint
    }
  }),
)

It's just javascript afterall

[panva]

Oh, and you needn't use the exact URL, the old (outdated, potentially vulnerable, albeit unlikely) guidance is to use token endpoint URL

https://www.rfc-editor.org/rfc/rfc7523.html#section-3
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.

https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
The Audience SHOULD be the URL of the Authorization Server's Token Endpoint

[panva]

I just spoke with @aaronpk about the Okta Private Key JWT validation and we'll see what can be done to expedite Okta's endpoints accepting the value of Issuer Identifier as the JWT audience in anticipation of draft-ietf-oauth-rfc7523bis WGLC. Auth0's endpoints already accept it, Okta should follow suit.

[trm217]

Thanks for your pointers and looking into this in Okta 💪🏻