| The main claim of the article is: > jwt as authentication tokens are constructed for Google/Facebook scale environments, and absolutely no one who is not Google/Facebook needs to put up with the ensuing tradeoffs. The first sentence is factually incorrect. Google doesn't use JWT for most of its own authentication. Try analyzing their traffic - web and mobile apps - and you'll find that none of their 1st party applications / web use JWT. They do use JWT for OIDC, for third parties, which makes sense since with OIDC/JWT, third party sites can verify the token without talking to Google using a standard. This is largely similar for Facebook. JWT RFC starts with: > JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. Notice "between two parties". Of course, nothing stops from a single party to use JWT, but claiming JWT was invented for "Google/Facebook scale environments" implying they are using it for their 1st party authentication is just factually wrong. JWT was always meant to be an information transport between two separate parties, like OIDC. "Ensuing tradeoffs" here is essentially about stateless authentication vs stateful authentication, and even there, this "absolutely no one" is simply incorrect. There are many scenarios where stateless authentication is sufficient, even for the authentication for a single party (let alone between two separate parties). Not all applications and use cases require the security properties of stateful authentication - a sufficiently short expiration would provide sufficient security in many cases, making the loss of any security worth it for the added benefit of simplicity and reliability with the stateless authentication. Now with more nitpick: The article claims, since "denylist" would require a database read, it's equivalent to stateful authentication. Theoretically that's true. In practice, denylist has some nice properties, that makes it worthwhile if server-side logout is the only missing feature you need from JWT. Denylist is often very small - if most users of your application or service do not explicitly log out, the number of denylist will remain very small. With the expiration, the size can not grow indefinitely either. Thus, the denylist you maintain can be much smaller than the record of all stateful authentication - which makes it cheaper/easier to replicate / cache across your systems than the full authentication records. So "denylist" is definitely a legitimate design option, with slightly different trade-offs than a full stateful authentication. --- If I re-interpret the main claim of the article in the way I think would make sense, it would be: services should prefer stateful authentication, and the cost of stateful authentication is lower than people imagine it to be. That I can be behind 100%. As written, the article is at best some big exaggeration with incorrect details and hidden assumptions. |