Open sam-super opened 11 months ago
fwiw i think option 3 is the best:
- make jwksUri OR getKeysInterceptor be required (rather than jwksUri being required). If jwksUri is not set, don't fall back.
I put this PR up just because i had already done it the jwksUriFallback
boolean way for my specific case:
https://github.com/auth0/node-jwks-rsa/pull/389
but happy to change to whataever
Checklist
Describe the problem you'd like to have solved
I have a service which issues a jwt, but also validates a token it has issued (on a separate request). I want to provide the jwk from the filesystem (rather than a uri, since the key is already in the service). I also have multiple auth strategies (meaning upstream issuers). However, if the provided
kid
isn't in the response fromgetKeysInterceptor
, it will fall back to the uri. Since i have multiple strategies, it's normal that an auth token will contain a kid that doesn't exist for one of my strategies.Describe the ideal solution
Ideally (for the stated use case), there would be no fallback, and i would have the option to supply a function OR a uri to
jwksUri
in order to load the correct jwk.This would cause issues with existing consumers who rely on the fallback, so some other more pragmatic options:
jwksUri
to be a function (as well as a string), and if it's a function, execute it in a similar way to howgetKeysInterceptor
currently works (the existinggetKeysInterceptor
function still exists and falls back tojwksUri
, which is a bit confusing).jwksUriFallback
which defaults totrue
to maintain current functionality (this is the simplest option but makes the config confusing: setting thejwksUri
is mandatory but will never be used).jwksUri
ORgetKeysInterceptor
be required (rather thanjwksUri
being required). IfjwksUri
is not set, don't fall back.Alternatives and current workarounds
No response
Additional context
The existing code looks good so I'm happy to put together a PR implement the chosen solution.