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

161–170 of 304 posts

Re: JSON Web Tokens should be avoided

#161

Post by danjoc »

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…

>that rebuts the (I think sort of silly) presumption that whatever an app uses needs to be RFC standardized.

I thought crypto mantra was "Never roll your own." An RFC (Request For Comments) is a literal attempt to follow that advice by seeking the advice of cryptographers who are presumably smarter at coming up with crypto standards. Where were the cryptographers during the draft phase when comments were being solicited?

>I think it's literally the case that no cryptographer bothered to point this out before because they all assumed people knew JWT was a tire fire.

Oh. Cunningham's Law. You know, if you're not part of the solution, you're part of the precipitate.

That's some considerable JWT fallout, since companies making a business out of security are endorsing it. Auth0 for example, https://auth0.com/docs/jwt

Until I read this article, I was under the impression JWT was the best new thing.

Re: JSON Web Tokens should be avoided

#162

Post by zeveb »

Klathmon wrote: post #58
cptskippy wrote: post #56

Earlier quoted context omitted.

Wouldn't you need to assign your cookies to the TLD for them to be accessible to both subdomains?

We only wanted them assigned to the subdomain that needed them (api.hostname.com), and we set it up that way to make sure we wouldn't accidentally expose cookies to other domains down the line.

I think you should probably have used another common parent domain, like app.web.hostname.com & api.web.hostname.com, with the cookies set for *.web.hostname.com (or something).

Re: JSON Web Tokens should be avoided

#163

Post by mspradley »

hardwaresofton wrote: post #63

Can anyone think of some criticism for simply storing an API key and secret in localstorage for a web client? It's 50% bridging the gap between using cookies and a normal API and 50% simplifying frontends. The scheme I'm currently using on a project goes like this: 1. Web client ("offline-first" SPA app) hits HTTPS backend in with username and password 2. Web client receives a a generated API key and secret, which ex…

It requires looking up the secret on the backend. The JWT doesn't require that.

Re: JSON Web Tokens should be avoided

#164

Post by arethuza »

zeveb wrote: post #159
arethuza wrote: post #155

Earlier quoted context omitted.

"json being sorted without whitespace" What is the significance of that part?

It makes JSON deterministic, which it isn't by default (e.g. {"foo": 1, "bar": 2} and {"bar":2,"foo":1} are both valid serialisations. Of course, it'd be better still to use a format _meant_ to provide human-readable canonical representations of data, e.g. Ron Rivest's canonical S-expressions ( http://people.csail.mit.edu/rivest/Sexp.txt ), but of course this is information technology and we have to reinvent the whee…

Ah yes, similar to canonicalization of XML for XMLSignature?

Presumably this means that you have to have have a "flat" JSON structure rather than lots of nested objects and arrays?

Re: JSON Web Tokens should be avoided

#165

Post by throwawaysed »

This article has little substance. The arguments don't apply to JWT, it just mentions badly done implementations and an insecure option that obviously nobody would turn on.

What else are we going to use? JWT is basically the simplest token protocol possible that maintains antiforgery properties. It's great that somebody standardized something that most API's were using anyways. If you give anyone that knows crypto the task of making a simple token protocol they will come up with JWT over and over.

Re: JSON Web Tokens should be avoided

#166

Post by davewritescode »

Kiro wrote: post #101

OT but I need a wake-up call here. Upon login I'm sending back a generated UUID tied to the account and saves it as a cookie in the client. What's wrong with this approach?

The only problem I can see is that depending on how you're generating the UUID you might be providing UUIDs that are guessable by a 3rd party.

Re: JSON Web Tokens should be avoided

#167

Post by jayd16 »

lr4444lr wrote: post #121
meric wrote: post #108

Earlier quoted context omitted.

IMO sessions for authentication is fine as long as we don't store any session variables. In the end someone's going to be keeping track of the number of GET requests made by each API consumer on each endpoint, and practically it's not breaking REST as long as that state doesn't affect the information GETable by the client.

I just can't reconcile the fact that if I hit an endpoint, and I get back certain data with a 2XX response code because I previously accessed a "login" resource, but I would have gotten a 4XX response code if I had not gone to that prior "login" resource that I haven't violated REST: my request for the second endpoint takes advantage of stored context on the server. Even worse, if I restart the server, change out its…

Rest doesn't mean no state in the world exists. It's not a violation at all that an endpoint changes its output. Rest only reasons about idempotency, not reproducibility.

Re: JSON Web Tokens should be avoided

#168

Post by chmike »

jchw wrote: post #147
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…

What's difficult about setting up a Redis cluster to back sessions? Yes, it adds a point of failure... so does having a database of any kind. However, I'd hardly call it difficult. If you're on Amazon, you can just create an Elasticache cluster and not even concern yourself with the ops. I don't hate secure cookies or anything, but some people act like plain-old regular cookies haven't been thoroughly solved by this…

When the authentication info needs to be used with servers in different location of the world, JWT is better. Getting the session info from a redis server or something equivalent isn't free. Deciphering a JWT token may be faster. So, the most appropriate method depends on the use case.

If all the servers are in one location, a random byte sequence as session id key with cached info is the most simple, compact and efficient.

Re: JSON Web Tokens should be avoided

#169

Post by mwpmaybe »

awjr wrote: post #29

I'm really confused by this post, a signed JWT is issued by the identity provider (or API end point) and is then validated again by the API end point when part of an API call, usually as a bearer token in the header. The validation of the signed JWT is done via the API. The approach I use is to have a 'use once' refresh token (long timeout) and a security token (short time out) and JTIs to hold a list of logged out/i…

> The approach I use is to have a 'use once' refresh token (long timeout) and a security token (short time out) and JTIs to hold a list of logged out/invalid (refresh token used twice) security token IDs.

Here's what I've never understood about this approach: the browser can send many requests at the same time, over the same (HTTP/2) or different (HTTP/1.1) connections. If, say, six requests hit your backend at the same time, all with the same refresh and security tokens, with four more queued up on the user-agent, and the security token is expired, how do you know:

1. that all ten requests are valid,

2. to revoke the security token once,

3. to generate one new security token,

4. to mark the refresh token as used,

5. to generate one new refresh token?

Is it as simple as granting some leeway on how long the tokens can be used after they expire/are revoked? Do you have some way of serializing requests on the client to prevent this from happening? Or do you assign all ten requests the same "batch" ID and tie them together on the backend somehow? Do you do a preflight request to refresh the security token if it's expired?

Re: JSON Web Tokens should be avoided

#170

Post by unscaled »

Alex3917 wrote: post #149
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…

> they may keep you up late on a Friday scrambling to deploy a token blacklist Because every token has an iat datetime, you don't need a token blacklist to invalidate tokens. You just need some sort of tokens_invalid_if_issued_before_datetime setting that gets checked whenever you validate the signature of a token. The alternative is to store a UUID for each user, and just rotate those whenever they log out, change o…

Agreed. Revoking all user sessions instead of a specific token is the common case. The only usage I see for revoking a specific token is when the user is deactivating a specific client.
Post reply on HN