search

Styria-Digital / django-rest-framework-jwt

JSON Web Token Authentication support for Django REST Framework
https://styria-digital.github.io/django-rest-framework-jwt/
MIT License
191 stars 57 forks source link

RFC: Support for multiple key IDs #31

Closed nigoroll closed 4 years ago

nigoroll commented 4 years ago

Before starting any development work, I would like to ask for opinions/advise on the following feature idea: Seamless changes to the signing key of a JWT, be it symmetrical or asymmetrical, requires a rollover procedure where consumers start to accept a new key before issuers create any tokens signed by it. While it would be possible to support such rollover with just a second key to try (usually called a transition secret or key), using JSON Web Key (JWK) IDs (kid) appears to be the cleaner solution: a kid (key id) parameter imforms consumers about which (known) key to use for validating a token.

Notice that this is particularly relevant in scenarios where a single JWT/JWS is used by multiple applications which need to be coordinated for secret/key rollover.

While complete JSON Web Signature (JWS) support would include many more JOSE header values, I would suggest to only add

Opinions?

fitodic commented 4 years ago

Thank you for bringing this up! I agree that this would be a valuable addition, and if you have the time for it, feel free to send a PR :+1:

This library uses PyJWT which already has support for specifying additional headers, including the kid header.

As to the proposed additions:

support for the kid paramter

I assume the kid header would be an additional setting?

  • support for multiple public keys / secrets to accept, identified by a kid
  • stick to a single public key / secret to use for issuing tokens, which also needs to be identified by a kid

Just to be clear, you are saying that the library will use a single private/public key pair for issuing outbound JWTs signatures, but use multiple public keys for verification of the incoming JWTs' signatures, i.e. to simultaneously support the old and new public keys?

nigoroll commented 4 years ago

support for the kid paramter

I assume the kid header would be an additional setting?

Yes, I would want to preserve the current implementation without any key ids.

Just to be clear, you are saying that the library will use a single private/public key pair for issuing outbound JWTs signatures, but use multiple public keys for verification of the incoming JWTs' signatures, i.e. to simultaneously support the old and new public keys?

Yes, that would be the idea.

Do we want to keep the issue open for some time in case anyone else has input? Other than that, I am fine with closing any time.

fitodic commented 4 years ago

Do we want to keep the issue open for some time in case anyone else has input? Other than that, I am fine with closing any time.

I'm fine either way. :slightly_smiling_face:

We can keep it open until a PR that implements it comes along.