JSON Web Token (JWT)

JWTs are self-contained tokens that carry all necessary identity and authorization data within the token itself, eliminating the need for a centralized session store. This is critical for agentic systems where services must verify identity without querying a shared database on every request.

• Reduces latency in high-frequency agent-to-agent calls
• Enables horizontal scaling without session synchronization
• Eliminates single points of failure in authentication infrastructure
• Ideal for event-driven architectures where agents operate asynchronously

JWTs encode claims — assertions about a subject — as JSON key-value pairs. These claims can be registered (iss, sub, exp, aud), public (namespaced for interoperability), or private (custom to a specific agent domain).

• Registered claims: Standardized fields like exp (expiration) and iat (issued-at) enforce temporal validity
• Custom claims: Embed agent roles, tool permissions, or trust tiers directly in the token
• Claims are digitally signed, making them tamper-evident
• Enables attribute-based access control (ABAC) without additional lookups

Every JWT carries a digital signature computed over the header and payload using a secret key (HMAC) or a public/private key pair (RSA, ECDSA, EdDSA). This guarantees that the token has not been tampered with since issuance.

• HMAC (HS256): Shared secret suitable for monolithic or tightly coupled services
• RSA/ECDSA (RS256, ES256): Asymmetric signing where only the issuer holds the private key; any service can verify with the public key
• EdDSA (Ed25519): Modern elliptic curve algorithm offering high security with small signatures
• Prevents token forgery and unauthorized claim modification in transit

JWTs use Base64URL encoding to represent the header, payload, and signature as a three-part string separated by dots: header.payload.signature. This format is safe for transmission in HTTP headers, query parameters, and message queues.

• No characters requiring URL escaping (unlike standard Base64)
• Minimal overhead — typical tokens are under 1KB
• Easily passed in Authorization: Bearer headers
• Compatible with gRPC metadata, WebSocket handshakes, and message broker headers
• Enables embedding identity in event payloads without breaking serialization

JWTs include built-in temporal and scope constraints that are critical for agentic security. The exp (expiration) claim enforces short-lived tokens, while aud (audience) restricts which services may accept a given token.

• Short-lived tokens (e.g., 5-minute TTL) limit the blast radius of token theft
• nbf (not-before) prevents premature token usage
• aud claim prevents confused deputy attacks where a token valid for one agent is misused against another
• Enables token rotation and refresh token patterns for long-running agent workflows

The JWT header declares the signing algorithm via the alg parameter. However, this flexibility introduces algorithm confusion attacks if not properly constrained. Secure implementations must enforce an explicit allowlist of permitted algorithms.

• Reject none algorithm: Servers must never accept unsigned tokens
• Pin expected algorithms: Only accept RS256 or ES256 if using asymmetric keys
• Validate key type: Ensure the alg matches the key material (prevent HMAC-for-RSA substitution)
• Use JWKS (JSON Web Key Sets) for dynamic public key distribution
• Combine with DPoP (Demonstration of Proof-of-Possession) to bind tokens to a specific client key