JSON Web Tokens should be avoided

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 ]