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