OAuth building blocks for non-human identity

Why OAuth is the substrate

Every serious proposal for agent identity composes existing OAuth mechanisms rather than inventing new ones, for a straightforward economic reason: OAuth infrastructure is already deployed, already audited, and already understood by the teams who would have to operate the alternative. The draft-klrc-aiagent-auth authors, from Defakto, AWS, Zscaler, Ping Identity, OpenAI and Okta, state this as the document's thesis.

The practical value of knowing the pieces is evaluative. When a vendor says they support agent identity, the question is which of these mechanisms they implement and at what version. That is checkable; "supports agentic identity" is not.

Token exchange. RFC 8693

Ratified, January 2020. The delegation workhorse. A client presents one token and receives another, typically narrower in scope, for a different audience. It carries two distinct semantics worth keeping separate:

• Delegation: the resulting token represents the client acting on behalf of a subject, and both identities are preserved. This is what you want for agents.
• Impersonation: the resulting token represents the subject alone, and the acting party disappears. This destroys attribution and is the mechanism behind most accidental delegation-chain breaks.

The distinction is expressed through the actor claim. An implementation that supports token exchange but drops the actor claim gives you impersonation whatever it is called, so ask specifically. See delegation chains.

DPoP. RFC 9449

Ratified, 2023. Demonstrating Proof of Possession binds a token to a key the holder must prove control of, so a stolen bearer token is useless without the corresponding private key. The client signs a proof for each request, bound to the method and URI.

This is the most under-implemented mechanism relative to its value, and agent architectures raise that value sharply: tokens leak into prompt context, tool outputs, logs, memory stores and inter-agent messages. Every one of those becomes a non-event if the token cannot be replayed. If you adopt one thing from this page that you are not already doing, adopt this.

PKCE and OAuth 2.1

PKCE is ratified (RFC 7636) and mandatory for all clients in OAuth 2.1. It prevents authorization-code interception by binding the code exchange to a secret the client generated. OAuth 2.1 consolidates accumulated best practice: PKCE required, implicit grant removed, resource owner password credentials removed.

Its relevance here is direct: the MCP specification mandates OAuth 2.1 with PKCE for protected HTTP deployments. An MCP server using a static bearer token has departed from the specification, which is a more useful thing to say in a review than that it is insecure.

CIBA

OpenID Foundation specification. Client Initiated Backchannel Authentication decouples the approval channel from the client channel: a system triggers an out-of-band request and the user approves or denies on a separate device, without the requesting party ever handling their credentials.

For agents this is the clean mechanism for human-in-the-loop approval on consequential actions, and it has a security property that in-band approval lacks. It takes the decision off the channel an attacker may control, which matters where prompt injection is a concern.

Client credentials, and why it is not enough

Ratified, part of OAuth 2.0. The client authenticates as itself and receives a token. It is correct for a workload acting purely on its own behalf: a batch job, a service-to-service call with no user involved.

It becomes the dominant anti-pattern the moment a user is involved, because it carries no user authority and cannot express delegation. An agent using client credentials to act for a person produces logs showing only the client. That is the mechanical origin of most missing delegation chains, and it is usually chosen because it is the simplest flow rather than because anyone decided impersonation was acceptable.

Two further cautions: the client secret is itself a long-lived non-human credential and needs the same lifetime and rotation discipline as any other, and where the runtime supports attestation, workload identity is a better answer than a client secret at all.

Assembling them for an agent

1. The agent obtains an attested workload credential from its runtime rather than holding a client secret.
2. The user authenticates and consents via OAuth 2.1 with PKCE.
3. The agent performs a token exchange to obtain a downstream token carrying both its own identity and the user's, with narrowed scope and the actor claim preserved.
4. All tokens are DPoP-bound so theft does not yield replay.
5. Consequential actions trigger CIBA approval out of band.
6. Revocation is pushed via CAEP rather than waiting for expiry. See kill paths.

Every step is a ratified standard or a published specification. Nothing in that sequence requires waiting for the agent-specific drafts to ratify, which is the point.

Frequently asked questions

Do AI agents need new authentication protocols?

The consensus position among the people doing the standards work is no. The IETF individual draft on AI agent authentication, authored across Defakto, AWS, Zscaler, Ping Identity, OpenAI and Okta, argues explicitly that agents need correct application of WIMSE and the OAuth 2.0 family rather than new protocols. The economic reason is that OAuth infrastructure is already deployed, audited and understood.

What is the difference between delegation and impersonation in OAuth token exchange?

In delegation the resulting token represents the client acting on behalf of a subject and both identities are preserved, expressed through the actor claim. In impersonation the token represents the subject alone and the acting party disappears. Impersonation destroys attribution and is the mechanical origin of most broken delegation chains, so when evaluating an implementation ask specifically whether the actor claim is preserved.

What is DPoP and why does it matter for agents?

DPoP, specified in RFC 9449, binds a token to a key the holder must prove control of, so a stolen bearer token cannot be replayed without the private key. It matters disproportionately for agents because agent architectures multiply the places a token can leak: prompt context, tool outputs, logs, memory stores and inter-agent messages. It is the most under-implemented OAuth mechanism relative to its value.

Why is the client credentials grant an anti-pattern for agents?

Because it carries no user authority and cannot express delegation. An agent using client credentials to act for a person produces logs showing only the client, so the delegating human is unrecoverable. It is correct for a workload acting purely on its own behalf, such as a batch job, but the moment a user is involved it silently converts delegation into impersonation. It is usually chosen for simplicity rather than as a decision.

Which agent authentication standards can I cite to an auditor?

The ratified ones: OAuth 2.0 Token Exchange (RFC 8693), DPoP (RFC 9449), and PKCE (RFC 7636), which is mandatory in OAuth 2.1. CIBA is a published OpenID Foundation specification. Nothing agent-specific is ratified: the IETF AI agent authentication document is an individual draft with no formal standing, and the WIMSE documents are working-group drafts. See our standards tracker for the current status of each.

What is CIBA used for in agent deployments?

Out-of-band human approval. Client Initiated Backchannel Authentication lets a system trigger an approval request that the user answers on a separate device, without the requesting party handling their credentials. For agents it provides human-in-the-loop approval on consequential actions with a security property in-band approval lacks: the decision is made off the channel an attacker may have manipulated.