JWT (JSON Web Token) is a compact, self-contained, and secure method for transmitting information between parties as a JSON object. JWT has become essential for addressing the following needs at scale across enterprise organizations. * **API Authentication** - After a user logs in, the server generates a JWT and sends it to the client, which stores it (e.g., in local storage or cookies). The client includes this token in the Authorization header for subsequent requests. * **API Authorization** - Servers decode the JWT to verify the user's identity and permissions before granting access to protected resources. Enterprise are choosing JWT primairly for internal APIs and microservices, but are also application outside the enterprise for the following reasons. * **Stateless** - JWTs are stateless and sessionless, meaning no server-side storage is required. All required user data is embedded in the token itself. * **Portable** - JWTs are URL-safe and small in size, making them easy to pass through URLs, HTTP headers, and query strings. * **Scalable** - Since JWTs do not require session storage, they are highly scalable for distributed systems and microservices. * **Flexible** - JWTs allow you to include custom claims, such as user roles and permissions, enabling fine-grained access control. * **Cross-Domain Authentication** - JWTs work well in Single Sign-On (SSO) scenarios, enabling seamless authentication across different domains and services. JWT is a secure, scalable, and stateless way to handle authentication, authorization, and secure data transmission. It is widely used in HTTP APIs, microservices, as well as Single Sign-On (SSO) systems, providing flexibility and security for modern applications and integrations.
JSON Web Token
JSON Web Token (JWT), standardized as RFC 7519, is a compact, URL-safe way to represent claims as a signed — and optionally encrypted — JSON object passed between two parties. A JWT packs a header, a payload of claims, and a signature into a single dot-delimited string that any party holding the key can verify without a database lookup. It has become the default bearer credential for HTTP APIs, microservices, and single sign-on.
- Three-part structure - A base64url-encoded header, a claims payload, and a signature, joined by dots into one portable string.
- Stateless verification - The signature lets a server trust a token’s claims without server-side session storage.
- Standard and custom claims - Registered claims like
iss,sub,exp, andaudsit alongside your own roles and scopes. - Signed or encrypted - Signed as a JWS by default, or wrapped as a JWE when the payload itself must stay confidential.
In real API operations a JWT shows up as the bearer token in the Authorization header, minted by an OAuth or OpenID Connect flow and validated on every request. Its statelessness is what makes it scale across microservices, but the same self-contained design is why expiration, key rotation, and signature verification have to be governed carefully — a forgotten exp or an accepted alg: none is a real breach. As agents begin calling APIs on a user’s behalf, the JWT is increasingly the thing carrying the delegated identity and scopes an agent is allowed to act within.
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.
