> Security should be binary. Either technology is secure or it’s not.
From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.
From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.
Just because there are attacks or ways around a particular defense doesn't mean it's worthless, that's why we have defense in depth.
I disagree with the main thesis for why JWT is a problem. JWT isn't necessarily encouraging you not to hit the DB for user lookup. This is the claim the article makes as a problem with revocation.
It reads like a really long thoughtful article based entirely on false assumptions for how to best use it.
It's ok to carry around some encrypted state in your tokens for some uses cases.
If you’re handling sensitive data, you have to understand the tools you’re using and what their relative weaknesses are. Best practices are nice. But it’s far too easy to make a mistake following them if you don’t understand the principles behind them.
“X is always secure” is a great way to ensure X is not implemented correctly.
For sure some aspects of security are binary. But even with JWT (I agree with the main points of the article), a token with an expiry of 5 minutes but no revocation capabilities is still objectively preferable to no expiry at all.
The binary aspect of security is primarily about whether you fall within your risk appetite or you don’t.
The problem then is that people - Us - all of us here on HN - frequently fail to understand their project requirements or at least fail to anticipate the future requirements of a project - and we’re arguing about what those requirements should be :)
And it’s not just people under-estimating things: it’s too easy to us ambitious-types to think “what if this simple PHP project goes viral and we need to scale to millions of users overnight?” (Answer for the curious: it won’t) - which in turn makes people think using stateless tokens is fine (well, it is fine, actually - provided you have a revocation system; TFA’s title is just clickbait, and the problems are hardly unique to JWT: almost every web platform’s built-in authX system will support stateless user-info and authorisation and use it by default… if not always and by-design (ASP.NET’s ClaimsPrincipal, Kerberos, etc). (Note I’m not referring to server-side session-state (like PHP’s $_SESSION) which is not intended for authX nor does it scale, for reasons mentioned in the article)
The article is a contrarian-sounding ad for Redis, written by a Redis employee, on Redis’ own website. Why are we treating it like news? And why am I even writing this retort? Argh! HN’s content team know how to drive my engagement! I’m doomed…