What Is MCP Authorization?
MCP authorization is the mechanism that decides whether an MCP client can access a protected MCP server and which of its tools and data it can use, usually on behalf of a user. It applies to remote MCP servers accessed over HTTP and is built on OAuth 2.1, so the AI application works with a scoped access token instead of the user’s credentials. The specification makes authorization optional, and local servers that run over STDIO should retrieve credentials from the environment instead of following this flow.
How MCP Differs From Traditional API Authorization
MCP builds on the same OAuth standards as a typical API, and most of the differences come from who connects and how access is discovered and requested.
| Aspect |
Traditional API Authorization |
MCP Authorization |
| Who Connects |
Known applications, first-party or third-party, built to call that API |
MCP clients inside AI applications, often connecting to servers they haven’t used before |
| Client Registration |
Usually registered with the provider ahead of time |
Clients can identify themselves with a Client ID Metadata Document where supported, with pre-registration still an option |
| Finding the Authorization Server |
Often configured from provider documentation, with discovery available but optional |
Discovered through the Protected Resource Metadata every protected MCP server must publish |
| Who Picks the Action |
Application logic selects which operations to call |
An AI model can select tools at runtime, within the limits the application sets |
| Token Audience |
Audience restrictions depend on the authorization profile and implementation |
Clients must request tokens for a specific MCP server, and the server must confirm each token was issued for it |
| Permission Requests |
The application requests scopes, sometimes incrementally |
The server can signal the scopes an operation needs, and clients can request more through step-up authorization |
The Building Blocks of MCP Authorization
MCP authorization relies on a small set of roles, credentials, and standards taken from OAuth 2.1. Each one has a defined job, and together they decide who can access an MCP server and what they can do there.
- Authorization Server and Resource Server: The authorization server authenticates the user when needed and issues access tokens. In enterprise deployments, it’s often an existing identity provider such as Okta or Microsoft Entra ID. The protected MCP server acts as the resource server and accepts requests only when they carry a valid access token. The specification allows both roles to run on the same host, but they remain separate functions.
- MCP Client and Access Tokens: The MCP client runs inside an AI application and acts as the OAuth client, making requests to the MCP server on behalf of the user. The access token is the credential it presents. Each token is requested for one specific MCP server and carries only the permissions it was granted.
- Scopes and Protected Resource Metadata: Scopes define what an access token allows, such as reading files (files:read) without writing them. Protected Resource Metadata is a document every protected MCP server must publish. It identifies the authorization servers that can issue tokens for that server and may list supported scopes. Clients use it to discover the authorization server, while scope challenges can indicate the permissions needed for a particular operation.
- PKCE and Client Registration: PKCE (Proof Key for Code Exchange) ties each authorization request to a one-time secret held by the client, so an intercepted authorization code is useless to anyone else. MCP clients must use it and refuse to proceed if the authorization server doesn’t advertise support. Client registration is how a client gets its client ID before requesting authorization. It can do that through a Client ID Metadata Document, pre-registration with the authorization server, or Dynamic Client Registration. The 2026-07-28 specification deprecates Dynamic Client Registration in favor of Client ID Metadata Documents and keeps it only for backward compatibility.
How MCP Authorization Works
MCP authorization follows a standard OAuth 2.1 flow, adapted for clients that may know nothing about a server before they connect. It unfolds in 3 stages, with the client finding where to get a token, obtaining it, and using it on each request.
1. Discovery
Discovery is how a client learns which authorization server protects an MCP server, without prior configuration.
- Client Calls the Server Without a Token: The client sends its first request with no credentials, since it doesn’t yet know authorization is required.
- Server Returns a 401 With Metadata: The server responds with a 401 Unauthorized whose WWW-Authenticate header can point to its Protected Resource Metadata and name the scopes needed. If it doesn’t, the client checks a well-known URL.
- Client Locates the Authorization Server: The client picks an authorization server from the metadata and fetches that server’s own metadata, which shows where users sign in, where to request tokens, and what the server supports.
2. Authorization
With the authorization server located, the client obtains an access token on the user’s behalf.
- Client Identifies Itself: The client presents a client ID from one of the 3 registration methods. Pre-registered and dynamically issued credentials are tied to one authorization server, while Client ID Metadata Document URLs work across any that support them.
- Authorization Code Flow With PKCE: The client opens the user’s browser to the authorization server with a PKCE code challenge, the requested scopes, and a resource parameter naming the target MCP server. After the user approves, the client receives an authorization code and checks that it came from the expected authorization server.
- Authorization Server Issues a Token: The client exchanges the code, its code verifier, and the same resource parameter for an access token issued for that MCP server, and sometimes a refresh token.
3. Access
The client can now call the MCP server, which checks the token on every request.
- Client Sends the Bearer Token: Every HTTP request carries the token in the Authorization header, never in the URL, and clients send only tokens from the server’s own authorization server.
- Server Validates the Token: The server checks that the token is genuine, unexpired, and issued for it, either by verifying its signature or by asking the authorization server, and answers any failure with a 401.
- Scopes Limit Tool Access: How scopes map to tools is up to the server. If the token’s scopes don’t cover the requested operation, the server returns a 403 with an insufficient_scope error listing what’s required, and the client can request a new token that adds those scopes to its existing ones.
MCP Authorization Risks in Enterprise Deployments
The authorization flow is only as strong as the way an organization configures and governs it. The risks below mostly come from deployment choices and gaps in oversight rather than from the protocol itself.
| Risk |
How It Happens |
Enterprise Impact |
| Over-Permissioned OAuth Scopes |
Servers define coarse scopes or a broad default set, or clients request permissions beyond what a task needs |
A stolen token or a manipulated agent can use every tool and dataset the token covers, far beyond the task it was granted for |
| Token Passthrough to Downstream Services |
An MCP server takes the token it received from the client and forwards it to another API instead of obtaining its own token, a practice the specification forbids |
Can bypass controls that depend on token audience or client identity, obscure which application initiated an action, and enable unauthorized downstream access when tokens are accepted outside their intended audience |
| Unverified MCP Servers |
Users or developers connect agents to third-party or community MCP servers that security teams have never reviewed, then grant them OAuth consent |
Corporate data access ends up with servers outside any inventory or review, and a malicious server can misuse the access or feed manipulated tool descriptions to the model |
| Stale Tokens and Forgotten Consents |
Refresh tokens and consent grants stay active after the agent, project, or employee that needed them is gone |
Dormant access outlives its business purpose, slips past offboarding, and becomes a ready entry point if a token leaks |
| Confused Deputy Attacks in Chained Calls |
An agent or MCP server uses its own broader permissions to act for a caller without checking that caller’s rights, and the original user’s identity gets lost as calls pass between agents and tools |
A low-privilege user or a prompt-injected agent can trigger actions it could never perform directly, and the specification describes a related variant in MCP proxy servers that use a static client ID with a third-party authorization server |
How to Implement MCP Authorization Step-by-Step
Implementing MCP authorization mostly means connecting an MCP server to identity infrastructure the organization already runs. The steps below follow the order a team would typically work in, from deciding whether a server needs protection to testing the full flow.
- Confirm the Server Needs Authorization: Remote MCP servers reached over HTTP that expose company data or actions should require it.
- Register the Server With Your Authorization Server: Add the MCP server as a protected resource in your existing identity provider. Confirm the provider supports OAuth 2.1 with PKCE, publishes its metadata, and ideally supports Client ID Metadata Documents.
- Define Scopes Around Tools: Map scopes to individual tools or small groups of related tools, such as files:read and files:write. Keep the default set limited to what basic functionality needs.
- Publish Protected Resource Metadata: Expose the metadata document at the server’s well-known URL, using the server’s canonical URI as its resource identifier and listing the authorization servers that can issue tokens for it.
- Return Proper 401 Challenges: Answer requests without a valid token with a 401 response whose WWW-Authenticate header points to the metadata and names the scopes the request needs.
- Validate Every Token: On each request, check that the token is genuine, unexpired, and issued for this specific server, and reject anything else with a 401.
- Enforce Scopes on Each Tool Call: Before running a tool, confirm the token’s scopes cover it. When they don’t, return a scope challenge so the client can request more access.
- Get Separate Credentials for Downstream APIs: If the server calls other services, it should obtain its own tokens for them, for example through token exchange, rather than forwarding the client’s token.
- Log Authorization Events: Record token validations, denials, and scope challenges with enough context to trace which user, client, and tool were involved.
- Test the Full Flow: Run the server against a client that follows the current specification. Include expired tokens, tokens issued for a different server, and requests that need more scopes than the token carries.
MCP Authorization in Multi-Agent Workflows
In multi-agent workflows, a single user request can pass through several agents and MCP servers before any tool runs. The specification covers each client-to-server connection, but not how authority carries across the whole chain.
How Agents Chain Tool Calls
An orchestrator agent splits a task into steps and hands them to sub-agents, which call MCP servers that may call further servers or APIs.
- Each Protected Resource Checks Authorization: The caller acts as the OAuth client and the receiver as the resource server, so an MCP server that calls another service plays both roles. A valid token can be reused for the resource it was issued for.
- The Path Forms at Runtime: Models choose which agents and tools to call as the task unfolds, so the full chain often isn’t known until it runs.
Token Propagation Across Agents
When a server calls a different protected resource, it needs a token valid for that resource instead of forwarding the token it received.
| Approach |
How It Works |
Trade-off |
| Token Exchange |
The service swaps the token it received for a new one scoped to the next resource (RFC 8693) |
Can keep the user’s identity in the chain, depending on authorization server policy and token claims |
| The Agent’s Own Credentials |
The service uses a token issued to itself, such as through the client credentials grant |
Simple, but the next service sees the agent instead of the user |
| A New User Authorization |
The service asks the user to approve access to the next resource |
Clearest consent, but interrupts automated workflows |
Scope Inheritance and Permission Drift
Each downstream token should grant only the permissions needed at that resource, within the authority delegated for the task.
- Inheritance Breaks: Sub-agents running on their own service credentials can hold broader access than the user they act for.
- Scopes Accumulate: Step-up requests combine earlier scopes with newly required ones, so access can grow broader each time a request is approved.
- Drift Goes Unnoticed: New tools, reused sub-agents, and unrevoked consents widen an agent’s access without anyone approving the total.
How to Scope MCP Authorization Correctly
Getting MCP authorization right is less about following the flow and more about the decisions around it. These 5 principles cover the judgment calls that decide how much access an agent ends up with.
- Treat MCP Servers as OAuth Resource Servers: Keep login, consent, and token issuance out of the MCP server, even though the specification allows them on the same host. A server that only validates tokens and enforces scopes is simpler to secure and keeps identity logic in one place.
- Delegate Sign-In to Your Identity Provider: Route user access through the identity provider that already enforces SSO, MFA, and conditional access, so agents follow the same policies and offboarding as every other app. For machine-to-machine access with no user involved, use the client credentials grant where supported, with an appropriate client authentication method such as mutual TLS.
- Grant the Narrowest Scope Per Tool: Keep read, write, and destructive actions in separate scopes, and group tools only when they carry the same risk. A useful test is whether a stolen token with that scope would count as an incident.
- Never Pass Client Tokens to Downstream APIs: When choosing between token exchange and the server’s own credentials, base the decision on whether the downstream service sets permissions by user.
- Re-Review Access When Agents or Tools Change: Review access whenever an agent’s tools, workflows, or owner change, not only on a fixed schedule. Compare granted scopes with what the agent uses, and revoke refresh tokens and consents that no longer serve a task.
How Opsin Governs MCP Access and Agent Risk
MCP authorization validates tokens, but it doesn’t show which MCP servers agents use, what those servers can reach, or whether agents stay on task. Opsin fills that gap, and its 2026 State of Agentic Adoption Report found that 60% of agents provisioned beyond default settings had allow-all access their tasks didn’t require.
- MCP Server Inventory and Classification: Opsin inventories MCP servers and tools reported by connected enterprise AI platforms, with nothing to deploy, and classifies each one by capability and exposure scope.
- MCP Connection and Identity Mapping: Each connection maps to the agents using it, and each agent maps to its owner, permissions, and users. Teams tag sensitive connections, and ongoing oversharing protection keeps that data from surfacing through AI queries.
- Risk Graph Prioritization for MCP Servers: Opsin ranks agents and connections by access, data, and capabilities, surfacing risky combinations in one prioritized view with plain-language reasoning behind each finding.
- Behavior Tracked Against Agent Intent: Agent Runtime Security compares each agent’s intended purpose with its live activity, data access, and tool use, including MCP tool calls where platforms expose them.
- Quarantine, Restrict, or Notify: Teams can quarantine an agent or restrict an MCP server, while recommended fixes such as narrowing scope or removing a connection go to the agent’s owner with step-by-step guidance.
- AI Readiness Assessment for MCP Exposure: An AI Readiness Assessment maps every MCP server that agents can invoke and delivers a prioritized remediation roadmap within 24 hours, reading only metadata and permissions.
Conclusion
MCP authorization answers a narrow question well. Is this token valid, and was it issued for this server?
The harder questions sit outside the token. Which servers can your agents reach, what can those servers touch, and is each agent still doing the job it was built for? A token can be perfectly valid and still carry far more access than the task needs.
So keep token validation at the server, tie permissions to the task, and review access every time an agent or tool changes. Opsin gives security teams the visibility to hold those lines as agents multiply, so a valid token doesn’t turn into a blank check.
