5 ms·

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 do

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.

bpicolo 5y ago
Definitely use cookies. Opaque tokens. Works great. 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.
ORioN63 5y ago
Refresh tokens are the real alternative, IMO. I kinda agree it looks like an ad for redis, since it doesn't even considers alternatives.
- allset_ 5y ago
  Agreed. Long(er) lived refresh tokens, and then having signed access tokens such as JWTs so that the API server doesn't have to hit the database on every request.
- digianarchist 5y ago
  Hasura [0] has a great article on how to make front end authentication as secure as possible. [0] - https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/ https://hasura.io/blog/best-practices-of-using-jwt-with-grap...
jmcgough 5y ago
There's "JWT hate" articles on HN because people keep implementing JWT auth without understanding it - they want an easy, cheap way to do auth when talking to different services, but it can be a huge security flaw since you can't do revocation. There's a lot of ways to configure JWT, so it's very easy to shoot yourself in the foot. 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.
- node-bayarea 5y ago
  +1
lstamour 5y ago
You could have short-lived JWT tokens so it wouldn’t matter because they only last 5-10 minutes or less. They could be refreshed or if using OAuth, simply redirect an unauthenticated user and they’ll be reissued based on the cookies stored by the OAuth provider… assuming the redirect doesn’t break your app of course. 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.
- edgyquant 5y ago
  Aren’t JWT tokens only supposed to be good for 10-15 minutes? I know using flask-jwt you have to go out of your way to make them last longer than that and it isn’t recommended.
  - Grimm1 5y ago
    Yes but a lot of times people don't do that properly, some frameworks have incorrect defaults or people don't want to deal with writing the logic to handle refreshing tokens after that 10-15 minute window etc etc. They are insecure but it's not a problem if you follow best practices like those, the difficulty is a lot of people don't because they don't really understand what it is they're doing or potentially causing by making the changes that let them be lazy or do things the easy way. You could probably change the title to articles like this from "JWT Tokens are NOT safe" to "JWT Tokens are NOT safe when you ignore all security practices and take the easy way out" but that doesn't make for a flashy title.
deleted 5y ago
[deleted]
jakelazaroff 5y ago
No solution is universal. That said: use sessions. They’ve worked fine for decades and there’s a 99% chance they work fine for your app.
CiPHPerCoder 5y ago
https://paseto.io https://paseto.io
PaulHoule 5y ago
It is funny that this is the way most web auth systems worked back before the JWT brand was invented. I made one that had a prefix extension bug, but you didn’t see the marketing drumbeat against it until it got a name and you could paint a target on its back. (E.g. branding something is often a transition from people using language as a club against hunger, wild animals and the unknown to using it as a club against the other man.) It is not unusual for systems like this to have some details such as verifying the cookie against the db if somebody is doing a critical operation and not being too worried about a five minute window for people reading articles and such. High volume attacks need their own countermeasures.
hamburglar 5y ago
There’s no reason to put all the user info in redis and this article makes no valid argument for it. Give the token a unique ID and store that ID in redis (or some other fast store). Validate the token by checking its sig and verifying that its ID is in redis. Store all the signed metadata you want on the client, revoke it by removing its ID from redis. Addresses all cases where the token is stale. So basically redis becomes your token whitelist, not your store of user metadata. Problem solved. Signed blobs of data such as certificates and web tokens are a very powerful massively distributed cache where the entity that benefits from the data being cached is also the entity responsible for persisting it. This is a wonderful optimization whose sole drawback is that you need an external way to decide when that entry is invalid. Solve that problem, don’t abandon the entire concept of the distributed cache.
heterodoxxed 5y ago
Simple session tokens are fine, always have been.
yepitis 5y ago
It is an ad. OP's recent post history are all Redis ads.
pabs3 5y ago
TLS client certs?

bpicolo 5y ago

Definitely use cookies. Opaque tokens. Works great. 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.

ORioN63 5y ago

Refresh tokens are the real alternative, IMO. I kinda agree it looks like an ad for redis, since it doesn't even considers alternatives.

allset_ 5y ago
Agreed. Long(er) lived refresh tokens, and then having signed access tokens such as JWTs so that the API server doesn't have to hit the database on every request.
digianarchist 5y ago
Hasura [0] has a great article on how to make front end authentication as secure as possible. [0] - https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/ https://hasura.io/blog/best-practices-of-using-jwt-with-grap...

jmcgough 5y ago

There's "JWT hate" articles on HN because people keep implementing JWT auth without understanding it - they want an easy, cheap way to do auth when talking to different services, but it can be a huge security flaw since you can't do revocation. There's a lot of ways to configure JWT, so it's very easy to shoot yourself in the foot. 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.

node-bayarea 5y ago
+1

lstamour 5y ago

You could have short-lived JWT tokens so it wouldn’t matter because they only last 5-10 minutes or less. They could be refreshed or if using OAuth, simply redirect an unauthenticated user and they’ll be reissued based on the cookies stored by the OAuth provider… assuming the redirect doesn’t break your app of course. 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.

edgyquant 5y ago
Aren’t JWT tokens only supposed to be good for 10-15 minutes? I know using flask-jwt you have to go out of your way to make them last longer than that and it isn’t recommended.
- Grimm1 5y ago
  Yes but a lot of times people don't do that properly, some frameworks have incorrect defaults or people don't want to deal with writing the logic to handle refreshing tokens after that 10-15 minute window etc etc. They are insecure but it's not a problem if you follow best practices like those, the difficulty is a lot of people don't because they don't really understand what it is they're doing or potentially causing by making the changes that let them be lazy or do things the easy way. You could probably change the title to articles like this from "JWT Tokens are NOT safe" to "JWT Tokens are NOT safe when you ignore all security practices and take the easy way out" but that doesn't make for a flashy title.

deleted 5y ago

[deleted]

jakelazaroff 5y ago

No solution is universal. That said: use sessions. They’ve worked fine for decades and there’s a 99% chance they work fine for your app.

CiPHPerCoder 5y ago

https://paseto.io https://paseto.io

PaulHoule 5y ago

It is funny that this is the way most web auth systems worked back before the JWT brand was invented. I made one that had a prefix extension bug, but you didn’t see the marketing drumbeat against it until it got a name and you could paint a target on its back. (E.g. branding something is often a transition from people using language as a club against hunger, wild animals and the unknown to using it as a club against the other man.) It is not unusual for systems like this to have some details such as verifying the cookie against the db if somebody is doing a critical operation and not being too worried about a five minute window for people reading articles and such. High volume attacks need their own countermeasures.

hamburglar 5y ago

There’s no reason to put all the user info in redis and this article makes no valid argument for it. Give the token a unique ID and store that ID in redis (or some other fast store). Validate the token by checking its sig and verifying that its ID is in redis. Store all the signed metadata you want on the client, revoke it by removing its ID from redis. Addresses all cases where the token is stale. So basically redis becomes your token whitelist, not your store of user metadata. Problem solved. Signed blobs of data such as certificates and web tokens are a very powerful massively distributed cache where the entity that benefits from the data being cached is also the entity responsible for persisting it. This is a wonderful optimization whose sole drawback is that you need an external way to decide when that entry is invalid. Solve that problem, don’t abandon the entire concept of the distributed cache.

heterodoxxed 5y ago

Simple session tokens are fine, always have been.

yepitis 5y ago

It is an ad. OP's recent post history are all Redis ads.

pabs3 5y ago

TLS client certs?