11–20 of 115 posts
OK, but what's the real alternative here? I'm sick of these JWT hate articles on HN all the time with no universal solution. Why not just use cookies and be done with it? This looks like an advertisement for Redis Enterprise.
All the good versions involve cookies somewhere - they’re the most resistant to all the various forms of attackers on the web.
Many use cookies in order to stamp short lived tokens, though.
OK, but what's the real alternative here? I'm sick of these JWT hate articles on HN all the time with no universal solution. Why not just use cookies and be done with it? This looks like an advertisement for Redis Enterprise.
I kinda agree it looks like an ad for redis, since it doesn't even considers alternatives.
> Security should be binary. Either technology is secure or it’s not. From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.
Ya, I hate to be pedantic too, but security it almost entirely NOT binary. It should be, but it's not.
OK, but what's the real alternative here? I'm sick of these JWT hate articles on HN all the time with no universal solution. Why not just use cookies and be done with it? This looks like an advertisement for Redis Enterprise.
Refresh tokens are the real alternative, IMO. I kinda agree it looks like an ad for redis, since it doesn't even considers alternatives.
I once watched a presentation about Macarons [ https://en.wikipedia.org/wiki/Macaroons_(computer_science) ] that is purportedly better than JWT. Are there any good success stories about using this?
- Holder of macaroon can issue a sub-macaroon with smaller power, while JWT is fixed
- Macaroon is notably longer than JWT
- Macaroon is equivalent to signed JWT, but does not offer equivalent to encrypted JWT
Let's say you keep your user sessions in Redis and replicate active-active between multiple regions. Your service allows for more than one active session per user, and has a second index of such "live sessions" so that users can terminate all of their sessions at once (eg. "Log out all of my devices").
You use optimistic concurrency to update multiple indices and pieces of information. Session mutation events and validations can occur anywhere.
What if an attacker slowly logs in thousands of different accounts, hundreds of sessions apiece, then logs everything out in unison?
Redis is single threaded, and all of your validation reads are going to get jammed with impossible to clear logout events. Replication is going to play these events out in all of your Redis clusters, meaning each of your regions will fall over. Nothing in logged-in flow can be processed, and you're stuck.
That was fun to fix.
I've got so many horror stories... Redis is great, but engineering at scale is tough even with great tools.
OK, but what's the real alternative here? I'm sick of these JWT hate articles on HN all the time with no universal solution. Why not just use cookies and be done with it? This looks like an advertisement for Redis Enterprise.
JWT for short-lived tokens is fine - it can work well for signing requests between microservices. If you want to give them to end users, use refresh tokens.
As with anything, the alternative depends on your needs and use case. There is no universal solution.
OK, but what's the real alternative here? I'm sick of these JWT hate articles on HN all the time with no universal solution. Why not just use cookies and be done with it? This looks like an advertisement for Redis Enterprise.
Alternatives? First, you could live with the possibility that tokens are valid for some period of time after logout because it usually doesn’t matter - generally you delete the cookie and the user is logged out, even if technically they could restore the cookie later. They won’t, unless you’re under attack.
Other alternatives: You could use Redis for session data as pointed out with the random key in a cookie and delete the session when done to invalidate the cookie.
You could also use Redis to keep token IDs that you want to invalidate or block. You could use something like Open Policy Agent to distribute a list of invalidated tokens to each server.
Finally, you could send your JWTs to a centralized authentication service — single point of failure, yes, but you could record invalidated tokens to memory and responses are very quick and easy to audit. With careful planning you could reduce the risks in having a single central service to validate issued tokens.
I’m sure there are other ways to mitigate this risk. The general reason why folks don’t recommend JWTs is because it’s too easy to make mistakes in the validation logic. But the same is true (with different possible mistakes) when you roll your own session cookies. At a certain point I think you have to either assume competence or you have to suggest that developers use identity proxies in the cloud, or frameworks others have written, and never implement this themselves.
But yes, this is a rather transparent advertisement for Redis as a KV session store.