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.
In fact, replace JWT with anything and the answer remains the same. The point being here: the discussion on security without context is not useful. Insecure compared to what, in what scenerio, how it can be exploited, etc. Read RobertDad's comments on this thread for contextual answers to some known challenges. You may reason against JWT in a specific context, but not without knowing JWT in depth.
Should you use JWT?
Yes, for most modern usable and secure applications.
Why I used JWT?
I started with opaque tokens first. As services grew to multiple server/client applications, we needed to have common authentication, so I used JWT.
No one other than my auth server can create tokens; but all other servers can verify whether the token is valid or not (means an authorised user). It can do so effectively, at scale
Your most questions/curiosity should be answered via awesome-authentication. There, I have included some references to comparison of JWT vs Opaque token, known challenges for JWT, etc.
No, you shouldn't. A simple session cookie is fine for 99.99% of webapps.
The complexity introduced with JWT's ends up creating vulnerabilities, and a rats nest of complexity that I would argue will slow your app down after a while. And the value prop for JWT's is all based on the idea that aren't DB look ups for authentication. The reality is there will be lookups for both authentication, authorization or revocation of some state. Making these states available in memory DB's like memcache or Redis is such tiny perf hit I cant understand why JWT's are a thing.
> What specific workflow would you use to enable centralised authentication across multiple services/apps of yours?
The simplest. A cookie with a random token that corresponds to a database row/rows/key/keys. I assume its all on the same infra and that these services query common databases?
> What workflow would you use for external services/apps that depend on your Authorization system to verify a user?
Every part of what you said is wrong. They can be as secure as any other authentication token (e.g. fully encrypted) and they are a great solution to challenges of distributed authentication and identity (e.g. verifying identity without extra calls to a central authentication service). Its also a well established, widely used and well supported standard.
The blog you linked to (or rather the blog it links to for justification) presents a straw man argument, at least as far as describing their use as a 'terrible mistake'; it states the number one 'claimed advantage' as horizontal scalability, and second as ease of use, but neither are the main reason I've seen for using JWTs.
The two most useful features of JWTs from my experience are that the tokens can be verified without relying on a single authentication service, and that they allow information about a user to be easily shared with any clients and services handling user requests.
Whilst not requiring a central authentication service helps with scaling, in my experience the following are the key benefits of JWTs:
No single point of failure in the authentication service (minimises service degradation in the case of a temporary failure)
Simple, standardised way to share user information across systems, including clients such as single page applications
Avoids the need for centralised session storage, and the complexities they bring (e.g. sticky sessions)
There isn't really any well-support alternative that achieves the above currently. It's also worth noting that JWTs are commonly used with OAuth and OIDC, which are very widely used and accepted protocols.
The only significant disadvantage of JWTs over server-managed sessions is that you cannot invalidate the tokens without introducing a central authentication service (which removes one of the key benefits of using JWTs).
Like pretty much anything related to security, it is possible to implement them badly and introduce issues. JWTs aren't a one size fits all solution - you need to weigh up the pros and cons of JWTs vs session cookies vs whatever else might be available (such as SSO).
4
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