OAuth 2.0

OAuth 2.0 enables a resource owner (e.g., a user) to grant a client (e.g., an autonomous agent) limited access to protected resources hosted by a resource server without sharing credentials. This is achieved through the introduction of an authorization server that issues access tokens. The client never sees the user's password, only a time-limited, scoped token. This is critical for agentic systems where an agent acts on behalf of a user across multiple services.

The core mechanism is the access token, a string representing a granted authorization. Tokens are opaque to the client but understood by the resource server. Scopes define the specific permissions bundled into a token, enabling the principle of least privilege:

• read:profile - Access basic identity information
• write:documents - Permission to create or modify files
• agent:execute - A custom scope allowing an autonomous agent to trigger a specific workflow Tokens have a limited lifetime and must be refreshed, reducing the blast radius of a compromise.

OAuth 2.0 defines several flows, or grant types, for different client profiles. The Authorization Code Grant with PKCE is the only recommended flow for most applications, as it prevents authorization code interception. Other flows include:

• Client Credentials Grant: For server-to-server communication where the client is the resource owner, commonly used for agent-to-agent authentication.
• Device Authorization Grant: For input-constrained devices or agents running on headless systems.
• JWT Bearer Token Grant: Allows a client to exchange a pre-existing, signed JWT for an access token, useful in Zero Trust Architectures.

A resource server validates an access token by calling the authorization server's introspection endpoint. This returns metadata about the token, including its active status, associated scopes, and expiration time. This allows for real-time validation without the resource server needing to parse the token itself. The revocation endpoint allows a client to signal that a previously obtained token is no longer needed, enabling proactive session termination—a key component of an Agentic Kill Switch Design.

Standard Bearer tokens are vulnerable to replay if intercepted; any party in possession of the token can use it. Sender-constrained tokens, such as those bound by Demonstration of Proof-of-Possession (DPoP) or Mutual TLS (mTLS), cryptographically bind the token to a specific client's private key. This is essential for securing Secure Inter-Agent Communication, as it prevents an impersonator from reusing a stolen token from a different host.

In highly dynamic agentic systems, pre-registering every client statically is infeasible. Dynamic Client Registration (DCR) allows clients to register themselves with the authorization server at runtime, obtaining a unique client_id and, optionally, a client_secret. This is often combined with a Software Statement—a signed JWT from a trusted authority that attests to the client's identity and properties, enabling automated, secure onboarding of ephemeral agent instances.

A mutual authentication protocol where both the client and server present X.509 certificates during the TLS handshake. Unlike standard TLS where only the server is verified, mTLS establishes bidirectional trust.

• Zero-trust agent networks: Every agent must prove its identity cryptographically
• Certificate-bound access tokens: OAuth 2.0 tokens can be bound to the client's certificate via cnf confirmation claims
• Prevents token replay: Stolen bearer tokens cannot be reused from a different client

mTLS is the foundational transport security layer for secure inter-agent communication in production deployments.

A compact, URL-safe token format defined in RFC 7519 that encodes claims as a JSON object. JWTs are the primary token format used in OAuth 2.0 and OIDC flows.

• Structure: header.payload.signature — three Base64URL-encoded segments separated by dots
• Common claims: iss (issuer), sub (subject), exp (expiration), iat (issued at), aud (audience)
• Signing algorithms: RS256, ES256, EdDSA — never accept alg: none

Agent systems must rigorously validate JWT signatures, expiration, and audience claims to prevent JWT confusion attacks and token substitution.

A security model that eliminates implicit trust. Every access request — whether from an agent, service, or user — must be continuously verified based on identity, context, and policy.

• Never trust, always verify: No distinction between internal and external networks
• Micro-segmentation: Agents are isolated and can only communicate with explicitly authorized peers
• Policy engine: Real-time authorization decisions based on multiple signals

ZTA is the architectural foundation for securing multi-agent systems where traditional perimeter defenses are meaningless.