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
Currently, multi-service setups require some kind of external method of synchronizing keys.
Proposed change
I propose an extension of this package that would allow it's users (the service developer) to specify a JWK_PROVIDER config key (JWK = JSON Web Key, hence JWK_PROVIDER), which the JWTManager.decode_key_loader method would use to fetch JWKs/JWK Sets from in order to verify JWTs issued by another service (think microservices where one is the service "useful" to it's users, and another is responsible for making sure the user is who they claim they are, or potentially a 3rd party verifies users, like Auth0, and I have to make sure that Auth0 has in fact verified the user in my own app).
Possible implementation
The implementation would likely entail:
Adding JWK_PROVIDER configuration key to documentataion
Extending JWTManager.decode_key_loader to handle JWT_SECRET_KEY or JWT_PUBLIC_KEY not being defined by requesting a JWK (Set) from the provider specified in JWK_PROVIDER
Adding a /jwks endpoint which would expose public(!) keys
Note:
If the received JWT is using a symmetric key, but no secret key is defined, we should make the request fail even ifJWK_PROVIDER is defined as this mechanism should not be used to exchange secret keys.
What can potentially be included, but is not as necessary at this moment:
Allow for keys to be defined in JWT_*_KEY configuration keys as key string, JWK or JWK Set
Allow for JWK_PROVIDER to be only a hostname, adding the HTTPS protocol and the /jwks endpoint ourselves.
Topics to discuss
Should we merge JWT_*_KEY and JWK_PROVIDER config keys into a single config key?
What should we name the JWK_PROVIDER key or the merged key, if we decide to do so.
What should the endpoint exposing public keys be called.
Nothing at this time. I do agree this is a good idea and would be cool to have some first class support built into this extension, but I don't have the time to work on it right now. I'll keep it on the backburner for when things calm down, or if anyone else wants to take a stab at it pull requests are always welcome! 👍
Following a discussion on Discord:
Issue
Currently, multi-service setups require some kind of external method of synchronizing keys.
Proposed change
I propose an extension of this package that would allow it's users (the service developer) to specify a
JWK_PROVIDER
config key (JWK = JSON Web Key, hence JWK_PROVIDER), which theJWTManager.decode_key_loader
method would use to fetch JWKs/JWK Sets from in order to verify JWTs issued by another service (think microservices where one is the service "useful" to it's users, and another is responsible for making sure the user is who they claim they are, or potentially a 3rd party verifies users, like Auth0, and I have to make sure that Auth0 has in fact verified the user in my own app).Possible implementation
The implementation would likely entail:
JWTManager.decode_key_loader
to handleJWT_SECRET_KEY
orJWT_PUBLIC_KEY
not being defined by requesting a JWK (Set) from the provider specified inJWK_PROVIDER
/jwks
endpoint which would expose public(!) keysNote:
If the received JWT is using a symmetric key, but no secret key is defined, we should make the request fail even if
JWK_PROVIDER
is defined as this mechanism should not be used to exchange secret keys.What can potentially be included, but is not as necessary at this moment:
JWT_*_KEY
configuration keys as key string, JWK or JWK SetJWK_PROVIDER
to be only a hostname, adding the HTTPS protocol and the/jwks
endpoint ourselves.Topics to discuss
JWT_*_KEY
andJWK_PROVIDER
config keys into a single config key?JWK_PROVIDER
key or the merged key, if we decide to do so.Further reading
RFC 7571 - Introduces JWKs and JWK Sets: https://tools.ietf.org/html/rfc7517
NGINX JWT Auth module documentation: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-jwt-authentication/
The text was updated successfully, but these errors were encountered: