What are the downsides of using JWT if we can handle token invalidation?
Asked by
CuriousCoder24
I've been looking into the differences between JWT (JSON Web Tokens) and session-based authentication methods. I came across an article that discussed the invalidation problem with JWTs, which got me thinking. With session-based auth, you typically store user sessions in a database, allowing you to log out users simply by deleting their session entries. This means when a session is invalidated, the user is logged out without extra fuss.
On the other hand, JWTs contain user information like the user ID within the token itself, allowing for a single database query to fetch user data after verifying the token. I've also seen some methods for managing refresh tokens that involve adding a version field in the User table, which can help with invalidation across devices.
So, with JWTs theoretically streamlining operations by reducing the need for database calls, I'm curious to know what your experiences have been with JWTs versus sessions. Do you think JWTs are worth it in real projects, or do sessions still hold the advantage?
Answers
You can actually minimize database queries using joins or aggregating results, so it’s possible to fetch user data with a single query instead of two separate ones. Remember, JWTs were designed for stateless auth to reduce database load, especially as you scale. If you're querying the DB for auth with every request, it kind of defeats the purpose.
Reply to this answer
Honestly, if you’re checking user status on every single request, you might want to reconsider using access tokens altogether. Sometimes, sticking with traditional sessions is just the easier path, especially for most applications.
DevRealization88: Yeah, I’m starting to think I may have complicated things. If I'm pulling user info every request anyway, maybe sessions would actually simplify things.
Reply to this answer
How long is your access token set to last? If you have it at about 15 minutes, the version bump approach can work effectively for managing auth. Just keep an eye on the expiration!
TokenMaster76: Yes, I keep it to 15 minutes too. I'm not fully sold on the global list strategy mentioned in that article, but I definitely see the value of versioning.
Reply to this answer
A few points to clarify: Yes, one query can work by fetching both session and user info. Also, JWTs do not necessarily encode user details; it’s more about checking token validity at the backend. But feel free to keep non-sensitive ID info on the browser side for convenience, if needed!
JWTQuestioner23: But in JWTs, you can encode user ID, right? It seems useful to keep that on the client-side for easy access!
Reply to this answer
The main issue isn't really about refresh token invalidation; that's manageable. The tricky part is invalidating the ID token to force a user to refresh. Sure, you could set short expiration times for the ID token, but then you run into the question of why not just use sessions at that point since you’d still have to hit the database to validate?
QuickReply01: Exactly! When you get a new ID token from the refresh token, you're typically not hitting the database, right?
Reply to this answer
Add your answer
Answers are reviewed before publication.
InformedDev13: Got it! So, even just using the user_id in a JWT and querying the database each time might not be optimal. It seems like implementing permissions directly into the token could be beneficial.