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

181–190 of 304 posts

Re: JSON Web Tokens should be avoided

#181

Post by jjawssd »

chmike wrote: post #168
jchw wrote: post #147

Earlier quoted context omitted.

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 eff…

Or you can use read only Redis replication and keep your architecture pretty much the same https://redis.io/topics/replication

Re: JSON Web Tokens should be avoided

#182

Post by infogulch »

elithrar wrote: post #127
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…

If you go so far as to maintain a revocation store that is checked on each request, you might as well just use that same store for full-blown server-side sessions. By your measure, 1GB can store a lot of tokens in memory: 32B tokens + that again as metadata (e.g. user ID + TTL in Redis) = 15,625,000 tokens.

No, the session state itself may be orders of magnitude larger than an id. At 4 bytes per token you can store up to 250M ids per 1 GB. But session state might store kilobytes of data per user for roles, permissions, names, descriptions, links etc.

And you're overestimating the necessary size of a revocation store. Only a tiny fraction of your users ever log out or otherwise invalidate session via means other than TTL. You're looking at storing just a couple thousand 4-8 byte revoked session ids and ttls instead of gigabytes of session data.

If you have a security breach and need to invalidate all tokens, just reject all tokens with an issue date before it's fixed. And they all fall off anyway after a week (or however long the ttl is).

Re: JSON Web Tokens should be avoided

#183

Post by dragonwriter »

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…

None of that violates REST; REST is not statelessness. In fact, REST (REpresentational State Transfer) is all about state and how it is changed and how those changes are manifested.

Re: JSON Web Tokens should be avoided

#184

Post by woah »

arethuza wrote: post #164
zeveb wrote: post #159

Earlier quoted context omitted.

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?

Afaik you just need to alphabetize the properties of every object

Re: JSON Web Tokens should be avoided

#185

Post by woah »

throwaway2016a wrote: post #130
lr4444lr wrote: post #80

Earlier quoted context omitted.

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…

> This has given me pause to doubt just how many people are really implementing REST, and/or how useful a model it is in modern web applications. Not many. I've made a good career out of consulting people who are doing REST wrong :) Usually they are either storing state or forgetting about HTAEOAS (Hypermedia). Often they are also negotiated format and version incorrectly and in a way that doesn't scale.

I'm going to contend that a "correct" implementation of REST has never existed

Re: JSON Web Tokens should be avoided

#186

Post by throwaway2016a »

throwaway2016a wrote: post #131
scandox wrote: post #47

I use stateful JWTs for session management, storing them in localStorage. If someone can exfiltrate the token, they will get a week long authorization, as well as some identifiable information (username, name and role). Probably I can achieve the same overall system with cryptographically secure session cookies, that are persisted in a database, or other store that is accessible across multiple servers. I guess it wo…

> So overall while I don't know how right he is, I feel like maybe he has a point. Why not just use cookies? Because in a highly distributed system hitting a database to validate authorization is expensive and causes bottlenecks. A cookie that requires you to hit the database does not solve that issue. Although if the cookie was signed some way that can be cryptographically verified then great. But then you are essen…

I probably got down-voted because I conflated cookie with session token cookies. You can of course have a cookie that does not require a database lookup to validate.

But JWT takes care of having the expiry signed in the value (in a cookie the expiry is more of a suggestion that a modified client could ignore). Combine that with low expiry JWT tokens and high expiry refresh tokens (subject to more validation) I think it is a clear winner.

Re: JSON Web Tokens should be avoided

#187

Post by stephenr »

StreamBright wrote: post #13

>> A lot of developers try to use JWT to avoid server-side storage for sessions. This is based on what? Sounds like he just made it up. His other claims does not look sound to much more either. I would like to see a more in-depth analysis on the subject, this all looks very hand-wavy to me.

> This is based on what?

