Another point is that managing session data on the server-side is a pain... If your app server goes down, stale session data would be left behind in your session store; it can easily become orphaned... So you need to set an expiry on it to ensure that it will be cleaned up no matter what... But you need to keep extending the expiry while the user is still online. God forbid you create the session data before you set the expiry on it and the operation that sets the expiry fails (e.g. server crashes at the precise moment or some error occurs which causes it to be skipped)... In practice, it's hard to avoid stale/orphaned session data.
And yes, you need to store and manage more data and your session store is an additional Single Point of Failure... With JWT the revocation list is an optional... Your system can keep running without it; it just won't be able to ban users. It's a cleaner separation of concerns without SPoF.
JWTs have so many benefits over session IDs, I could write a book about all the benefits. Sure, there are some tradeoffs but the negatives are typically pretty minor or hand-wavy.
Exactly, it's like saying that Postgres is insecure because it allows SQL injection attacks when untrusted user input is injected into the query directly.
Not really. Being able to verify a user's signed identity immediately without having to do any database or memory store lookup first is valuable in itself.
With session IDs, anyone can spam/DDoS your system much more easily; they don't even need to be authenticated to waste your computing resources as they can send plausible-looking session IDs and your system will waste a ton of resources querying your session store or database to figure out that the session doesn't exist... It adds a ton of latency and wastes CPU cycles across multiple systems. Also stateful systems like Redis are harder and more expensive to scale than stateless systems like application servers. Not to mention that they may be depended upon by other parts of the application so hitting those too hard can be more disruptive. And that's kind of best-case. Some people use a database to store their session data...
At least with a revocation list with JWT. If the JWT says that the user is user1234, then you know that this is a real, previously logged-in user, they have an account at stake, you can afford to spend a bit of time/resources to check them against your revocation list... And if they are on that list, you can ban their ass and they're done! They'd have to create a new account of they try to spam you again. They can't spam without a valid JWT and they can only get that by authenticating with your server first.
Sure with JWT, some computation is spent on verifying the signature but it's very cheap using the default algorithm and only touches one system... And you only need to call another system once you know that the user is valid.
JWT is much more robust for DDoS prevention because of this. But yeah, you don't necessarily need a revocation list. You can use short JWT expiries with frequent token refreshes. Revocation list is good if you need immediate ban.
Yes but it only impacts your stateless app servers which are easier to scale. Your backend services/stores are protected and not affected by the attack.
The people who are upset about JWTs probably got burned by trying to use them in a weird way. Some people try to store sensitive data inside JWTs... WTF, the idea would never have entered my mind! Sensitive data should stay on your server. Encrypted or not! JWTs are supposed to be signed, not encrypted! You shouldn't even think to put sensitive info in there. Also, WTF is wrong with people who accepted algorithm "none." Most of these people who tried to tweak the defaults had no idea what they were doing in the first place.
> Also, WTF is wrong with people who accepted algorithm "none."
They dared to use the default validation function of their JWT library. They did not choose to accept "none".
And the library authors implemented it because it's in the spec. It doesn't excuse that the default was to accept "none", but it is an explanation and in my opinion a valid critique of the standard.
I've never had any issues with JWT. There's a group of incompetent developers who like to point to a tool as a scapegoat to distract away from their own failure to use the tool correctly.
I think the irony is that the people who make these blanket statements may be idiots themselves and that's why they think everyone else is an idiot. They can't imagine that other people don't have problems using those tools. It's a skill issue.
Some people here built embarrassingly parallel distributed systems with consistent hashing load balancers. JWT is easy by comparison.
To me, it sounds like a child putting their shoes on the wrong feet, getting blisters and concluding that nobody should wear shoes.
JWTs are extremely useful for storing basic non-secret authentication info. Session IDs are not as good for most situations and force unnecessary database or memory store lookups. JWT is a more versatile authentication construct because it doesn't prevent you from doing that extra lookup but it also doesn't force you to.
It's far better than a session ID in the sense that you can store an accountId inside a JWT and be confident about the identity of this user... The fact that you can get such confidence without any external lookups; just by looking at the token, is incredibly useful on its own. You can already seperate out unauthenticated guest users from authenticated users and you can tie their identities to real accounts without even checking the DB or session store. Banning is a separate concern. Being able to quickly, efficiently and reliably identify a user from the server-side is a necessity.
The only real downside of JWTs which people point to is that they cannot be easily be revoked... But if you really need the ability to revoke quickly, you can easily have 10 minute expiries on your tokens and request refresh every 3 minutes or so... So if you want to ban someone, there would be a 10 minute delay which is acceptable for the vast majority of scenarios... You should handle rate limiting as a separate concern anyway if spam is the issue.
For certain systems, a user may be making hundreds or thousands of requests in 10 minutes so you're saving a HUGE number of session ID lookups and it means that you don't need to run and maintain a separate Redis service or whatever else. Not to mention the additional latency which is added when you need to check Reddit before each operation.
These blanket statements against JWT are not new. People have been misusing them and blaming the tech because they don't want to acknowledge that they made implementation mistakes.
Any technology can be misused. It's foolish to misuse a perfectly good piece of tech and then use that as the basis to promote some alternative which has been through less battle-testing and which probably has even more gotchas which are yet to be discovered.
As a senior engineer with 15+ years of experience, I've seen this cycle over and over again. The new tech is always presented as fool proof and it never never never is.
100%. Most people can be very happy with very low consumption. What people want is not to work.
The happiest time in my life was when I was earning a measily $40K per year in passive income from crypto and didn't work. It was the lowest salary I ever had, least I ever consumed and happiest I'd ever been. The purpose of consumption for most people is to soothe the pain of working. If you don't work, you don't need to consume anywhere near as much. When my wife quit her job 10 years ago, our rate of savings stayed the same because we spent less and quality of life went up significantly for both of us.
Anyone who enjoys working is delusional. What they call work is not work; they're living in a parallel reality where the economy rewards them for playing the big boss and sitting on their asses and watching their money compound... Everything they're doing is meaningless; it only serves as a narrative device to justify the handouts that they'd be getting regardless. Just look at Steve Ballmer of Microsoft; he probably made more money after he resigned from the CEO role. It's incredible really when you look at Microsoft's product offerings these days; even Bill Gates knew to dump MSFT and now has less money than Ballmer. It's like the economy punishes people for having common sense.
> The purpose of consumption for most people is to soothe the pain of working.
Yes, for a lot of people it is like this.
When I was young, I couldn't understand why people went on 1-2 week short, extremely expensive vacations where they blow multiple months worth of their savings (ie. multiple months of their income after expensives) in what is extremely short amount of time. It seemed mind-bogglingly stupid.
Now I understand. Being part of the system and doing 9-to-5 wageslavery is inescapable fact of their life.
So when they get 2 weeks off - 2 weeks to actually go and live freely, they just go all out on having a good time. Because no matter what - they are going back to 9-to-5 system.
And however wastefully they "consume" whatever is left after basic expenses, doesn't really matter in grand scheme of things and won't free them from slavery.
It's a distraction. "Whatever hours of free time I get after work, I'm gonna indulge consoom however I want"
Now software engineers are a bit different, where it's possible to retire after 10 years of work if you plan and live frugally, this is simply not an option for vast majority of people.
Not only is it not impossible, it's precisely where it's heading.
I think even mass-market companies are going to thrive without customers. They don't need customers. The government will start handing out billion dollar contracts to these companies for doing almost nothing and they're going to focus on investing and the government money is just going to keep going round and round in circles between all the chosen companies.
And yes, you need to store and manage more data and your session store is an additional Single Point of Failure... With JWT the revocation list is an optional... Your system can keep running without it; it just won't be able to ban users. It's a cleaner separation of concerns without SPoF.
JWTs have so many benefits over session IDs, I could write a book about all the benefits. Sure, there are some tradeoffs but the negatives are typically pretty minor or hand-wavy.
reply