Major companies like Google do all sorts of dumb things, and, equally importantly, have gigantic well-funded security teams triple-checking what they do, so that the pitfalls in these standards are mostly an externality to them.
(The actual answer is: I have no idea what Google does with JWTs.)
> have gigantic well-funded security teams triple-checking what they do
Yes! This is the answer to almost every "Well, it works for Google..." that comes up.
Alice: "It works for Google!"
Bob: "Sure, but how many PhDs does Google have on payroll managing it?"
Google has the resources, meaning dollars and reputation, that if they want to do something, they can hire anyone they want to make it possible. They frequently hire the authors of the programming languages and environments they use (that weren't already invented in-house), who can then customize everything to fit Google's needs just so.
Assuming you're a normal mortal corporation, getting the inventors of your platforms on board and committed to your problems specifically is no trivial matter, and you don't have an army of bona fide, credentialed computer scientists on payroll to patch any intervening rough spots, so "Google does it" is not really applicable.
With the right choice of algorithm, and if you control the code which interprets that JWT (whitelisting the alg and choosing the right library), I don't see a reason why JWT would be insecure.
It's absolutely true that if you do everything correctly, a JWT implementation can be secure. Generally, in crypto engineering, we're looking for constructions that minimize the number of things you need to get right.
Yeah this is the problem with crypto security people they are one dimensional. JWT has the benefit of allowing disconnected services to send each other information through the front end.
Which minimizess the number of things you need to get right or in your words equals more secure.
Designing a token that can be validated instead of looked up. (Design/Implement once)
Or
maintaining, updating and monitoring a set of firewall rules so that app-servers in network zone x and y can make call backs to a database in network zone z.(design many implement many)
There are a ton of great reasons to use JWT at scale. As with anything use case is important.
I disagree almost absolutely with all of this but am comfortable with how persuasive our respective comments on this thread are or aren't to the rest of HN. I'd rather not re-make points I've already made.
That's also an argument for just using Kerberos over the Internet. And I'm not sure that's a good idea.
I'm almost certain it's a bad idea if that means rolling your own Kerberos implementations in php, javascript and golang in order for your various back-end to speak to your various front-ends.
But sure, leverage secret-key crypto and tickets in your own implementation in a way that's more secure than Kerberos.
Or, use a solution that's simple enough any weakness is fairly obvious.
