Every time I start a new job I feel like I spend a lot of time trying to argue this point exactly. Don't send a JWT to the client, just send a fucking cookie.
JWT Tokens are NOT safe
111–115 of 115 posts
Re: JWT Tokens are NOT safe
#112> Imagine you logged out from Twitter after tweeting. I don't use Twitter, but that doesn't sound like the usual use case. If the device you're using is trusted, why log out? If it isn't trusted, why enter your credentials at all?
I don't know about Twitter in particular, but it's fairly common for users to log onto accounts for various services on borrowed devices and then log out when they're done. So the device is only partially trusted, or only trusted for a limited amount of time.
If you want to say you'd never enter any credentials on any device that wasn't fully trusted, well 1. That just doesn't match how many people use accounts and devices, if you want a widely used service, you must account for it even if you'd never do it, and 2. It will still cause problems if you ever sell a device, or have to return a corporate/managed device after leaving a job, or return a device for repair, etc.
Re: JWT Tokens are NOT safe
#113Not bad for an advert. If you are interested, here is a short guide how to actually implement JWT securely: - Make the JWT short lived ( 5 minutes) - Re-freshing the JWT should involve server state (DB hit every 5 minutes, not every request) - Protect highly-sensitive actions (typically overwrite/delete, but not read / non-overwrite) by requiring a fresh token.
I prefer traditional sessions, but for some systems implement JWTs as well. I'd offer the above but with a couple of slight differences.
- Issue tokens containing a flag which makes them read-only and give them a short life-time (around a minute). At times of heavy use you're now performing authentication much less frequently in comparison to every request, so less scale is needed. If the token is intercepted it remains a read-only one tied to the context/permissions of the user it was provided to.
- When a destructive action is requested (write, delete) if you receive a read-only token reject it. The app will then be forced to re-authenticate to get a write-capable token, which has a lifetime measured in seconds. This covers you for a couple of quick requests and so still reduces load - but the lifetime is very fleeting so revocations, if still needed, are extremely short-lived before the token is expired anyway.
If you still want to maintain a revocation list you can stick the tokens in something like Redis with an auto-expiry set to match the token. The short lifespan will keep the revocation list comparatively small and Redis being in memory will make checking it fast.
However as the read-only token is only valid for a minute and the write-capable token for a few seconds, there is usually no need to keep a revocation list at all.
This all may not seem worth it for the small usage windows you get with a short-lived token, but if your client app/site is refreshing pages or pulling in data via 10 requests in a 2 second window (not uncommon) then you've eliminated 9 authentication requests. At small volumes it doesn't matter, and at large volumes you may reduce the authentication cycles by 90% or more. Again, without needing a revocation list.
All that said, use traditional cookies/sessions unless you have complex requirements.
Re: JWT Tokens are NOT safe
#114I flagged this post for the following reason: Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity. The user's submission history is almost completely RedisLabs content.
I post all sorts of stuff if you look into the complete history. The blog legitimately identifies and highlights the issues that a ton of security experts have already identified for years and written about. May I ask you to un-flag it?
I did not look past your last 15 submissions, so I did not see that.
I unflagged, but it still appears flagged. Perhaps somebody else has flagged it.
Re: JWT Tokens are NOT safe
#115TL;DR as always, is that there's nothing wrong with JWT. The problem is with thinking that there is a way to have an authentication token that isn't persisted in any way, so long as you want the ability to invalidate a token (i.e. logout, user banned, password change, etc).
The difference tho is maintaining a list of user ids you dont accept, a "blackist" (likely very small and each record expires as the token expires). This can be kept in-memory Vs doing a network request to your DB and searching a table that could have millions of rows.
Well this is what I mean by "persisted in any way." A blacklist is still persistence.