Delegation vs OAuth

OAuth 2.1 and cryptographic delegation solve different problems. In multi-agent systems, you need both. This page explains the distinction, when each applies, and how they work together.

The Core Difference

OAuth answers: "Which human authorized this client application to act on their behalf?"

Delegation answers: "Which agent has authority to perform this action, and who granted that authority?"

OAuth is a consent protocol between humans and applications. Delegation is an authority protocol between agents and other agents.

Comparison Table

Dimension	OAuth 2.1	Cryptographic Delegation
Primary question	"Did the user authorize this client?"	"Does this agent have authority from the root?"
Participants	Human + client app + authorization server	Agent + agent + root authority
Token format	Opaque or JWT (server-issued)	Signed delegation chain (self-issued)
Verification	Token introspection or JWT validation against issuer JWKS	Ed25519 signature chain walk (no server call)
Attenuation	Scopes are static at issuance; cannot narrow downstream	Caveats accumulate at each delegation; can only narrow
Chaining	No native chaining; on-behalf-of (RFC 8693) is server-mediated	Native chaining: A -> B -> C -> D, each adding restrictions
Offline verification	JWT can be verified offline against cached JWKS	Always offline - everything is in the proof
Revocation	Token revocation endpoint (server call)	Revocation callback (application-defined)
Transport	HTTP (Authorization header)	Any transport - HTTP, stdio, WebSocket, file
Identity model	Client ID + user sub (server-assigned)	DID (self-sovereign, derived from keypair)
Key management	Client secrets / PKCE / mTLS	Ed25519 keypairs (agent-managed)

The MCP Auth Gap

The MCP specification defines an authorization framework based on OAuth 2.1 for HTTP transports. This works well for the pattern where a human user authorizes an MCP client to access an MCP server on their behalf.

However, MCP also supports stdio transport - where a host process spawns the MCP server as a child process and communicates over stdin/stdout. The OAuth 2.1 flow has no analog here:

• There is no HTTP redirect for user consent
• There is no authorization server to issue tokens
• There is no token endpoint to call

Stdio is the primary transport for local MCP servers (e.g., npx @kanoniv/mcp). In this mode, the MCP server has no way to know which agent is calling it or what authority that agent has. Every tool call is implicitly trusted.

Cryptographic delegation fills this gap. The agent attaches a _proof field to tool arguments containing a self-contained invocation proof. The MCP server extracts and verifies the proof - no HTTP, no authorization server, no redirect flow.

When to Use Which

Use OAuth 2.1 when:

• A human needs to authorize an application to access their data
• The MCP server is accessed over HTTP and needs to identify the user
• You need to integrate with existing identity providers (Okta, Auth0, Azure AD)
• The authorization server is a central, trusted component in your architecture

Use cryptographic delegation when:

• An agent needs to prove its authority to another agent or server
• Communication happens over stdio, WebSocket, or any non-HTTP transport
• Agents need to sub-delegate authority to other agents with restrictions
• Verification must work offline without calling an authorization server
• You need a tamper-proof audit trail of who authorized what

Use both when:

• A human authorizes an agent via OAuth, and that agent delegates to sub-agents via cryptographic delegation
• An MCP server accepts both HTTP (OAuth) and stdio (delegation) connections
• You need to answer both "which human approved this?" and "which agent chain executed this?"

Composition Pattern

In a typical multi-agent system, OAuth and delegation compose as follows:

Human (OAuth consent)
  |
  v
Agent A (OAuth access token + Ed25519 keypair)
  |
  | Delegation: [resolve, search], expires 1h
  v
Agent B (Ed25519 keypair)
  |
  | Delegation: [resolve], max_cost $5
  v
Agent C (Ed25519 keypair) --> MCP Server

1. The human authorizes Agent A via OAuth 2.1. Agent A receives an access token.
2. Agent A uses the OAuth token for HTTP API calls (e.g., Kanoniv Cloud API).
3. Agent A creates a signed delegation granting Agent B [resolve, search] authority.
4. Agent B narrows the delegation and passes it to Agent C with [resolve] only.
5. Agent C calls an MCP server over stdio, attaching the delegation chain as a _proof.
6. The MCP server verifies the chain: C was authorized by B, who was authorized by A, who is the root.

The OAuth token proves "a human approved this." The delegation chain proves "Agent A granted this specific authority to Agent C through Agent B, with these exact restrictions."

What OAuth Cannot Do

OAuth 2.1 was not designed for agent-to-agent authority transfer. Several properties of cryptographic delegation have no OAuth equivalent:

Caveat accumulation. Each delegation can only narrow authority. In OAuth, if Client A obtains a token with scope read write, there is no standard mechanism for Client A to issue a derived token to Client B with scope read only. Token exchange (RFC 8693) exists but requires a server roundtrip and does not support arbitrary constraint types.

Self-contained verification. An OAuth JWT requires the verifier to know the issuer's JWKS endpoint or have cached the signing keys. A delegation chain is fully self-contained - the issuer's public key is embedded in each delegation. No network call is needed.

Arbitrary depth. OAuth supports one level of delegation (user -> client). Token exchange can add a second level (user -> client A -> client B), but each level requires a server call. Delegation chains support up to 32 levels with no server interaction.

Transport independence. OAuth requires HTTP for the authorization flow and token endpoint. Delegation works over any transport that can carry JSON - stdio, WebSocket, message queues, files on disk.

What Delegation Cannot Do

Delegation is not a replacement for OAuth. It does not provide:

User consent flows. There is no equivalent of the OAuth authorization screen where a human reviews and approves permissions. Delegation assumes the root authority (which may be human-controlled) has already decided to grant authority.

Identity provider federation. OAuth integrates with enterprise SSO (SAML, OIDC) through identity providers. Delegation uses self-sovereign DIDs with no federation protocol.

Token refresh. OAuth access tokens expire and can be refreshed via refresh tokens. Delegations use expires_at caveats but there is no refresh mechanism - a new delegation must be issued.

Standardized discovery. OAuth has .well-known/openid-configuration for server discovery. Delegation has no discovery protocol - the root authority's public key must be configured out of band.