OAuth lets an application obtain limited access to another service without collecting the user’s password. For AI agents and remote MCP servers, that means a user can authorize specific tools or data while keeping access scoped, expiring, and revocable.

OAuth is an authorization framework. OpenID Connect adds an identity layer for sign-in. An access token is a credential; a JWT is one possible token format. Keeping those concepts separate prevents fragile security designs.

Why agents need delegated access

Suppose an assistant can read a calendar and create meetings. Copying the user’s password or permanent personal token into the agent would give broad, difficult-to-revoke access.

OAuth allows the application to request narrower permissions such as:

• read calendar events;
• create events;
• no permission to delete calendars;
• access for a limited account and time.

The user authorizes the service at the provider. The agent receives access through your controlled backend—not the user’s password.

The actors

OAuth term	AI/MCP example
Resource owner	User or organization granting access
Client	AI application or MCP client
Authorization server	Service that authenticates and issues tokens
Resource server	API or remote MCP server protecting tools/data
Access token	Credential presented to the resource server
Refresh token	Credential used to obtain a new access token

An agent is not automatically the OAuth client. In many architectures your backend is the confidential client and the agent operates under a narrower internal identity.

Authorization code flow with PKCE

For user-delegated access, the common high-level flow is:

1. Your application creates a random verifier and derived PKCE challenge.
2. It redirects the user to the authorization server with requested scopes and a state value.
3. The user authenticates and reviews consent.
4. The provider redirects to an exact registered callback with a short-lived code.
5. Your backend validates state and exchanges the code plus verifier for tokens.
6. Tokens are stored server-side and associated with the user, integration, and granted scopes.
7. The agent requests an approved action through your application policy layer.

PKCE binds the code exchange to the client that initiated it. The state value helps defend the callback flow against request forgery and mix-ups. Use the provider’s current OAuth and MCP documentation rather than copying endpoints from an old tutorial.

Scopes are a product decision

Do not request every permission because it may be useful later. Broad consent increases both user concern and damage if a token is exposed.

Map features to scopes:

summarize repository → repository:read
draft issue          → issues:write
merge pull request   → separate high-risk permission or confirmation

Show the user which integration and account the agent will access. When possible, let them connect read-only access before enabling write actions.

Consent must describe agent behavior

Traditional OAuth screens list scopes, but an AI product should also explain:

• which agent or workflow uses the connection;
• whether actions happen automatically;
• what data may be sent to model providers;
• which actions require confirmation;
• how to disconnect access;
• whether background runs continue after the session.

OAuth consent does not automatically equal consent to every future autonomous action.

Token storage

Keep access and refresh tokens out of browser storage when a backend can hold them. Encrypt sensitive stored tokens, limit which service can decrypt them, avoid logging them, and record ownership and scopes.

Refresh tokens deserve stronger controls because they can extend access. Use rotation when supported and detect reuse or failed rotation. On disconnect, revoke with the provider where possible and delete local usable copies.

See AI Security & Credentials and managing API keys and secrets.

MCP authorization boundary

A remote MCP server exposes capabilities that may read data or perform actions. Authentication establishes the caller; authorization must still decide which tools and resources are allowed.

Avoid designs where:

• one shared token grants every MCP user the same access;
• the model can request broader scopes itself;
• a tool description overrides server policy;
• tokens appear inside prompts or tool results;
• connecting one server implicitly trusts every tool indefinitely.

Use the MCP authentication guide for transport-specific implementation and AI agent authentication for the internal agent identity.

Public clients, confidential clients, and agents

A browser, desktop application, or CLI cannot always keep a client secret. Treat it as a public client and use the recommended PKCE flow. A secured backend can be a confidential client.

Do not embed an OAuth client secret in distributed software and call it protected. The authorization server should enforce the correct client type and redirect URIs.

High-risk actions

OAuth answers whether access was granted; it does not prove a specific agent action is appropriate. Add application controls:

• tool allowlists;
• argument validation;
• tenant policy;
• per-run budgets;
• human confirmation;
• idempotency keys;
• audit events;
• emergency revocation.

For destructive or financial actions, require explicit approval close to execution. Revalidate current authorization instead of relying on an old plan produced earlier in the agent run.

Common failures

• Treating OAuth as synonymous with login.
• Requesting broad scopes before they are needed.
• Storing refresh tokens in local storage.
• Accepting arbitrary callback URLs.
• Failing to validate state, issuer, audience, or token expiry.
• Giving an agent the user’s own permanent credential.
• Keeping integrations active after account or workspace removal.
• Assuming provider consent replaces product-level action approval.

Implementation checklist

• Register exact redirect URIs.
• Use authorization code with PKCE where recommended.
• Validate state and token metadata.
• Request narrow scopes tied to visible features.
• Store and rotate tokens server-side.
• Keep tokens out of prompts, logs, and model context.
• Separate user, application, and agent identity.
• Add policy and confirmation for consequential tools.
• Support revocation and offboarding.
• Audit who authorized which agent to perform which action.

Place OAuth within Authentication for AI Applications and the broader AI Application Architecture. OAuth is the delegation layer—not the entire security model.