Please subscribe to our YouTube channel @ https://www.youtube.com/@DevoxxForever
Subscribe to LinkedIn @ https://www.linkedin.com/company/voxxed-days-amsterdam
Follow us on Twitter @ https://twitter.com/voxxedamsterdam

JWTs (JSON Web Tokens) are everywhere—frontends, backends, microservices—and for good reason: they're easy to pass around, self-contained, and standardized. But while JWTs can be a solid fit for authentication, using them for authorization is a decision that comes with serious pitfalls—especially in distributed systems.

In this lightning talk, we’ll explore the technical and security limitations of JWT-based authorization and explain why they're fundamentally incompatible with the needs of modern applications. From the infamous "New Enemy Problem" described in Google’s Zanzibar paper to the vague semantics of scope claims and the difficulty of revoking tokens in-flight, we’ll unpack the real-world consequences of treating JWTs as your AuthZ layer.

Devoxx

JWTs are widely misused for authorization, but they have fundamental flaws for this purpose. Being stateless and self-contained, they cannot be meaningfully revoked — a problem known as the 'confused deputy' or 'new enemy problem' described in Google's Zanzibar whitepaper. Scopes don't scale to fine-grained permissions, and tokens flowing through distributed/microservice architectures create unpredictable privilege escalation risks. OWASP consistently ranks broken access control as the top web app risk, with 100% of tested apps failing. Modern alternatives include Zanzibar-based relationship access control systems (SpiceDB, OpenFGA, Permify) and policy decision points/engines (OPA, Cedar). JWTs remain appropriate for one-time, short-lived, non-revocable grants like email verification links, but should not be used for long-lived sessions or fine-grained app authorization.

Stop Using JSON Web Tokens (JWTs) for Authorization! by Sohan Maheshwar