141–150 of 304 posts
OT but I need a wake-up call here. Upon login I'm sending back a generated UUID tied to the account and saves it as a cookie in the client. What's wrong with this approach?
Given that tokens are signed and you can't really unwrap them on the client side without having "more information", I'd say this article is long on scare-tactics and short on real-life usage scenarios.
JWT is to HTTP Basic what OAuth2 is to logging in. Auth doesn't have to be complicated to be effective. Developers know/care very little about information security and a lot about following "standards" and "best practices." Google and Facebook have learned over the years to take advantage of this.
In what way?
Earlier quoted context omitted.
> So overall while I don't know how right he is, I feel like maybe he has a point. Why not just use cookies? Because in a highly distributed system hitting a database to validate authorization is expensive and causes bottlenecks. A cookie that requires you to hit the database does not solve that issue. Although if the cookie was signed some way that can be cryptographically verified then great. But then you are essen…
> Because in a highly distributed system hitting a database to validate authorization is expensive and causes bottlenecks. Don't you have to do something similar to invalidate tokens anyway?
Then, having the 'just-the-right-amount-of-short-expiration-time' for access token helps... maybe? :)
JWT is to HTTP Basic what OAuth2 is to logging in. Auth doesn't have to be complicated to be effective. Developers know/care very little about information security and a lot about following "standards" and "best practices." Google and Facebook have learned over the years to take advantage of this.
> Google and Facebook have learned over the years to take advantage of this. In what way?
There's also generally a lot of FUD around authentication because most web developers don't understand information security well enough to weigh the pros and cons, so technical discussions usually devolve into, "Google uses it, so it must be solid."
The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…
I don't hate secure cookies or anything, but some people act like plain-old regular cookies haven't been thoroughly solved by this point.
Related: Something people get wrong a lot with secure cookies is worrying about obscuring the cookie more than securing it. Encryption does not give you authentication; you need MAC for that. An encrypted message can still be blindly modified. Imagine being able to change a UID stored in a "secure" cookie even if you couldn't 100% control which. Eventually, if you try enough permutations, you're going to escalate your privileges!
Earlier quoted context omitted.
Sure, revocation lists are relatively small. But they need to be available to every server (replication), be proof against server/service restarts (durable), and checked with every request (highly performant). So, a good revocation list effectively requires a database. Not a trivial thing to implement yourself, and a weighty requirement for an otherwise stateless service.
Could you just have per-server tokens? Wouldn't a single client tend to hit just one server anyway?
The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…
I don't care if you want to use stateless client tokens. They're fine. You should understand the operational limitations (they may keep you up late on a Friday scrambling to deploy a token blacklist), but, we're all adults here, and you can make your own decisions about that. The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, yo…
Because every token has an iat datetime, you don't need a token blacklist to invalidate tokens. You just need some sort of tokens_invalid_if_issued_before_datetime setting that gets checked whenever you validate the signature of a token.
The alternative is to store a UUID for each user, and just rotate those whenever they log out, change or reset their password, or there is some sort of security event. These are then stored in the payload and used as a secret. The one advantage over just using dates is that with the former, there can be weird bugs if you have multiple servers with clocks that are out of sync.
But you shouldn't ever need to blacklist specific tokens, at least not unless you have some highly specialized use case.
Earlier quoted context omitted.
Sure, revocation lists are relatively small. But they need to be available to every server (replication), be proof against server/service restarts (durable), and checked with every request (highly performant). So, a good revocation list effectively requires a database. Not a trivial thing to implement yourself, and a weighty requirement for an otherwise stateless service.
Hmmm, using a database (eg PG) for the authoritative information, with memcached in front sounds like it would be practical for most uses.