If you like Ptacek, read this: https://latacora.micro.blog/2019/07/24/how-not-to.html
But more importantly, why do you need stateless auth tokens?
But more importantly, 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.
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.)
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.
JWT doesn’t mean you give up anything....
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.
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...
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).
Sure.
The vanishing minority of projects ever get to that point.
Didn't we internalize YAGNI literally a decade ago?
Know your facts. And YAGNI and all that...
I get that it's hard with your bloggable thing, but it's better for the people on the other end.
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.
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 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.
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.