v5.7.1

[panva]

Refactor

• jwt client authentication audience is now an issuer identifier string (0b05217)

Note: If needed this can be reverted using the extras.clientAssertionPayload option.

---

This discussion was created from the release v5.7.1.

[nwalters512]

@panva can you share more about the rationale for this change? Unfortunately this was very much a breaking change for us, and it's a shame to see it was released in a patch version.

From my read of the OIDC spec (https://openid.net/specs/openid-connect-core-1_0.html#rfc.section.9), under "9. Client Authentication", "private_key_jwk", aud is indeed supposed to be the "Authorization Server's Token Endpoint", not the issuer. It'd be helpful to know which part of the spec this change was based on.

[panva]

it's a shame to see it was released in a patch version

Unfortunately, it had to be done.

It'd be helpful to know which part of the spec this change was based on.

A future not yet disclosed one.

Unfortunately this was very much a breaking change for us

If needed this can be reverted using the extras.clientAssertionPayload option in whichever authenticated methods you invoke.

From my read of the OIDC spec (openid.net/specs/openid-connect-core-1_0.html#rfc.section.9), under "9. Client Authentication", "private_key_jwk", aud is indeed supposed to be the "Authorization Server's Token Endpoint", not the issuer.

It's not that simple. The specs are layered in such a way that the issuer identifier is also a valid value for an AS to accept.

[nwalters512]

Sure, thankfully it was an easy enough fix (once we realized what was going wrong, which took a few days): PrairieLearn/PrairieLearn#11038. I appreciate the pointer in the commit message.

Is this related to a vulnerability that hasn't been publicly disclosed yet? I can understand if you can't say more at this time, but otherwise the secrecy/caginess here is unexpected from this project.

Regardless, I appreciate the work you do in maintaining this library. Thank you.

[nwalters512]

It's not that simple. The specs are layered in such a way that the issuer identifier is also a valid value for an AS to accept.

I buy that; I'm definitely not very well versed in the spec, this is just what I found with a quick read. For my own edification, do you know offhand what other pieces of the spec apply here?

[panva]

I cannot say more at this time, the issue will be discussed publicly in the IETF OAuth WG interim meeting on 2025-01-27.