DEV Community

Discussion on: Simple Intro to JWT Basics

Collapse
 
wparad profile image
Warren Parad

I would highly recommend against maintaining a blacklist/whitelist, the need to do that signals a problem of architecture design. JWT represents authentication, you still need a mechanism for authorization. There isn't really a good reason to keep a database of jwts, it is more likely that is another attack service your service will be creating. If you find yourself needing to do that, you probably want take another look at why.

The problem with this is that it is inflexible. Users might find it annoying to constantly be getting logged out, and you can't really use a manual "log out now" button with this approach.

This isn't necessarily true. Using standard session continuation is what most providers of JWTs do to provide a secure way to stay logged in, even after a JWT expires. Instead a browser will "reauth" with the federated server, and get a new JWT the next time your website needs one. In general, you should be using an auth provider and not trying to roll your own JWTs.

Additionally it is worth noting:

Essentially it is the value of the header + payload, put through a one-way encryption hashing function that uses a secret that ONLY the server knows.

This isn't strictly true either. You're using HS256 token symmetric encryption in your example, which means that both the server and the validator need to be using the exact same validation method. Which actually means that unless you have a monolith, there are N + 1 identities which know that value. The actual recommendation is to use RS256 and the service signer will publish a public key any validator can use to verify the signature.

Collapse
 
joshuatz profile image
Joshua Tzucker

These are all great points; I strongly agree that creating lists of JWTs and trying to force them into a session-shaped box is indicative that a developer might need to rethink their approach.

Re: Session continuation
You're right, and I've updated my post. It sounds like most people recommend using a short token duration, and auto-refreshing/exchanging as long as the site/app is kept open. Then the user only gets logged out after prolonged inactivity. It still rubs me the wrong way that this approach is recommended as a way to emulate "true" logout functionality, even by Auth0.

Re: Signing algorithms
Again, you're absolutely right. I missed that when researching JWTs, and have updated my post. I've kept my examples as symmetric, to reduce the complexity of the post, but added a disclaimer about symmetric vs asymmetric.