Based on the entire reason JWT is even a thing? Developers love to believe every app they build is going to run at the scale of Facebook to the power of Google times Twitter, and thus needs to run on 10,000 Docker instances spread across 15 data centres around the globe (and soon, one on the moon!).

Relying on server-side sessions is "terrible" because you have to talk to the backend, and you need to keep the data synchronised in a manner that all 10,000 Docker instances can read/write to it instantly. So instead, a new concept was devised, whereby you use these stateless tokens that don't rely on the same server after issuing.

Of course, it's impossible to invalidate them individually, and they're either insecure (available to JS) or stored in a cookie, and thus sent with every request, which means, due to their larger size than regular session cookies, more data on each request.

So.. that. That is what it's based on.

Edit: added missed word "same".

Re: JSON Web Tokens should be avoided

#188

Post by mwpmaybe »

floatboth wrote: post #34

"Just use cookies over HTTPS [instead of JWT]" is weird advice. I mean, JWT goes… inside… things like cookies. (or the Authorization header in APIs, of course)

This drives me nuts. To expand on your point, there are a number of separate, debatable design decisions that seem to get conflated all the time:

* Transport: how the session ID or token is shipped between clients and servers (authorization header, cookie headers, or payload).

* Storage: how the session ID or token is stored on clients (cookies, localStorage, sessionStorage, or in memory).

* Statefulness: whether to use a stateless token (with or without a revocation list) or a stateful, server-side session.

* Encryption and/or signing

* Structure/standardization

Examples:

* JWT generates structured, stateless tokens that are signed—and optionally encrypted (JWE)—with the implementor's choice of algorithm. The tokens can be transported and stored by any mechanisms.

* Rack::Session::Cookie (in Ruby) generates unstructured, stateless tokens that are signed—not encrypted—with HMAC. The tokens are transported and stored as cookies.

* Rack::Session::Pool (also in Ruby) maintains an in-memory store of unstructured, stateful sessions. Unsigned and unencrypted session IDs are transported and stored as cookies.

The point being that you can really mix and match. You can even send a session ID in a header and store it as a non-HttpOnly-cookie on the client. Anything goes!

Re: JSON Web Tokens should be avoided

#189

Post by danjoc »

tptacek wrote: post #180
danjoc wrote: post #161

Earlier quoted context omitted.

>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 solici…

I don't care about these moral arguments. I'm making a simple, positive claim: JWT is bad. You can blame whoever you'd like for it being bad, but as engineers, you need to understand first and foremost that JWT is bad, and reckon with your feelings about that later. You have a responsibility to built trustworthy systems, and you get no pass on building with flawed components simply because you wish experts had made t…

I have no feelings on the subject. I don't use JWT. I just want to point out this sounds like (and continues to sound like) "Roll your own" advice to me.

Re: JSON Web Tokens should be avoided

#190

Post by throwaway2016a »

falcolas wrote: post #137
throwaway2016a wrote: post #131

Earlier quoted context omitted.

> So overall while I don't know how right he is, I feel like maybe he has a point. Why not just use cookies? Because in a highly distributed system hitting a database to validate authorization is expensive and causes bottlenecks. A cookie that requires you to hit the database does not solve that issue. Although if the cookie was signed some way that can be cryptographically verified then great. But then you are essen…

> Because in a highly distributed system hitting a database to validate authorization is expensive and causes bottlenecks. Don't you have to do something similar to invalidate tokens anyway?

> Don't you have to do something similar to invalidate tokens anyway?

Not exactly..

1. Invalidation lists can be held in memory easier than an entire token database. And if the invalidation list is huge you can distribute a bloom filter across your nodes and use that to check before hitting the database.

2. As another poster pointed out. Bearer JWT tokens are meant to be short lived. If your implementation is ontop of OAuth use a longer lived refresh token to get a new bearer token every so often (say half an hour). So if you are OK with your invalidated tokens being OK for "up to" the expiry (so up to half an hour in this example) you only need to do strong validation on the refresh tokens.

Post reply on HN