[ehutch79]

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.

[the_sleaze9]

> what damage can that employee do in 5-10 minutes?

This is not an authentication issue (JWTs) this is a classic authorization issue (Permissions/Roles).

It's not the authentication layer's fault if you allow everyone root access.

JWTs are just fine. Bearer tokens are just fine. You can write shitty session code just as easily as shitty OAuth2 code.

[ehutch79]

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.

[ehutch79]

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...

[drikerf]

That was my point. You can easily add validation checks to JWT. Just invalidate tokens issued before a certain time.

[senko]

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?

[ffo]

Well you don't ;-)

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"

[tzs]

> 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?

[jayd16]

Why doesn't the same argument apply when looking at other services? Can't they still do a lot of damage in that 5-10 minutes against those services?

[ehutch79]

You're not wrong.

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.