-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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. |
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? |
You could, but clearing the cache is an easier mechanism that does not require a server (or container) restart. |
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? |
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?
django-oci/django_oci/auth.py
Line 101 in a596148
The text was updated successfully, but these errors were encountered: