Not saying you should use JWT, but you can invalidate tokens by adding a timestamp to the payload. This way you could invalidate those issued before a certain time and logout users.
The overwhelming majority of JWTs have an expires field. That's not the issue.
The idea is that you have a disgruntled employee with a token that expires in 5-10 minutes. You don't have invalidation checks, so what damage can that employee do in 5-10 minutes? Keep in mind for many companies, exporting a client list is a big deal.
Why would you not have validation checks? The point of a JWT is they're stateless. When you get one, if you have the key, you can validate it without access to the auth service.
If you take your JWT, and then are using the claims to check the database, it is 100% functionally the same as a session token.
JWTs are not something you issue to use on your own service. It's for another service to verify the user on their service based on a factor coming from your service.(yes i'm aware there are other uses)
If the only thing in your payload is a session_id or a user_id. Stop using JWTs.
To clarify, what I do for sso stuff, if I get the JWT, verify it, then generate a session_id to hand back to the frontend. I'm essentially using the JWT as a replacement for username/password when it comes from a sso provider. I can then do invalidation or deny login as normal.
You're absolutely right, but then we reach the, "why are you using JWTs?" part of things. if you're issuing them for your own service because that's what some guy on reddit said you should be doing...
How do you do it without the service going into some sort of a database to check if there's a certain time for which all tokens older than it should be invalidated?
If you stick to OAuth and OIDC you have the option to validate the tokens against the userinfo and introspect endpoints, but that's, just another "database"
> The idea is that you have a disgruntled employee with a token that expires in 5-10 minutes.
Assuming the tokens issued to employees have an N minute lifetime stop replacing expired tokens for that employee N minutes before you do whatever it is that might disgruntle them enough to make them try to trash your systems?
I replied to a sibling comment. What I do is use the JWT from oauth or whatever sso, verify it, and log the user in as normal. Using the JWT as a replacement for a username/password.
I can invalidate the session or block the user as normal.
I suppose, but generally the solution is a refresh token with the JWT having a very short expiry to the point where adding a timestamp would be superfluous.
IMO the only flexible way is a denylist of tokens or JTI which adds the burden of more infrastructure.
My take is to use an opaque token unless you are using OAuth and paying someone else for all these extra capabilities, at which point things become easy.
ex. If you are using Firebase Auth or Auth0, they manage the token revocation for you so the problem sort of melts away and you are left with only benefits of JWT. Just have to blacklist the JTI claim and it'll automatically be denied in the future.
The idea is that you have a disgruntled employee with a token that expires in 5-10 minutes. You don't have invalidation checks, so what damage can that employee do in 5-10 minutes? Keep in mind for many companies, exporting a client list is a big deal.
Why would you not have validation checks? The point of a JWT is they're stateless. When you get one, if you have the key, you can validate it without access to the auth service.
If you take your JWT, and then are using the claims to check the database, it is 100% functionally the same as a session token.
JWTs are not something you issue to use on your own service. It's for another service to verify the user on their service based on a factor coming from your service.(yes i'm aware there are other uses)
If the only thing in your payload is a session_id or a user_id. Stop using JWTs.