If you have been put off learning about JWT (JSON Web Tokens) because they sound scary or complicated, I have good news; they really aren't. In thi...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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:
This isn't strictly true either. You're using
HS256token 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 useRS256and the service signer will publish a public key any validator can use to verify the signature.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.
Great post. I have a QQ. In the the “Avoiding State” section, it seems like you don’t like the idea of changing the secret to invalidate JWTs, and I’m curious why that might be bad practice. Is only bad when used instead of a blacklist / whitelist approach?
Thanks! To answer your question, one of the primary reasons is that it leads to a bad user experience. If I change my server secret, it indiscriminately invalidates all circulating tokens, regardless of when they are created. If I'm a user, and I happened to have logged in just 20 seconds prior to a dev doing this, I'm going to be confused and maybe a little aggravated that I'm suddenly logged out again.
There are legitimate reasons to do this; if a secret key is leaked, you absolutely need to change the server-side key ASAP.
My problem with this method is when it is used as more of a crutch to avoid implementing a more robust session-based approach. At that point, the use of it, at least in my mind, is really a symptom of your system design not matching what is needed.
I try not to be opinionated about these things, but definitely adhere to the idea of "use what is best for your needs".
I see, that makes sense. It's better to change the key only if you actually want to revoke all user tokens. If you only want to revoke just some tokens, a different solution makes for a better user experience. Thanks.
Okta has a nice article from a few years ago about using JWTs for sessions - developer.okta.com/blog/2017/08/17...
Thanks for the link; they make a lot of really good points! You definitely lose a lot of the benefits of JWT over other auth approaches once you start trying to use them for session based stuff.
Thanks for the post.