Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Web Tokens should be avoided

paragonie.com

Post reply on HN
Print view View original

111–120 of 304 posts

Re: JSON Web Tokens should be avoided

#111

Post by Ajedi32 »

mgkimsal wrote: post #102
StevePerkins wrote: post #70

The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…

> If I'm providing a REST API, then I'd prefer a token string that I could pass as a header value rather than forcing the use of cookies Aren't cookies just strings passed as HTTP headers?

The very next sentence:

> Although I suppose you could argue that a cookie is just another header value.

So... yes.

Re: JSON Web Tokens should be avoided

#112

Post by lostcolony »

saint_fiasco wrote: post #99
true_religion wrote: post #76

Earlier quoted context omitted.

I was under the impression that newly minted developers would use existing libraries and frameworks, which have already take security into account.

The article points out that many popular libraries have vulnerabilities and unsafe defaults.

Which to me says that relying on there not being any footguns is wishful thinking. The better recourse, to my mind, is to stress the need for mentorship, so people learn to proactively look out for traps.

Re: JSON Web Tokens should be avoided

#113

Post by scottmf »

tptacek wrote: post #77
StevePerkins wrote: post #70

The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…

I don't care if you want to use stateless client tokens. They're fine. You should understand the operational limitations (they may keep you up late on a Friday scrambling to deploy a token blacklist), but, we're all adults here, and you can make your own decisions about that. The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, yo…

> there's a reason crypto people hate the JWT/JOSE/JWE standards. You should avoid them

Could you give more info about this? If ECDHE-ES is avoided why else is JWT insecure?

Re: JSON Web Tokens should be avoided

#114

Post by mgkimsal »

Ajedi32 wrote: post #111
mgkimsal wrote: post #102

Earlier quoted context omitted.

> If I'm providing a REST API, then I'd prefer a token string that I could pass as a header value rather than forcing the use of cookies Aren't cookies just strings passed as HTTP headers?

The very next sentence: > Although I suppose you could argue that a cookie is just another header value. So... yes.

Ack - missed that - was visually jumping around some.

But yes, it is.

Re: JSON Web Tokens should be avoided

#115

Post by [deleted] »

scottmf wrote: post #113
tptacek wrote: post #77

Earlier quoted context omitted.

I don't care if you want to use stateless client tokens. They're fine. You should understand the operational limitations (they may keep you up late on a Friday scrambling to deploy a token blacklist), but, we're all adults here, and you can make your own decisions about that. The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, yo…

> there's a reason crypto people hate the JWT/JOSE/JWE standards. You should avoid them Could you give more info about this? If ECDHE-ES is avoided why else is JWT insecure?

[deleted]

Re: JSON Web Tokens should be avoided

#116

Post by tptacek »

scottmf wrote: post #113
tptacek wrote: post #77

Earlier quoted context omitted.

I don't care if you want to use stateless client tokens. They're fine. You should understand the operational limitations (they may keep you up late on a Friday scrambling to deploy a token blacklist), but, we're all adults here, and you can make your own decisions about that. The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, yo…

> there's a reason crypto people hate the JWT/JOSE/JWE standards. You should avoid them Could you give more info about this? If ECDHE-ES is avoided why else is JWT insecure?

https://news.ycombinator.com/item?id=13866983

Re: JSON Web Tokens should be avoided

#117

Post by tboyd47 »

JWT is to HTTP Basic what OAuth2 is to logging in.

Auth doesn't have to be complicated to be effective.

Developers know/care very little about information security and a lot about following "standards" and "best practices."

Google and Facebook have learned over the years to take advantage of this.

Re: JSON Web Tokens should be avoided

#118

Post by Chris2048 »

lr4444lr wrote: post #80
StevePerkins wrote: post #70

The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…

Either way, if you're serving up a REST API to a JavaScript UI... what's NOT a good option is server-side session state (e.g. Java servlet sessions) Can you explain what you mean, as oppose to other kinds of session tokens? Roy Fielding makes it abundantly clear[0] in the seminal delineation of REST that We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the cl…

So, does this include web tokens too, or is auth a special case?

Re: JSON Web Tokens should be avoided

#119

Post by Chris2048 »

falcolas wrote: post #95
meddlepal wrote: post #90

Earlier quoted context omitted.

I feel like the argument against #2 is usually purely hypothetical in nature. I really do not have a problem maintaining a small lookup cache for revocations. I feel like the argument against doing this tries to take the form of all server-side kept state is bad when in reality it's sticky state and huge object graphs (read: memory consumption) that get stuffed into session objects that are the real evil. A server wi…

Sure, revocation lists are relatively small. But they need to be available to every server (replication), be proof against server/service restarts (durable), and checked with every request (highly performant). So, a good revocation list effectively requires a database. Not a trivial thing to implement yourself, and a weighty requirement for an otherwise stateless service.

Could you just have per-server tokens? Wouldn't a single client tend to hit just one server anyway?

Re: JSON Web Tokens should be avoided

#120

Post by vkjv »

floatboth wrote: post #30
Freak_NL wrote: post #17

Earlier quoted context omitted.

Session invalidation is possible though, by maintaining a (short) blacklist of tokens on the server. JSON Web Tokens can be given an ID (via the jti claim), and server-side these IDs can be matched against this blacklist. When you log out, you send a request to the service that your current token be blacklisted. Because JSON Web Tokens are short-lived, the blacklist need only contain tokens valid for validity period…

Yeah, and that's kinda sad because now you have to check a signature AND query a database!

Store it in a DB for persistence, but push it out to application memory. If for some reason you expect your blacklist to be very large (maybe, you have a massively popular API?), push a bloom filter of the blacklist instead of the actual list.

Now, you (probably) only absorb the DB hit on blacklisted tokens.

Post reply on HN