OAuth for AI agents: secure, delegated tool access

Overview

OAuth for tool access means using the OAuth authorisation framework to let an AI agent use tools and data on a person's behalf without ever holding that person's password. The person signs in to the service that owns the data, sees what the agent is asking for, and approves it. The service then gives the agent a token: a short-lived credential that only works for the approved actions, only at that service, and that can be revoked at any time.

Agents make this more important than it was for ordinary apps. An agent may connect to email, calendars, file stores, code repositories and business systems, and it decides at run time which tools to call. If every connection used a shared API key with full rights, one leaked key or one manipulated agent could do great damage. OAuth gives each connection its own limited, auditable permission.

An everyday comparison is a hotel key card. You do not give the cleaner your house keys. Reception issues a card that opens only your room, only during your stay, and can be cancelled from the desk at any moment. An OAuth token is that key card. The scopes say which doors it opens, the expiry says for how long, and revocation is the cancel button at reception.

What it is

OAuth is a family of open standards from the IETF. For agent tool access, a handful of roles and pieces matter.

Part	Role in agent tool access
Resource owner	The person whose data or account is being used
Client	The agent application, or the agent host, that wants access
Authorisation server	The service that signs the user in, shows consent and issues tokens
Resource server	The API or tool server that accepts tokens, such as an MCP server
Access token	A short-lived credential sent with each request
Refresh token	A longer-lived credential used to get new access tokens
Scope	A named permission, such as read calendar or send email
Audience	The specific resource a token is meant for
PKCE	A proof that stops stolen authorisation codes from being used
Consent screen	The page where the user sees and approves the requested access

OAuth handles authorisation, which means what the agent may do. Signing the user in and proving who they are is usually handled by OpenID Connect, built on top of OAuth. Tokens are often JSON Web Tokens, but they do not have to be.

Where it came from

OAuth began in 2006 and 2007 as a way for websites to share access without sharing passwords. OAuth 2.0 was published as RFC 6749 in October 2012 and became the standard for delegated access on the web. Several extensions followed that matter for agents:

PKCE, RFC 7636 (2015), protects the authorisation code in public clients such as mobile and desktop apps.
The device authorisation grant, RFC 8628 (2019), lets devices without a browser ask a user to approve on another screen.
Token exchange, RFC 8693 (2020), lets one service swap a token for another, for example to act on behalf of a user towards a downstream API.
Resource indicators, RFC 8707 (2020), let a client say which resource a token is for, so tokens can be bound to one audience.
Protected resource metadata, RFC 9728 (2025), lets an API tell clients which authorisation server protects it.

OAuth 2.1, still an IETF draft, consolidates these lessons: PKCE for all clients, no implicit flow, and no password grant.

The Model Context Protocol added an authorisation specification in March 2025, revised it in June 2025 to treat MCP servers as OAuth resource servers, and in November 2025 added Client ID Metadata Documents as the preferred way for clients and servers with no prior relationship to register.

How it works

Step 1: The agent tries the tool

An agent, through its host application, calls a protected tool server without a token. The server replies with HTTP 401 and a header that points to its protected resource metadata. In MCP, the header can also say which scopes the request needs.

Step 2: Discovery

The client reads the metadata and learns which authorisation server to use. It then fetches that server's own metadata to find its endpoints and confirm it supports PKCE.

Step 3: Client registration

The authorisation server needs to know which client is asking. Options are pre-registration, a Client ID Metadata Document (the client uses an HTTPS URL as its ID, pointing to a JSON description with its name and redirect addresses), or dynamic client registration.

The client opens a browser to the authorisation server with the requested scopes, a PKCE challenge and a resource parameter naming the tool server. The user signs in and sees what is requested. If they approve, the browser returns an authorisation code to the client.

Step 5: Token exchange

The client sends the code and the PKCE verifier to the token endpoint. Because only the original client knows the verifier, a stolen code is useless. The client receives an access token, usually short-lived, and often a refresh token.

Step 6: Calling the tool

Every request to the tool server carries Authorization: Bearer <token>. The server validates the token: signature or introspection, expiry, scopes and, crucially, audience. A token issued for another service must be rejected.

Step 7: Downstream access and step-up

If the tool server itself calls another API, it must get its own token for that API, for example through token exchange or its own OAuth flow. It must never forward the user's token unchanged, which the MCP specification forbids as "token passthrough". If the agent needs more rights later, the server returns 403 with insufficient_scope, and the client asks the user to approve the extra scope.

Key concepts and terms

Term	Meaning
Delegated authorisation	Letting an app act for a user within limits the user approves
Authorisation code flow	Browser-based flow that returns a code later exchanged for tokens
PKCE	Proof Key for Code Exchange; binds the code to the client that requested it
Scope	A named permission attached to a token
Audience	The resource a token is valid for
Resource indicator	The `resource` parameter that names the intended audience
Protected resource metadata	A document that tells clients how an API is protected
Token exchange	Swapping one token for another, often for a downstream service
Token passthrough	Forwarding a received token to another service; forbidden in MCP
Confused deputy	A trusted service tricked into using its authority for an attacker
Step-up authorisation	Asking the user for extra scopes when a task needs them
Revocation	Cancelling a token or grant before it expires

