MCP Authentication and Authorization Guide

MCP authentication establishes or validates the identity behind a protected request. MCP authorization decides whether that identity, client, token, and consent may access a specific MCP resource or invoke a particular tool. A secure design needs both decisions and must carry them into the tool handler and downstream system.

Authentication and authorization are different decisions

Authentication answers “who or what presented this credential?” Token validation can establish issuer, subject, client, and other identity context. Authorization answers “may this subject perform this operation on this resource with these arguments now?” A valid token can still be unauthorized.

The distinction prevents two common errors: accepting any token from a trusted issuer, and treating successful user login as permission for every tool. It also clarifies why local and remote MCP deployments differ. A local stdio server often inherits an operating-system identity, while a protected remote server participates in an OAuth-based flow.

For protocol roles beyond security, read the Model Context Protocol definition. This page focuses on identity, tokens, consent, and action authorization rather than re-explaining tools and resources.

Map the MCP OAuth actors

The protected MCP server acts as an OAuth resource server. The MCP client requests access. An authorization server authenticates the user or workload, obtains consent or applies policy, and issues access tokens. The server may then use a separate identity to reach downstream APIs.

Name each actor and identifier. Record the MCP resource URI, authorization-server issuer, client registration, redirect URIs, subject, token audience, scopes, and downstream identity. Do not use “the agent” as one identity label when client software, user, server process, and service account make separate decisions.

The current MCP Authorization specification is the controlling protocol source for protected remote servers. Implementations should pin and review the specification version they support.

Understand discovery and authorization flow

A client first reaches a protected MCP resource or its metadata, discovers the relevant authorization server, and starts the appropriate authorization flow. User-facing public clients use authorization code with PKCE. Redirect URIs and state must be validated. The client then presents the access token to the MCP resource.

The server validates the token before exposing protected operations. Authentication at a reverse proxy is insufficient if an alternate transport, streaming endpoint, internal route, or cached connection bypasses the same decision.

Discovery data is part of the trust path. Require HTTPS, a canonical resource identifier, approved issuers, and environment-specific configuration. A production resource must not discover a test issuer or accept a redirect registered for a different client.

Bind tokens to the MCP resource

Bearer tokens must be intended for the receiving resource. For a JWT access token, validate signature, allowed algorithm, issuer, expiry, not-before, audience or resource, and scopes. For an opaque token, use the authorization server's approved introspection or validation path, then enforce resource and scope. Reject a token issued for an upstream API or another MCP server even if it comes from the same authorization server.

OAuth resource indicators let clients request a token for a particular protected resource. OAuth Resource Indicators defines that mechanism. Resource binding reduces token passthrough and confused-deputy risk because the MCP server cannot treat any valid organizational token as its own.

Do not forward the incoming bearer token unchanged to downstream APIs by default. Use an explicit token exchange, delegated flow, or server identity that preserves the intended subject and audience boundaries.

Design tool-level authorization

Scopes are coarse protocol permissions, not the final authorization decision. A server should validate the selected tool, normalized arguments, tenant, object ownership, destination, requested effect, and policy at execution time. Separate read and write and require stronger control for messages, deployments, financial actions, sensitive records, or destructive operations.

Bind approvals to exact arguments and a short lifetime. Adding a new tool or expanding a schema should not inherit consent granted to an older tool list. The handler must re-check authorization after redirects, aliases, path resolution, or other normalization that changes the actual target.

Downstream systems remain authoritative for their resources. The MCP layer should not turn a denied database or SaaS action into an allowed one by using an overprivileged service account.

Choose deployment patterns

For a single SaaS MCP server, a managed authorization server plus resource-server token validation usually has the lowest maintenance burden. For many internal servers, an identity-aware gateway can centralize discovery, client policy, and observability, but each server or downstream service still needs meaningful action authorization.

Machine-to-machine workloads need dedicated workload identities and narrowly scoped grants. Do not reuse human refresh tokens in automation. Local servers should rely on operating-system isolation, process provenance, and local secret handling rather than pretending an API key in a config file provides the same model as remote OAuth.

Broker and proxy patterns require extra confused-deputy analysis. A proxy that holds upstream credentials must bind the user's authorization to the specific upstream resource and must not ask users to consent to a generic proxy client for unrelated services.

Use deployment pattern as a review decision, not a product label:

• One protected remote server: define one resource, validate its tokens at the server, and authorize each tool against the resource and downstream target.
• Many internal servers behind a gateway: centralize discovery and common identity policy, while preserving a distinct resource and action boundary for every server.
• Local stdio server: rely on artifact provenance, operating-system identity, process isolation, and local secret controls; do not imply remote OAuth semantics that the transport does not use.
• Credential-holding proxy: bind consent and tokens to the exact upstream resource and test confused-deputy paths before allowing delegated actions.

Handle tokens and audit evidence

Keep access tokens, refresh tokens, authorization codes, PKCE verifiers, and client secrets out of prompts, model context, URLs, repositories, shell history, and normal logs. Use an OS credential store or managed secret system and rotate exposed credentials.

The credential leak prevention guide covers the broader agent path. MCP audit records should retain subject, client, issuer, resource, scopes, tool, normalized target, decision, and reason without storing bearer values.

Evidence must connect authorization to outcome. A denied request should leave the target unchanged. An allowed request should show the bounded identity and intended object, not an unrestricted service account acting with no user context.

Threats and failure modes

Test wrong issuer, audience, resource, scope, redirect, client, tenant, and expired or revoked tokens. Test authorization-code reuse, missing PKCE, key rotation, discovery outage, alternate transports, cached sessions, and direct handler access. Include a valid token that lacks permission for one consequential tool.

Confused-deputy attacks exploit a component that holds authority but cannot distinguish who authorized which target. Token passthrough, overly broad proxy consent, and shared credentials make that easier. Resource binding and per-action authorization reduce the ambiguity.

Authentication also does not establish server integrity. A correctly authenticated malicious or compromised server remains dangerous. Place identity controls inside the wider AI agent security architecture, alongside component trust, runtime policy, isolation, and downstream enforcement.

Architecture review checklist

An architecture is reviewable when it records: deployment type; resource URI; issuer; clients and redirects; user and workload identities; token validation rules; scopes; tool-level policies; downstream identities; secret storage; revocation; audit fields; bypass tests; and change triggers.

Turn that sentence into a signed review checklist:

• all resource and issuer identifiers are canonical and environment-specific;
• every public transport and internal route reaches token validation;
• scopes are mapped to tools, while object and tenant rules stay in deterministic policy;
• incoming tokens are not passed to unrelated downstream audiences;
• user, client, workload, and server identities remain distinguishable in audit evidence;
• secret storage, revocation, signing-key refresh, outage behavior, and rollback are tested;
• an allowed least-privilege request succeeds and every denial leaves the target unchanged.

Validate with one allowed request and several denied cases. Inspect target state after each. Re-run when protocol version, issuer, keys, client registration, redirect URI, resource identifier, scope, tool, schema, proxy, SDK, or downstream identity changes.

AgentGuard can add scan, policy, audit, and selected runtime evidence for supported integrations, but it does not replace the authorization server or resource-server validation. The public product boundary also avoids claiming complete coverage of every third-party MCP runtime call.

This architecture guide has a different search and internal-link role from the implementation page. How to Secure MCP Authentication is the step-by-step deployment and failure-test sequence for one protected server. This page explains actors, resource binding, scopes, deployment patterns, proxies, and threat boundaries so a team can choose an architecture before implementing it. What Is an MCP Server remains a short component definition and should send readers here only when identity design becomes their next task.