vimalloc / vimalloc/flask-jwt-extended

Implement JWK (Set) fetching and publishing for other services

Open
#321 3 comments 9 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1.6k
Forks
253
PR merge metrics
No merged PRs in 30d

Description

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 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 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:

  • 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.

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/

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading JWTManager.decode_key_loader and the documented configuration around JWT_SECRET_KEY and JWT_PUBLIC_KEY. Resolve the open naming and endpoint questions before implementing JWK_PROVIDER support and the /jwks endpoint; done means services can fetch public keys for verification without exchanging symmetric secrets.

Written by the indexing model from the issue text.

Assessment

Tech stack
flask, python
Domain
api, authentication, backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.