You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 from getKeysInterceptor, 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:
allow jwksUri to be a function (as well as a string), and if it's a function, execute it in a similar way to how getKeysInterceptor currently works (the existing getKeysInterceptor function still exists and falls back to jwksUri, which is a bit confusing).
add another boolean option jwksUriFallback which defaults to true to maintain current functionality (this is the simplest option but makes the config confusing: setting the jwksUri is mandatory but will never be used).
make jwksUri OR getKeysInterceptor be required (rather than jwksUri being required). If jwksUri 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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: