JSON Web Tokens (JWT) have been widely adopted for authentication in web applications, thanks to their simplicity and stateless nature. They allow ...
For further actions, you may consider blocking this person and/or reporting abuse
A few mitigation measures/defenses for the humble JWT.
I know lots of people use JWTs as a way to not have to go off to the server and validate everything. A quick way to include a users groups or access level and that's fine, a good use case even. So long as you remember nothing on the web is truly secure once it hits the client. That's true with everything we do.
Wonderful security measures
I also wrote a blog about creating an authentication system that observes the security procedures not to overlook; including the ones listed here.
Any beginner overwhelmed can have a look. And also drop a github star(If only you found the resource useful)
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
Great insights!
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
I feel like you could have included resolutions to the concerns so that someone reading this that may not know the resolutions isn't scared away from using JWT. For example, logout is not an issue when you use short lived access tokens and a refresh token. The only issue here which is really not an issue but some may complain is the need for the consumer to check for a 401 and if it occurs, use the refresh token to get a new access token, then retry the previous request if they get a new valid token. There are SDKs/frameworks that do all that for you these days, so it's just a matter of knowing what to look for in an SDK for example that uses JWT.. ensure it covers the access token failure and retry logic.
In my experience.. the only way to go is using https and tokens in cookies with httpOnly flagged. The consumer app should not be able to access the token or decode it for any reason. "But then how do they get info like username, etc". Sure.. on login, the response body returns the details the consumer needs that are not "secure" like name, email, user id, etc. Whatever the API is willing to provide and deems OK to send back as part of the response body on login. Again, it's really simple and works very well. Where things fall off is developers that lack experience with JWT and misunderstand how to use them in a secure manner.
Plenty of large company's, including banks and medical sites use them. So they obviously work well enough to secure some of the most needed secure sites.
For those using a blacklist cache on the server to handle logout/invalidation.. I have yet to see a need for that. You provide an access token that is short lived. 30 seconds or so tops. With auto refresh/retry logic on the client, the consumer never worries about this. The one caveat is that the consumer does need to know how to handle the refresh token returning a 401 or 403. Basically send the user to a login screen again. Or.. if the API provides a response with the 401 or 403, consumer can use that response body.. for example "You're fired" could be a message sent back to an employee trying to access their company site. Server side on a request sees access of user that is now terminated.. invalidates that immediately.. 401 response. Refresh attempts a try and that logic on the server side sees status of employee as invalid and thus invalidates the refresh token and the response body that goes back to that request can carry details, error codes, etc.. that the consumer (with proper API documentation) can use to inform the user what is going on.. or.. just send them to a login screen. Login will now fail for a fired employee. It works quite well but DOES require the client side knowing what the responses mean and taking appropriate action.
This is why auto generated SDKs for clients to use vs straight raw API calls is often ideal.. so the consumers of the API don't have to code up the refresh/retry logic themselves and thus be annoyed at the extra code they have to do.
I have found that many developers are just lazy and don't want to deal with a little bit extra coding to provide a seamless integration with an API. Hence.. again.. generated SDKs so developers can avoid the need to do anything more than wire up some code to be called by the SDK when the failure(s) occur.
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
I think your solution has couple flaws. What you suggested is basically polling. Very bad from performance perspective. When you work with large applications, that is a no-go from the get go. "Server side on a request sees access of user that is now terminated" how do you verify that access? What is your data source? Database? Redis? Against what do you verify it? A list of all tokens? Or a blacklist? What do you think is faster here? :>
As a part time hacker I like JWT. Developers just make my job easier. Sometimes they give me 2 mins access window, sometimes there is no proning so there is more time to look around.
I believe this article is aimed more at junior developers.
1) Not a JWT issue: Only store essential data in JWTs. Avoid adding extra payload that can bloat the token or expose sensitive information. Keep it lightweight and, if needed, encrypt the payload. JWTs should primarily be used with private APIs to limit exposure
2) Token revocation: Use Redis to track active JWT IDs. It works well in multi-node environments and allows easy token revocation. However, bear in mind that managing revocation may reduce the stateless benefits of JWT. Opt for short-lived tokens and refresh tokens for simplicity
3) Cordova issues: Cookies are weakly supported in Cordova apps, which makes session management harder. You’re correct about using HTTP-only, secure cookies with encrypted data as a valid alternative
4) Sensitive data: Always encrypt sensitive information in both JWTs and cookies. Signed tokens can still be read unless the payload is encrypted
5) Session expiration: As mentioned in point #2, Redis can manage session expiry by setting EXPIRE on records. However, refreshing short-lived tokens might be more practical than actively managing sessions in Redis
6) Tool selection and purpose: JWT is not something to use just because it seems modern or popular. It should only be applied when it solves a specific problem, such as when you need stateless authentication in a distributed system. If simpler alternatives (like session cookies) can achieve the same goal more effectively, use them. JWT should always be part of a well-considered architecture, not a default choice for every project
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
Hi there!
Greta article!
Your article inspired me to write an article of my own trying to discuss and maybe solve the issues you've mentioned here.
More Secure JWT | A Better Experience
Adnan Babakan (he/him) ・ Oct 5
It'd be great if you let me know what you think about it.
Cheers!
Glad to hear Adnan that my articles inspired you write your first article. All the best for your journey. Do Subscribe to my YouTube Channel if you find it helpful! Subscribing is free, and it will motivate me to stay active here. 😊
Subscribe to my YouTube Channel if you find it helpful! Subscribing is free, and it will motivate me to stay active here. 😊
I think you should recommend other alternatives for auth. Great post!
If you found my content helpful or interesting, and you’d like to show your appreciation, why not buy me a coffee? It’s a small gesture that goes a long way in helping me keep creating more content for you.
Just click the button below to support:
Think like a hacker, its not if a data breach will happen, its when and how bad will it be. Be careful what you put in the payload. names, email addresses, roles and other things might be convenient but they are painless to extract from the JWT without knowing the secrets or algorithm used for signing. Far better to perform the lookup when you need the information or need to validate security rights.
I think this is a strong argument in favor of JWTs—all sensitive information should be stored encrypted, and every JWT implementation of JWT I've seen makes it trivially easy to add encryption (in addition to the cryptographic signing).
I can't say that about other ways of handling cookies.
To mitigate those issues, you can use opaque tokens. They can contain whatever you want / what security is required and be as small as you want (avoid excessive bandwidth use). Everytime the client passes the token to the backend, the BE takes that token and checks whether it’s still valid (revocation possible) and what permissions the use has.
Obviously the token itself is then not a JWT anymore.
I would state it differently, JWT are just great and I personally encourage using it, revocation is a problem indeed but it is quite easy/possible to mitigate. It is box of wonders especially with open source KeyCloak. It is the tool for SSO in my opinion at least:)
Great article btw.
I always use a trick. I always issue the token version in jwt payload and save that version on database and then compare the token version in authentication. If I want to expire the session I will just update the version in database and old jwt becomes useless.
JWT can be replaced by forwarding hmac'd cookies to other services that need them, having correct cors, setting up good certificates, a reverse proxy, some fast access in memory database for storing sessions. You decouple your session storage from your main database.
Basic recommendation: If you're not LARGE, you probably shouldn't use JWTs. Just use regular session tokens if you don't need to solve Google-scale problems.
Having a SPA and mobile app is not Google-scale problems
I mean, JWTs are great for authentication. You shouldn't ever have to expire an authentication because people's identities do not change.
You can't trust the grants in the JWT if users can be ejected from a system - so pretty much every B2B system out there still has to look up the user - so the benefit of JWT is gone, it's just big and unweildy and still needs a database read.
There are ways to ameliorate this, I for instance use JWTs and have a black list in redis with an expiry time slightly longer than my JWT valid time. This is at least a very fast database lookup.
🚩🚩🚩
In addition to the problem of being able to boot a user from the system (e. g. an employee getting fired) users should have the option of expiring all their authenticated devices at will because the user may have suffered a breach of some kind.
Imagine you're sitting at home and you suddenly realize, "Wait, I'm not sure if I remembered to uncheck the 'Remember me' box when I logged into my bank account at that library computer earlier today." You, as a user, need a way to remotely expire the token stored in that library computer.
This isn't an authentication problem though, this is an authorisation problem. You shouldn't use JWT for authorisation, period.
Your other example is a hard problem to solve with JWT though.
People's identities get stolen, lost, and other things happen to them though. You need a way back. You should only really use JWTs if you really, really need them and have the infrastructure to manage them.
I like how this isn’t a rage rant, but a simple “Welp, there’s this thing. It’s good if you use it right, but not really if you don’t.” Not a JWT bad and evil, but a good fyi article. Good one mate.
So what is replace it
Your article is good. I am the operator of servbay. Can you promote our products? Our official website is servbay.com. If you are willing, we can give you some channel discounts.
Looks like author forgot about tokens epiration/refreshing
what is the alternate and best solution to JWT ?
There's a typo in your cover image, by the way. It reads “Why do many using people not recommend using JWT?”. It should read, “Why do many people not recommend using JWT?” (extra
Usingremoved).The logout problem can be mitigated by forgoing the stateless nature of JWTs and storing Access Tokens so you can Invalidate them immediately after logout.