JSON Web Tokens should be avoided

Re:JSON Web Tokens should be avoided by meddlepal on Tuesday March 14, 2017 @08:42AM (#13867008)

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 with 1GB can hold a lot of JWT's in memory. Probably more than most of the people building services here have to actually deal with.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by falcolas on Tuesday March 14, 2017 @08:54AM (#13867083)

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.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by unscaled on Tuesday March 14, 2017 @12:32PM (#13868966)

JWT are even smaller than their size since you can revoke them by hash (although you should really just revoke by user ID in most cases).

Your tokens should generally have a rather short lifetime - then you can keep the entire relevant window of revocations in memory.

The implementation is not trivial though, that's for sure.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by justinclift on Tuesday March 14, 2017 @09:17AM (#13867228)

Hmmm, using a database (eg PG) for the authoritative information, with memcached in front sounds like it would be practical for most uses.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by falcolas on Tuesday March 14, 2017 @09:54AM (#13867459)

At which point you should probably ask yourself: "What value is keeping all of my state inside this token providing me?"

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by mwpmaybe on Tuesday March 14, 2017 @10:40AM (#13867811)

Probably not. If the Pg instance is replicated, as indicated above, it'll be challenging to keep the Memcached copy in sync. In other words, you can't just use the caching feature of your ORM, you'll need another piece.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by justinclift on Tuesday March 14, 2017 @01:44PM (#13869716)

Thanks, that does need further thinking about. :)

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by cygned on Wednesday March 15, 2017 @10:20AM (#13876257)

Postgres is not a good solution for this kind of data. I'd use Redis, but maybe there are even better products.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by Chris2048 on Tuesday March 14, 2017 @09:28AM (#13867321)

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

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by dkersten on Tuesday March 14, 2017 @09:41AM (#13867360)

Wouldn't a single client tend to hit just one server anyway?

No? Maybe? It depends on your load balancer. Assigning a client to a specific server is "sticky sessions". Many of us don't want to tie a client to a specific server and prefer a completely stateless 12-factor-style mechanism where any server can serve the client and stateless tokens provide a mechanism to achieve this.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by tracker1 on Tuesday March 14, 2017 @02:44PM (#13870269)

Not to mention the challenges with multi-region replication needs... to do this for every request along a server-server pipeline adds more latency still, since each request to the db means potentially 2-3ms on top of more complex requests, which all adds up.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by Chris2048 on Wednesday March 15, 2017 @10:49AM (#13876461)

> and stateless tokens provide a mechanism to achieve this

without revocation. What's wrong with tieing a client to a server, or co-located server? Either they are close enough to share tokens / sync fast, or not?

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by dkersten on Thursday March 16, 2017 @05:59AM (#13883787)

What's wrong with tieing a client to a server, or co-located server?

Nothing, if you can get away with it. What do you do if your server dies or is overloaded? The 12-factor patterns came to be for services running on ephemeral hosts in cloud environments. Stateless servers mean you can seamlessly serve requests from another server without problem. Sure, you can store the sessions in a shared resource (redis perhaps?) but this complicated failover and redundancy and may add latency.

Maybe this isn't an issue, maybe it is. If you don't need or want that, then just use normal sessions, for sure.

Revocation can be handled (although admittedly not as well as with sessions or stored tokens) through short TTL's and refresh tokens (which are stored, but only need to be looked up when the stateless token expires). Its not perfect, but its often a good enough tradeoff.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by rblatz on Tuesday March 14, 2017 @10:38AM (#13867796)

What if you are running dozens of services each specializing in its own domain? Do you proxy each service through a pool of central webservers? Or do you just stand up a central auth server and have each service trust that auth server?

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by Chris2048 on Wednesday March 15, 2017 @10:52AM (#13876481)

The latter makes sense to me. Auth is a cross-cutting concern.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by elithrar on Tuesday March 14, 2017 @09:42AM (#13867365)

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.

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by infogulch on Tuesday March 14, 2017 @12:03PM (#13868666)

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).

[ Parent | on HN ]

Re:JSON Web Tokens should be avoided by tracker1 on Tuesday March 14, 2017 @02:41PM (#13870245)

Or better, have a really short lived requirement for server-server jwts (I suggest even 1m, having a new one per request).

For client-server a 5 minute refresh is fine, as long as you do a lookup for refresh, so you can expire refresh tokens, requiring a full re-auth.

[ Parent | on HN ]