Hacker News Reader

Comment by spookthesunset | Hacker News Reader

> why do you need stateless auth tokens?

So you aren't hitting some validation server on every HTTP request to validate a token. Said validation server adds a very nasty point of failure & potential for page latency.

Going mostly stateless via JWT lets you balance the desire for fast token revocation times and load on your auth server. Even if your revocation time is a minute, meaning your clients need to refresh their token once every sixty seconds, that can still substantially lighten the load on your auth server. High security stuff can always validate the token on every request but stuff that doesn't matter as much can have a much more policy.

View on HN

> So you aren't hitting some validation server on every HTTP request to validate a token.

This is not a real problem for the 99.9% case and you can add another nine if you aren't defaulting to "extreme conservative"on your risk analysis. A session token lookup in a Redis or a Postgres is completely trivial and cheap.

("But my auth service is over a network link," cries the architecture astronaut, who now has more problems and fewer solutions. Build simpler things, you almost certainly don't need more complex and you can build better solutions than JWT when you need them.)

JWT is much simpler architecture than looking up session tokens every request.

Until you need revocation.

Which is to say until you need a working authentication system.

JWTs solve a nonexistent problem in the 99.9% case but are so very, very bloggable that they've brainwormed the population but good.

It’s a trade off dude. You trade off the ability to revoke a token instantly for fewer backend calls. For most parts of your site (99.9%) that trade off is fine. For the parts where it isn’t fine you... call the auth server every request.

JWT doesn’t mean you give up anything....

That's demonstrably not true; it might be more efficient for loaded systems, but it's certainly not simpler.

Looking up an ID in a database is much simpler that using JWTs (which involve crypto) and handling revocation.

Libraries might hide a lot of the complexity of JWTs behind abstractions, but that doesn't mean it doesn't exist.

Oh please... you are seriously going to argue it is less complex call a database or redis than it is to locally validate a token using proven crypto methods that have existed for decades?

If you are gonna play the “look under the layers of abstraction to count true complexity” game.... your assertion falls apart in a hurry. Calling a database or redis every http request is a hell of a lot more complex in terms of call stack, configuration, network dependencies and library support than JWT.

But it is a stupid way to frame your argument to begin with. Both ways abstract all their doings behind a library. Both probably have almost the same general configuration foot print. And JWT has the benefit that you can still treat it like a session token and validate on every call for parts of your site that need it. Most sites do not need to instantly revoke a token everywhere!

The number of detractors around here who don’t understand that last point is pretty sad...

While I think your response is overly harsh, I could have phrased my argument better. What I'm getting at is that the JWT spec has issues, JWTs are complex to get right, and they have (notorious) encryption footguns. Connecting to a database is a relatively simple affair.

For the record, I'm not a JWT "detractor" (if you look elsewhere in this thread you'll find a comment where I used it to good effect).

Network latencies and round trips will almost certainly be the primary source of performance issues in any larger microservice environment. If you don’t need that level of scale, that’s great. But once you do, JWTs are perfect for carrying information across the network that may be verified without extra network calls involved.

> But once you do

Sure.

The vanishing minority of projects ever get to that point.

Didn't we internalize YAGNI literally a decade ago?

A vanishingly small minority of projects need the ability to instantly revoke a token on every HTTP request. And even then there is nothing stopping you from doing so with JWT.

Know your facts. And YAGNI and all that...

"Logout all my sessions" is basic decency towards your user.

I get that it's hard with your bloggable thing, but it's better for the people on the other end.

I worked at a place which had local server in-memory cache talking to local Redis cache talking to shared Redis cache talking to MySQL session tables and the traffic to the actual session tables was still heavy enough that they had to sit on their own DB cluster. Switching to signed session cookies encoding a few bits of information (or JWTs if you prefer a mad complicated outsourcing) would have been a huge win on that point.

What sort of traffic levels were you hitting?

> "But my auth service is over a network link," cries the architecture astronaut, who now has more problems and fewer solutions.

There are at least a few cases where a central auth service makes sense. Gov't here uses it for example, so that the services from all the various departments and whatnot don't have to roll their own auth.

Certainly there are! Nobody's saying otherwise. But they are few, they are far between, and if they manage anything important they should be using OAuth to validate identity and provide credentials that the services check on-request.

That's exactly what they're doing, using JWT for OAuth 2.0 bearer tokens.

Which is not checking on-request. If a token is invalidated, it must be rejected inline. Otherwise, you're just fucking around. Which, if you aren't doing anything important, sure, fine--the problem is that most of the folks who leap to poorly-specified jank like JWT are doing important things with tools they don't understand and the people that are impacted are downstream of them.

Not sure what you mean, and I might have explained their setup wrongly, I'm no expert in this.

I ask for an access token from auth server, I pass access token to API server, API server optionally checks with auth server if token is ok, or if token is self-contained, verifies signature, checks expiration time etc.

Obviously self-contained tokens cannot be revoked, they can only expire.

For this service, JWT is used when requesting an access token, and as an access token for self-contained tokens.

The only architecture astronaut around here would be the one who makes up requirements like “needs to validate every request against a backend auth server” and “network calls to an auth server are cheaper and easier than local token verification”.

The crypto used for JWT not some brand new space age thing. Public key cryptography has existed for decades now.

JWT is a very elegant solution to the problem space once you understand what it does. I get the feeling the actual architecture astronauts are the folks around here dismissing it.

Implementing a logout-all-sessions function is not the behavior of an architecture astronaut--but building distributed auth because you footgunned yourself with microservices certainly is. And to implement that with JWT you aren't doing local validation because you can't do validation without implementing revocation and you've devolved back to checking a store for validity anyway.

That might not matter to you because you might not work on things that matter and that's fine. If what you work on doesn't matter, do whatever you want, but if it does, don't use JWT.

Reply on news.ycombinator.com