A worked example

This scenario is illustrative. A company deploys an internal assistant that can read and draft email, check calendars and search a document store, all exposed as MCP servers.

On first use, an employee asks the assistant to find a free slot with a colleague. The calendar MCP server returns 401 with scope="calendar.read".
The assistant's host opens the company's sign-in page. The consent screen lists "Read your calendar". The employee approves.
The host receives an access token valid for 15 minutes, with audience set to the calendar server, and a refresh token that rotates on each use.
Later the employee says "send the invite". The calendar server replies 403 with insufficient_scope and calendar.write. The host asks the employee to approve the extra permission, and also shows a confirmation of the invite itself before sending, a human-in-the-loop step.
The document server receives a token for the calendar server by mistake and rejects it because the audience does not match.
When the employee leaves, the identity team revokes all grants for the account. Every agent connection stops working at once, with no shared keys to rotate.

Strengths and limitations

Strengths:

Agents never see or store user passwords.
Scopes and audiences limit what each token can do and where.
Short-lived tokens limit the damage from leaks.
Users and administrators can revoke access centrally.
Every action is tied to a user and a client, which helps auditing.
Widely supported standards with mature libraries.

Limitations:

Scopes are often coarse; "send email" may not distinguish one recipient from another.
OAuth does not stop a manipulated agent from misusing permissions it already has; see prompt injection defence.
The flows and specifications are complex and easy to implement wrongly.
Consent fatigue can lead users to approve everything.
Long-running background agents need careful refresh token handling and storage.
Many legacy APIs still only offer static API keys.

How it compares with alternatives

Option	How access works	Main risk
OAuth with scoped tokens	User approves limited, expiring, revocable access	Implementation complexity, coarse scopes
Shared API key	One static secret with broad rights	Leaks are severe and hard to trace
User password stored by agent	Agent signs in as the user	Full account exposure; violates most policies
Service account	Agent acts as itself, not as the user	Over-broad rights, weak per-user audit
mTLS client certificates	Machine identity proven at the connection	Identifies machines, not user consent

Practical guidance and best practices

Use the authorisation code flow with PKCE (S256) for every client, including desktop and command-line agents.
Request the smallest scopes that work, and add more through step-up only when needed.
Always send a resource indicator and always validate the audience on the server.
Never pass a received token through to another API; obtain a separate token instead.
Keep access tokens short-lived and rotate refresh tokens for public clients.
Store tokens in a proper secret store such as HashiCorp Vault, never in logs or prompts.
Require explicit confirmation for high-impact actions even when the scope allows them.
Log which user, client, scope and tool were involved in each call, and review regularly.

Common mistakes

Putting tokens into the model's context, where they can leak through output or injection.
Accepting any valid token without checking that it was issued for this server.
Asking for every scope on first connection "to save time".
Using one service account for all users, which hides who did what.
Treating OAuth as the whole security model and skipping sandboxing and approvals; see zero trust.
Allowing redirect URIs that are not exactly registered.

Frequently asked questions

Why should AI agents use OAuth?

Because it lets an agent act for a user with limited, expiring and revocable permissions, without ever handling the user's password, and it ties every action to a user and an application for auditing.

Is OAuth the same as signing in?

No. OAuth is about authorisation: what an application may do. Proving who the user is, authentication, is usually handled by OpenID Connect on top of OAuth.

How does MCP use OAuth?

For HTTP-based transports, an MCP server acts as an OAuth resource server. Clients discover its authorisation server through protected resource metadata, use the authorisation code flow with PKCE and a resource indicator, and send bearer tokens that the server must validate for audience.

What is token passthrough and why is it banned?

It is when a server forwards the token it received to another API. It breaks audience boundaries and can create confused deputy attacks, so the MCP specification forbids it. The server must get its own token for downstream calls.

Does OAuth stop prompt injection?

No. It limits what an agent can do, which reduces damage, but a manipulated agent can still misuse the permissions it has. Combine OAuth with injection defences, narrow tools and human approval for risky actions.

What about agents running in the background?

They typically use refresh tokens, stored securely and rotated, or a device-style flow for initial approval. For actions without a user, a service identity with tightly limited rights may be appropriate.

Glossary

OAuth: a framework for delegated authorisation.
Access token: a short-lived credential for API calls.
Refresh token: a credential for getting new access tokens.
Scope: a named permission.
Audience: the resource a token is for.
PKCE: protection against stolen authorisation codes.
Resource server: the API that accepts tokens.
Authorisation server: the service that issues tokens.
Consent: the user's approval of requested access.
Revocation: cancelling access early.

Summary

OAuth gives AI agents scoped, short-lived and revocable access to tools on a user's behalf, without passwords or shared keys. The core flow is discovery, consent, the authorisation code with PKCE, and bearer tokens bound to one audience. The MCP specification builds on this, requiring protected resource metadata, resource indicators and audience checks, and forbidding token passthrough. Use the smallest scopes, short lifetimes, secure storage and human confirmation for high-impact actions, and remember that OAuth limits damage but does not replace other agent defences.

It belongs to Protocols in my stack, under Agentic AI. Others in the same group:

MCP A2A Function calling Structured outputs