Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JWT blacklist #526

Open
Tracked by #527
janbaykara opened this issue Apr 17, 2024 · 6 comments
Open
Tracked by #527

JWT blacklist #526

janbaykara opened this issue Apr 17, 2024 · 6 comments

Comments

@janbaykara
Copy link

We're setting up a simple public API ontop of our private API, and we want to use the same Strawberry setup.

As part of this, we'd like to extend the use of JWT tokens for use as long-lasting API tokens that can be revoked.

Some research led to the strategy of revocation via blacklisting tokens, and it'd be fantastic if this was built in to the library.

@janbaykara
Copy link
Author

The first challenge I'm facing is how to add a jti field to the payload, when I can't figure out how to extend the TokenPayloadType strawberry type.

@nrbnlulu
Copy link
Owner

Hey.

  1. Do you want to blacklist fresh tokens or refresh tokens?
    if the latter what's stopping you from just revoking it?

  2. What's jti?

@janbaykara
Copy link
Author

janbaykara commented Apr 23, 2024

I want to revoke the tokens themselves. I've implemented this by storing a plaintext reference to the JWT signature along with a revocation boolean field. I load this blacklist into the cache and check all authenticated requests against it. PR here: commonknowledge/mapped#46

Re JTIs, a quote trom the article above:

To revoke a JWT we need to be able to tell one token apart from another one. The JWT spec proposes the jti (JWT ID) as a means to identify a token. From the specification: > The jti (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well.

@nrbnlulu
Copy link
Owner

Ok so AFAIR you want that the api clients would not be required to use a refresh token something like github tokens so you want to make the fresh tokens revokeable in order for them to be usefull for long periods, correct?

If that so, why not just to authenticate yourself via a refresh token? You can setup a public authorization field that would accept refresh tokena instead of short tokens.

@janbaykara
Copy link
Author

janbaykara commented May 9, 2024

Oh, that's a nice idea! I'm not immediately sure what that would precisely look like but may take a look at this and report back here.

For now, I'll post this PR here for how I hacked a first version of blacklisted tokens: https://github.com/commonknowledge/meep-intelligence-hub/pull/46/files

@nrbnlulu
Copy link
Owner

nrbnlulu commented May 9, 2024

For now, I'll post this PR here for how I hacked a first version of blacklisted tokens: commonknowledge/meep-intelligence-hub#46 (files)

Thanks for sharing, on my TODO 😄

We might as well rename refresh tokens to long running tokens and have support for it here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants