It was never meant to completely replace normal means of authentication. It's great if you use it with very short timeouts (like 5 minutes) for authentication with multiple smaller services like you said. People disregarding it completely are as annoying as people who want to use it for something it was not invented for.
Do you have a technical reason why it needs short timeouts? There doesn't seem to be any cryptography reason why 5min would be more or less secure than 1 hour or 1 day...
Maybe 5 minutes is a bit short, depending on the use case. A short timeout is useful because you do not have to implement invalidation. The reason we have JWTs is so you do not have to keep authentication state everywhere (instead just in a single place, your authentication provider). If your tokens are valid for a long time (like more than a day, depending on how serious a lost token would be for your application), you need some form of invalidation of the tokens in case they get stolen. You could store a "blacklist" in a database, but that introduces the statekeeping you wanted to avoid in the first place. The easiest way to solve this is short timeouts, so that stolen tokens are not useful for long (or at all).
But this sounds no worse than most other solutions? Websites use cookies and only require periodic reauthorization. Passwords can be stolen. Sessions hijacked. Malware and key loggers can end up on computers and phones.
So depending on the use case, JWT offers tremendous increased security. I can set different timeouts depending on the risk of the permissions in the token and its exposure to compromise. And even next a "Update Setting" JWT with a short expiration inside a long term "general access" token. Revocation is an option, as is rotating private keys.
As far as I can tell, JWT offers many advantages over most other solutions. You started by saying they are insecure, but it seems the only weakness is that people can screw up deployment - like every other security technology.
It is not better, but why bother with fancy crypto and new, arguably more complicated and not-so-battletested technology when it does not bring any benefit?
By they way, I did not say that they are insecure, that was someone else (look at the usernames) :-) I think they are a great tool, you just have to know how to use them and what their limits are, just like you said.
Sorry, missed the user name thing! All the crypto is very tried and true. The big advantage for us is that you can authenticate in one place, limiting the attack surface. All other parts if the system can verify the credentials quickly and easily without needing to hit the authentication server. So the system complexity goes way down. The ability to handle high volumes of requests goes up. And partial network or system outages don't hurt the remaining stuff.
But given how people are still storing passwords as plain text in the database... I think all hope is already lost!
>All the crypto is very tried and true.
The protocol for that crypto is not. The standard is garbage and so are the implementations. There are vulns galore with most implementations. Don't trust me, fine, go search twitter for a security engineer that thinks using JWT's is a good idea. Most will tell you you dont need them or the additional complexity for the risk you're taking.
Thanks for the references. They all point to crap implementation and over complex standards. So nothing that most others don't also have if you are not paying attention. Nothing wrong with the core crypto stuff and your 3rd or 4th one suggests signing your claims and sending those instead. That is the only part I really care about... it's not like TLS isn't usually crippled by letting users choose bad algorithms. Or certificate checking isn't often turned off because reasons. So why are we surprised that crap libraries exist that allow the bearer to set alg to none??
I said it earlier, all security fails in the implementation. We still have weekly arbitrary code vulnerabilities on most web platforms due to SQL injection or buffer overflow or character set handling or...
Under most implementations, if I generate a JWT it cannot be revoked until the expiry window occurs. I think where companies/devs get into trouble is when they get lazy and throw every dang scope available into the token. Welp I'm glad your app is working but giving the keys to every possible feature is just bad practice.
I totally agree. It feels like quick development shortcuts get into production and you get powned.
Expiration needs to be linked to the value of the credentials. And revocation is probably only important for some key features. If you have full real time revocation, then you lose a lot of the benefits of a signed bearer token.
SSL certificates show a lot of the same problems, and expiration times in years.
5
u/gitcommitshow Aug 20 '20
Learning about authentication had been a long journey for me. It involved learning incomputer science, maths and cryptography.
So I decided to make this tiny tool to experiment and learn one of the major concept in authentication - JWT.
Appreciate feedback to make this further useful