Who’s on FirstChoose a flow

Flows

Every way an agent gets access

19 flows, each as a sequence diagram you can step through. They are grouped by the question that matters most when choosing between them: is there a person involved, and when?

Human present

Someone is at the keyboard and can sign in and consent right now.

Authorization code + PKCE

The baseline. A person signs in, approves specific scopes, and the agent receives a token that says so.

Human presentStable standards

Device authorization

For agents with no browser of their own: show a code, let the person approve on another device, and poll.

Human presentStable standards

MCP authorization

How an MCP client that has never seen a server before discovers where to sign in, identifies itself, and gets a token good for that server alone.

Human presentEmerging

Human in the loop

The agent works on its own, but pauses for a person to approve specific actions.

Step-up authorization

Start with a weak token. When the agent reaches something sensitive, the API says so and the user is asked for exactly that.

Human presentStable standards

Backchannel approval (CIBA)

The agent asks the authorization server to go and find the user. Approval arrives as a push notification, not a redirect.

Human reachableStable standards

URL elicitation

A tool needs the user to sign in somewhere else. It hands back a link, the user completes the flow in a browser, and the secret never touches the agent.

Human presentEmerging

Delegation chains

Carrying “who asked for this” across agents, tools and trust domains.

Token exchange

Trade the token you were given for a new one that names both the user and the service now acting for them.

With or without a humanStable standards

Enterprise-managed (ID-JAG)

The company identity provider decides which agents may reach which apps for which employees. No per-app consent screens.

Human presentEmerging

Identity chaining

Carry who-is-this-for across an organizational boundary, with each side keeping control of its own tokens.

With or without a humanEmerging

Transaction tokens

Inside your own infrastructure, replace the access token with a short-lived token that pins down one transaction and travels the whole call chain.

With or without a humanEmerging

No human

The agent acts as itself: workload identity, not user identity.

Client credentials

The agent authenticates as itself. No user, no consent screen, no one to ask.

No humanStable standards

Workload identity federation

Your agent uses an identity established by its runtime to obtain short-lived access from a system that trusts that identity.

No humanStable standards

SPIFFE + mTLS

Every agent process gets a cryptographic identity from the infrastructure it runs on, and uses it to authenticate both ends of every connection.

No humanStable standards

Workload tokens (WIMSE)

A workload identity that is bound to a key and proven on every request, so it survives the gateways and proxies that agent traffic passes through.

No humanEmerging

Agent to agent, agent to web

Agents authenticating to each other, to websites and to merchants.

Agent to agent (A2A)

One agent discovers another, reads what credentials it wants, and presents them. When the remote agent needs more, it says so mid-task.

With or without a humanEmerging

Web Bot Auth

An agent that browses the open web signs its requests, so a site can tell which operator it belongs to without trusting a user-agent string.

With or without a humanEmerging

Agent payments (AP2)

The user signs what the agent may buy. The agent proves, to the merchant and to the payment network, that a purchase falls inside it.

Human reachableExperimental

Cross-cutting

Techniques that harden any of the above.

DPoP

Bind a token to a key so that stealing the token is not enough to use it.

With or without a humanStable standards

Credential broker

The agent never holds the secret. A proxy outside the sandbox adds it to outgoing requests, and only for the hosts it was meant for.

With or without a humanEmerging

Side by side

Who the token is about, and what proves it.

FlowHumanToken subjectAgent proves itself withMaturity
Authorization code + PKCEpresentUserPKCE, plus client authentication if confidentialStable standards
Device authorizationpresentUserDevice codeStable standards
MCP authorizationpresentUserClient ID metadata URL and PKCEEmerging
Step-up authorizationpresentUser, for one actionSame as the underlying flowStable standards
Backchannel approval (CIBA)reachableUser, for one actionSigned client assertionStable standards
URL elicitationpresentUser, at the third partyNothing: the server holds the grantEmerging
Token exchangeEitherUser, with the actor namedClient authentication and the token it receivedStable standards
Enterprise-managed (ID-JAG)presentUserA grant issued by the identity providerEmerging
Identity chainingEitherUser or agent, mapped per domainA signed grant from the home domainEmerging
Transaction tokensEitherUser and transactionWorkload identityEmerging
Client credentialsNo humanAgentSigned assertion or client secretStable standards
Workload identity federationNo humanAgent, as a workloadA token issued by the platformStable standards
SPIFFE + mTLSNo humanAgent, as a workloadCertificate obtained by attestationStable standards
Workload tokens (WIMSE)No humanAgent, as a workloadKey-bound token and per-request proofEmerging
Agent to agent (A2A)EitherWhatever the token saysA scheme declared in the Agent CardEmerging
Web Bot AuthEitherAgent operatorHTTP message signatureEmerging
Agent payments (AP2)reachableUser’s signed intentA key named in the mandateExperimental
DPoPEitherUnchangedA signed proof on every requestStable standards
Credential brokerEitherUnchangedNothing: the proxy holds the secretEmerging