No problem at all! I know, I used clickbait, but I genuinely want to hear your opinion on the following article because I truly believe that JWT is...
For further actions, you may consider blocking this person and/or reporting abuse
Storing the JWT in an httpOnly Secure cookie reduces the chance of it being stolen significantly, but you've still got to keep a Redis log of disabled keys for sure. The case may be that the user's account is invalidated by an administrator etc.
Thank you for your response, but regarding having disabled keys in Redis, do you think it's necessary? I mean, if you have a whitelist, even if a valid token enters, you would still need to check in Redis that the key exists. If it doesn't exist, either because it expired or was deleted to disable it, then even if the user provides a valid JWT, they would be denied access since it's not on the whitelist. Could you give me an example of why to use the blacklist to see if I understand?
Very few tokens will be blacklisted, therefore the amount of storage used to maintain this list is minimal. Blacklist keys need to only last as long as tokens remain valid, so most of the time, there are no keys being maintained at all.
Whitelisting tokens is creating a secondary auth database with cost and performance implications.
I understand the point, but I think that once you have to put a token on the blacklist, you no longer know, depending on how it has been implemented, whether the attacker hasn't generated another refresh token and someone has your session. I believe that managing JWT without having control over the tokens and following typical web tutorials where everything is not made clear can be insecure. I'm starting to think that using JWT is more of a hype than something useful. By the way, I don't know if you've seen this video; you might find it interesting: youtube.com/watch?v=pYeekwv3vC4
Don't blacklist tokens. Blacklist by
iatclaim.Invalidating JSON Web Tokens (JWT) the Right Way
José Pablo Ramírez Vargas ・ Dec 11 '22
Gracias Jose for your answer, Your approach is really interesting, and it brings up points I hadn't considered, such as not directly saving the token. I wanted to know what you think, for example, about using invalidation for log-out? Is it something you would do, or would it simply not be a feature to consider? In this case, for instance, every time you log in, would you always need to have a record in Redis or wherever with the "iat" (issued at) timestamp, or would you approach it differently?
I would only use IAT invalidation for "log out from everywhere". Not for regular log outs.
And how do you refresh the token to differentiate it from the access token? Do you set any attribute with a specific value?
I suppose you mean to ask "how do you create the refresh token to differentiate it from the access token?". If yes, then a payload attribute, most commonly
tokenTypeor a shortened version likettyp. Your refresh tokens (or all your tokens) can be given a unique ID and the refresh token ID could become part of the access token payload if you need fancy tracking.For user authentication/sessions, I'm all on your side. Good ol' session cookies are both simpler and safer than JWTs. Cookie is there, user is logged in, cookie is gone, user is logged out. Dead simple, secure, efficient. Nevertheless, IMHO, the main purpose of JWT is another: usage of a third-party API. In that context, when a service "grants permission" to another, JWTs make much more sense since it's decoupled from user authentication/sessions altogether. The API may even be used in a background services while the user is offline.
Thank you for your point of view; I think it's interesting. I really thought I was wrong with all the hype about JWT, but as you say, I believe sessions are the simple option that has what is needed.
I guess this is another case of 'it depends'. How long is the window a potential attacker has when he's got a token. He should not be able to do a refresh with the token alone. Was he able to retrieve the refresh token, too? What are the risks. Maybe you'd have to implement an additional security check for certain actions? There are many ways to make JWT work in a secure enough way. The question is always 'what harm could be done?' and mitigate.
Hello, thanks for your response. As you mentioned, it's another case of "it depends," and of course, depending on the implementation of the refresh token, it could be even worse. Still, the more you delve into how you have to implement JWT instead of sessions, for example, it starts to make less sense for them to sell it to you as easy, secure, fast, and without sessions. In the end, to ensure a certain level of security, it depends on the opposite. I just watched this video youtube.com/watch?v=pYeekwv3vC4 that presents other points in favor of or against JWT, which I find interesting. What do you think? Do you usually use JWT or sessions?
It was a great post and I agree with you but what do you think about Redis in a microservices architecture? is it a good idea to use 1 Redis instance among all the running services?
Hello, thank you, I'm glad you liked the post. Regarding Redis, I don't think it's a drawback to use it for data that can be volatile, such as caching or a shopping list – I know, I know, those are typical examples. However, I haven't had the need to implement more complex things. Personally, I've used it for caching and messaging on a few occasions, although I've mostly used Kafka or Pulsar.