MCP authorization should let a client call a protected MCP server for an identified user and purpose without turning the user's credential into a master key. The safe design binds each access token to the MCP resource, validates it at that resource, requests only useful scopes and obtains a separate credential for any downstream API. The agent may propose an action, but authorization remains a deterministic exchange among the resource owner, client, authorization server and protected service.
This is a protocol implementation problem and an enterprise identity problem. The MCP server architecture guide explains the broader host and server boundary; this guide follows the current MCP OAuth profile through discovery, consent, audience validation and downstream delegation. It also connects to Edilec's secure API access control guide, because an MCP server must enforce object and action policy after validating a token.
Define the MCP authorization boundary first
For HTTP transports, a protected MCP server is an OAuth resource server and an MCP client is an OAuth client. The authorization server issues access tokens after interacting with the resource owner where necessary. The MCP authorization specification makes authorization optional for MCP generally, but defines the interoperability profile when HTTP authorization is supported. STDIO deployments obtain credentials through their local environment and should not mimic the HTTP flow.
Draw the canonical MCP server URI, authorization server, client redirect locations and every downstream resource. Decide which component owns consent, token validation, scope policy and revocation. A server that both exposes MCP and calls a finance API occupies two roles: resource server for the inbound MCP token and OAuth client or workload for the outbound finance token. Keeping those roles distinct prevents accidental pass-through.
Implement protected-resource discovery defensively
The protected MCP server publishes OAuth Protected Resource Metadata identifying acceptable authorization servers. A client learns the metadata location from a WWW-Authenticate challenge or the defined well-known URI and then discovers authorization-server endpoints. Validate HTTPS, exact issuer values and metadata consistency. Cache according to policy, but expire trust when keys, endpoints or registration claims change. Discovery reduces manual configuration; it does not establish organizational trust by itself.
Maintain an allowlist or federation policy for authorization servers acceptable to each environment. Guard metadata fetches against server-side request forgery, redirect abuse and oversized responses. Public clients need exact redirect URI matching and authorization-code protections. RFC 9700 updates OAuth security practice for dynamic environments; apply its guidance to the complete flow rather than treating MCP discovery as an exemption.
Bind every token to its MCP resource
MCP clients include a resource parameter in authorization and token requests to identify the canonical MCP server. This follows RFC 8707, which lets a client tell the authorization server where it intends to use the token. The authorization server should issue an audience-restricted token, and the MCP server must reject tokens not intended for it even when issuer, signature and expiry are otherwise valid.
Use the most specific stable resource URI that represents the protected deployment. Normalize it consistently and test path, port, trailing slash and case behavior. Do not accept a token minted for a neighboring MCP server, a gateway or a generic corporate API audience. Audience validation is the control that stops a credential legitimately obtained for a low-risk resource from being replayed against a more powerful one.
| Token or assertion | Intended audience | May carry | Must not be used for |
|---|---|---|---|
| User session | Application frontend | User authentication state | Calling MCP or downstream APIs directly |
| MCP access token | One canonical MCP resource | Granted MCP scopes and subject context | Unrelated MCP servers or backend APIs |
| Downstream access token | One business API | Narrow delegated or workload authority | Returning to the model or MCP client |
| Approval evidence | Action verifier | Request digest, approver and expiry | General API authentication |
Design scopes around capabilities and consequence
Scopes should express stable categories the resource server can enforce, such as customer records read or ticket creation, rather than mirroring every tool name or using one broad mcp.full_access value. Combine scope checks with tenant, object, amount, destination and workflow policy. A scope grants eligibility to request an operation; it does not prove that every argument is allowed. Keep high-impact write scopes out of initial authorization and request them through step-up only when required.
Consent must describe the actual resource, data and effects in terms a user or administrator can evaluate. Do not ask the model to approve its own authority. For enterprise deployments, administrators may pre-authorize low-risk scope bundles while a human approves consequential transactions at runtime. Bind that approval to immutable action fields and expiry. The agent tool permissions guide gives a practical action-tier model for this second layer.
Never pass the MCP token to downstream APIs
The MCP server terminates the inbound authorization decision. If it needs another API, it obtains a credential intended for that API using its workload identity, a supported on-behalf-of profile or token exchange. Forwarding the inbound bearer token leaks authority, violates audience separation and makes the downstream service unable to distinguish the MCP intermediary. It also expands the damage if logs, prompts or error messages expose the token.
RFC 8693 defines token exchange and distinguishes delegation from impersonation. Choose deliberately. Delegation can preserve both the subject and acting party, which is valuable for audit and policy; impersonation may make the intermediary invisible to the resource. Whatever profile the identity provider supports, the downstream token should be narrower in audience, scope and lifetime than the authority from which it was derived.
Close confused-deputy and token-theft paths
A confused deputy occurs when a privileged MCP server is induced to use its authority for an unauthorized caller or target. Validate the initiating principal, requested tenant and target object together. Do not let prompts select arbitrary backend endpoints, token audiences or authorization servers. Map each published tool to fixed service destinations and policy functions. Re-check authorization immediately before the side effect rather than relying on a decision made when the conversation began.
Keep access tokens out of model context, tool descriptions, traces and application analytics. Store refresh tokens only in an encrypted credential service bound to the client and user; rotate and revoke them through the authorization server. Prefer short access-token lifetimes and sender-constrained credentials where the ecosystem supports them. Errors shown to the model should identify an authorization class and recovery action, not echo headers or claims.
Test the complete authorization flow
Build a conformance suite around discovery, registration, authorization code flow, resource indicators, scope challenges and token validation. Include malicious issuer substitution, mismatched audience, expired keys, reused authorization code, altered redirect URI, insufficient scope and cross-tenant object access. Verify that a denied downstream call cannot be made through a different tool with equivalent effect. Tests should exercise both public and confidential client profiles actually deployed.
Run an end-to-end trace with synthetic identities. An investigator should be able to identify resource owner, MCP client, MCP server workload, authorization decision, downstream executor and final record change without seeing a secret. Connect those fields to the audit log design guide. Authorization that cannot be reconstructed after an incident is difficult to govern even when every token validated correctly.
| Test case | Expected result | Evidence |
|---|---|---|
| Token for another MCP audience | Reject before tool dispatch | Audience validation event |
| Valid scope, forbidden tenant | Reject at object policy | Subject, tenant and policy version |
| Backend API needed | Exchange or mint separate token | Inbound and outbound audiences linked |
| High-impact action | Pause for bound approval | Request digest and approval expiry |
| Credential appears in output | Redact and raise security alert | Leak-prevention event without token value |
Operate authorization as a changing dependency
Monitor discovery failures, issuer changes, key rotation, consent errors, denied audiences, scope escalation and downstream exchange failures separately. Alert on repeated token reuse across resources and sudden growth in privileged scopes. Version authorization metadata and client registrations alongside server releases. A tool schema change that creates a stronger side effect may require a new scope or approval policy even when its endpoint is unchanged.
Prepare revocation playbooks for a compromised client, MCP server and authorization server. Disable catalog visibility, revoke grants, rotate workload credentials and identify affected actions from trace evidence. Retain enough metadata to prove which policy and keys applied at the time, without retaining bearer tokens. Review grants periodically and remove clients, scopes and redirect URIs that no longer serve a production workflow.
Key takeaways
- Model the MCP server as its own protected resource and validate exact token audience.
- Treat discovery metadata as input to an enterprise trust policy, not automatic trust.
- Use stable least-privilege scopes plus argument, tenant and object authorization.
- Exchange or mint a separate downstream token; never pass the MCP bearer token through.
- Keep credentials out of model context and preserve a reconstructable delegation trail.
Frequently asked questions
Does every MCP server need OAuth?
No. The MCP specification makes authorization optional, and local STDIO servers use environment-provided credentials. A remote HTTP server protecting enterprise data or actions normally needs strong client and user authorization. Choose according to transport, trust boundary and consequence rather than copying one profile everywhere.
Can one token cover several MCP servers?
Avoid that design. Resource indicators and audience checks are intended to constrain a token to the target resource. Obtain separate access tokens for separate MCP resources, even when one authorization server issues them. This limits replay and makes grants understandable.
Are scopes enough to authorize a tool call?
No. Scopes express broad delegated capabilities. The MCP server still checks tenant, object, workflow state, values, separation of duties and any required approval. Downstream services must enforce their own invariants as the authoritative resource owners.
Conclusion
Good MCP authorization preserves boundaries. The user authorizes a client to reach one MCP resource; that resource validates audience and scope; business policy evaluates the exact action; and any backend receives its own constrained credential. At no point does the model need to handle a token or determine whether its proposed action is legally authorized.
Implement the deny paths first: wrong issuer, wrong audience, wrong tenant, excessive scope, changed request and failed token exchange. When each failure is contained and explainable, the successful path becomes both safer and easier to operate. Delegation then expands useful capability without expanding every credential to match it.