Intuit/Quickbooks OpenID uses a RSA key with a modulus length of 1024 and isn't supported by openid-client

[GuiSim]

Hi,

I'm trying to get next-auth to work with Intuit/Quickbooks' OpenID.
next-auth relies on node-openid-client which in turn relies on https://github.com/panva/jose

As far as I understand, it is currently impossible to get node-openid-client to work with Intuit and I'd like to ask this community if anyone has succeeded in getting this to work or has suggestions for a workaround.

The main issues:

The JWS key used by Intuit is RSA with a modulus length of 1024 bits. This isn't super secure, but I can't change their keys so I have to live with them.
https://developer.api.intuit.com/.well-known/openid_configuration
https://oauth.platform.intuit.com/op/v1/jwks

This is rejected by Jose due to this check: https://github.com/panva/jose/blob/main/src/runtime/node/check_modulus_length.ts#L68-L71
The min reqs for RSA256 are documented here: panva/jose#210

The id_token will always fail to validate since the key is too short and Jose rejects it.

next-auth allows you to bypass the id_token and obtain user info through another mechanism, but this ends up hitting this check:
92ffee5
The id_token is defined in the response from Intuit and can't be ignored by openid-client.

Now I recognize that Intuit are to blame here for the short key, but I would like to see with this community if there's a way to work around this limitation. I have written to Intuit to get this changed but I am not very hopeful that they will address this.

Is there a way to bypass the id_token check and ignore it completely? Removing the openid scope achieves this, but then I can't retrieve the user's info since this is tied to the openid scope.

Is there a way to tell Jose to temporarily support 1024 bit modulus length on RSA256?

Related issues:
nextauthjs/next-auth#3114
nextauthjs/next-auth#4554

Any help appreciated.

[panva]

The use at least 2048 bit RSA modulus length is a normative requirement of the JWA specification.

A key of size 2048 bits or larger MUST be used with these algorithms.

There is no way to remove such check.

---

Enforcing the correct callback method to be used for each respective flow (OpenID Connect or pure OAuth 2.0) is by design and to prevent the developer foot-gunning themselves thinking they perform all security checks when they in fact don't, a downgrade attack of sorts?

Again, no intention to alleviate these.