OAuth 2.1 for AI agents.
OAuth 2.1 for AI agents applies the OAuth authorization framework to non-human, autonomous identities: an agent obtains a scoped, short-lived access token — via the client-credentials flow for its own identity, or token exchange / on-behalf-of when acting for a user (with PKCE in any user-facing leg) — and presents it to call tools and APIs. It is the right foundation for agent authentication and delegation, but OAuth issues tokens; it does not make per-action decisions. It must be paired with fine-grained authorization enforced at the tool-call layer.
Key takeaways
- Use OAuth 2.1 (scoped, short-lived tokens) for agents — never long-lived API keys.
- Client credentials when the agent acts as itself; token exchange / on-behalf-of when it acts for a user.
- PKCE is mandatory for any human-authorization leg; bind tokens to an API with resource indicators.
- OAuth issues tokens; it does not decide individual actions — pair it with tool-call authorization.
Why agents need OAuth, not API keys
The reflex is to hand an agent a long-lived API key. That gives it standing, unscoped, unrotatable access — the worst credential shape for an identity that runs unattended and decides its own actions. OAuth 2.1 replaces that with short-lived, audience-bound, scoped tokens that can be revoked and rotated, and that carry the context needed to attribute actions back to a human and a purpose.
The flows that fit agents
Match the flow to who the agent is acting as:
- Client credentials — the agent acts as itself (a machine identity) with its own scoped token.
- Token exchange (RFC 8693) / on-behalf-of — the agent acts for a user; the user’s token is exchanged for a downscoped one carrying the user’s context.
- Authorization code + PKCE — any leg where a human authorizes the agent; PKCE is mandatory in OAuth 2.1.
- Resource indicators (RFC 8707) — bind the token to a specific API so it cannot be replayed elsewhere.
Where OAuth stops and authorization begins
OAuth answers "who is this agent and what broad scopes did it get?" It does not answer "may this agent make this specific tool call, on this resource, right now?" That per-action decision is authorization — RBAC/ReBAC/ABAC evaluated at the tool-call layer, ideally with zero standing privileges so even a valid token only unlocks what the current task needs. This is the core of MCP security: OAuth for identity, a policy layer for every action.
Common questions.
Does OAuth authenticate or authorize an AI agent?+
OAuth establishes the agent’s identity and issues a scoped access token — closer to authentication-plus-coarse-authorization. It does not make per-action decisions. Fine-grained authorization (may this agent do THIS, now?) is a separate policy layer enforced when the agent calls a tool.
What OAuth flow should an AI agent use?+
Client credentials when the agent acts as itself; token exchange / on-behalf-of when it acts for a user (so the token is downscoped to that user’s context); authorization code with PKCE for any human-authorization step. Avoid long-lived API keys entirely.
Is OAuth enough to secure an AI agent or MCP server?+
No. OAuth 2.1 is the right authentication and delegation foundation, but securing an agent also requires per-tool-call authorization, zero standing privileges, and audit logging. See MCP security for the full picture.
The whole picture, in one place.
This explainer is part of our complete guide to IAM — authentication, authorization, governance, privileged access, the standards, and how to run a program.