| While this article raises some pain points, it is really bad advice and while it does seem to come up every now and then, the initial flaw with the argument, which typically leads to it confusing newbies while making more experianced users ignore the valid points is the conflation of Auth with Authz. Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to. Note the opening claim: > JWT promises stateless authentication and delivers neither JWT claims typically are used to pass identity of authenticated users, not to authenticate users, that is important, and I cannot validate a opaque bearer token at all, while we do need something better, opaque bearer tokens are not an improvement for authorization. > You can't. That's the answer. The token is valid until it expires, full stop. The only way to invalidate it is to store the jti server-side in a revocation list and check that list on every single request. Which is a database lookup. Which is the thing JWT was supposed to let you skip. Congratulations, you've reinvented sessions, badly. Bloom filters, which are constant factor time add/remove, constant-space set data structure are trivial to implement, if you have something like the expiry time of a jwt to restrict their growth. Even if you had a scalable bloom filter for a narrow temporal high volume need, the sizes are tiny and the performance avoids needing to pound your redis revocation list. While JWT doesn't have the information hiding capabilities of opaque tokens that must be validated through introspection, with every request needing a call to the authorization server or local cache, Nothing with JWT stops you from doing exactly the same, either in the positive case with a SPoF authorization call, or in the negative case with a bloom-filter in front of a revocation list on redis. Basically all the options have limits, costs and tradeoffs. Choosing between JWTs and opaque bearer tokens is a least worst option choice, About which one fits your application’s architecture, security model, and operational needs. If you need information hiding JWT isn't probably the best choice, if you want flexibility, observability, and performance opaque bearer tokens are probably not the best choice. Remember there is that nuance and temper your expectations from the clickbait, they don't know your system, your needs, or your risk tolerance. This is a shift in complexity, not a change in complexity. |