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

'jit' for JWT token #22

Open
ad-m opened this issue Oct 27, 2020 · 4 comments
Open

'jit' for JWT token #22

ad-m opened this issue Oct 27, 2020 · 4 comments
Labels
question Further information is requested

Comments

@ad-m
Copy link

ad-m commented Oct 27, 2020

Hello,

Why do you generate 'jit' for JWT token? The primary use case for 'jit' is if you want a token "revoke" mechanism. Most tokens usually expire due to expiration. I see no reason for generating and storing "jit" for JWT if there is no "revoke" mechanism. Could you please explain it regarding purpose of that?

filecache.set(jti, "good", timeout=settings.TOKEN_EXPIRES_SECONDS)

@vsoch
Copy link
Owner

vsoch commented Oct 27, 2020

The jit is stored in a cache with the same expiration as the token itself. If a registry wants to revoke all tokens they can simply clear that cache.

@ad-m
Copy link
Author

ad-m commented Oct 27, 2020

If I want to revoke these tokens, is it not enough to change secret key? If the same goal can be achieved in two ways, why keep this data?

@vsoch
Copy link
Owner

vsoch commented Oct 27, 2020

You could, but clearing the cache is an easier mechanism that does not require a server (or container) restart.

@vsoch vsoch added the question Further information is requested label Oct 27, 2020
@ad-m
Copy link
Author

ad-m commented Oct 28, 2020

However, in this case you do not have the option of horizontally scaling, or you need to provide an efficient shared filesystem. If you run it in a container, a statefull service is created (any remaining state of that service can be eliminated, because the user database is in an external service and binary files will be stored in the object storage), which is not e.g. kubernetes-friendly (Kubernetes has persistent volumes but their use should be minimized).

If you take this approach to the session - why go into JWT at all, when OCI spec treats it as "opaque value"? Wouldn't it be easier to just save everything in session data (similar to PHP sessions), instead of having some of the data in a JWT token and some in the local filesystem?

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

No branches or pull requests

2 participants