private_key_jwt auth - aud property

[leemcmullen]

Hi,

I'm trying to get nextauth working with an auth provider who use private_key_jwt for authorisation. nextauth uses oauth4webapi under the covers.

The issue we're coming across is that when oauth4webapi creates the JWT to send to the token endpoint, the aud property is being created as an array. The provider we're using will strictly only accept a string for this property.

The line where this happens is here:

oauth4webapi/src/index.ts

Line 1400 in 787efb2

aud: [as.issuer, as.token_endpoint],

I've found this spec which seems to imply the aud should be a string but then goes on to talk about aud values as a plural, so I don't know for sure: https://datatracker.ietf.org/doc/html/rfc7523#section-2.2

Either way, is it feasible to submit a PR to make aud optionally a string with a single value instead of an array?

Thanks,
Lee

[panva]

What is the provider?

[panva]

Much has been said and written about the aud claim in Private Key JWT client assertions.

Bottom line is that the AS should accept both string and array and expect a value that uniquely identify the AS. For historical reasons a single string may be both the issuer identifier or the url of the token endpoint, in an array (which this module does for interoperability reasons) at least one of those needs to be present.

That's as much as we've agreed upon in the FAPI WG and is summarized in the FAPI 2.0 SP draft.

I'd suggest you reach out to NHSConnect first to fix this issue. Their own interface specification talks about aud containing the token endpoint URL which is the correct language since aud may be both a string or an array of strings.

If NHS had undergone OpenID Connect Certification this would have been identified as a defect in the process.

I could, of course, add an option to get out of this interop nightmare once and for all but I'd rather not if it can be avoided.

[leemcmullen]

Thanks for your detailed response 👍

I've been speaking to them in a private slack channel I've been granted access to and they're so far saying that they have no plans to support an array 😕

I'll refer them to this chat but I suspect even if they decide to support it, then it will be a long process and therefore be quite some time before it actually gets implemented and released.

Would it be possible to add an option to override the default and get over this hump? I'd much much prefer to continue using the library rather than having to try and work out something different 🙏🙏🙏

If we can get an option to use a string, I'll see about submitting a PR to next-auth to update to the latest version. There's another issue with their lib where they're not even sending the private key into this lib (so private_key_jwt can never work with next-auth at the moment) which I'll look at adding a PR for too.

[leemcmullen]

Lol, just spotted your reply to our chat in the slack channel 👍

[panva]

I'm not going to be adding an option just yet on the account of there being an ongoing discussion which I believe NHS should be able and willing to accomodate.

[leemcmullen]

@panva I've had an update from NHS in the Slack channel that conversations are now in progress. Hopefully they can make the necessary change 🤞

[leemcmullen]

Just following up my comment about nextauth not passing the private key into oauth4webapi, here's the PR for that lib to pass it across: nextauthjs/next-auth#11132

[balazsorban44]

I reviewed the PR. Feel free to reach out at https://x.com/balazsorban44 or https://discord.authjs.dev if I don't see your replies.

[leemcmullen]

@panva Quick update. The NHS login team have advised (via the Slack channel) that they're going to make the change to the aud prop on their side, should be wihtin the next week or so 🎉

Also, my next-auth PR to pass the key into oauth4web has been approved and merged (thanks again @balazsorban44 🙏).