TL;DR

In MCP, a protected server is an OAuth 2.1 resource server and the client is an OAuth 2.1 client; authorization is optional, but HTTP-based servers that need it should follow the spec.
Clients discover the authorization server from the server's Protected Resource Metadata (RFC 9728), get a client ID, then run OAuth 2.1 with PKCE and a resource indicator so the token is issued for that server only.
In production, pair the spec flow with your enterprise identity provider, short-lived scoped tokens, per-client access you can revoke, and an audit trail for every tool call.

MCP authorization is the part of the Model Context Protocol that decides whether a client, often an AI agent acting for a user, may call a protected MCP server and which tools it may use. The spec builds it on OAuth 2.1; authentication proves who the client and user are, and authorization limits what that identity can do.

How MCP authorization works

The current MCP specification (version 2026-07-28) defines authorization for HTTP-based transports. Local servers that run over STDIO don't use this flow; they take credentials from the environment.

The MCP authorization flow: a 401 challenge, discovery, client registration, OAuth authorization, then the authorized call.

The client calls the MCP server without a token and gets 401 Unauthorized. The WWW-Authenticate header points to the server's Protected Resource Metadata and can list the scopes it needs.
The client reads that metadata (RFC 9728) to find the authorization server, then reads the authorization server's own metadata (RFC 8414).
The client obtains a client ID: through a Client ID Metadata Document (recommended), pre-registration, or Dynamic Client Registration, which the spec now marks as deprecated.
The client runs the OAuth 2.1 authorization flow with PKCE, passing a resource indicator (RFC 8707) so the token is issued for that MCP server specifically.
The client calls the server with the access token. If a tool needs more scope than the token has, the server responds with an insufficient-scope challenge and the client can request step-up authorization.

Two rules matter most for security. The server must only accept tokens issued for it, and it must not pass a client's token through to upstream APIs; it should use its own credentials for those calls.

Why MCP authorization matters

MCP changes the threat model because agents and distributed servers act autonomously and may process sensitive enterprise data. That increases the attack surface and the risk of lateral movement. A single compromised agent can attempt many API calls quickly.

Authentication proves the identity of a server, agent, or user. Authorization decides what that identity can do. Both are required: identity alone is not enough, and authorization without strong authentication is risky.

Common risks when these are poorly implemented:

Long-lived credentials exposed in images or repositories that remain valid for months.
Replay or token theft when tokens are not audience- or client-bound.
Over-broad scopes or roles that allow destructive actions, for example write or delete of sensitive records.
Configuration drift across many MCP servers that results in inconsistent privileges.
Missing audit trails that make incident investigation impossible and slow revocation of compromised instances.

Centralized auth ties MCP servers into enterprise IAM and SSO for access reviews, separation of duties, and SCIM provisioning lifecycles. Auditors expect evidence of who or which service called an API and the ability to revoke it quickly. Vendors commonly recommend storing credentials in a credential manager and capturing execution traces to satisfy auditors.

Operational pain points that motivate these patterns:

Scaling auth setup across thousands of MCP servers without manual steps.
Rotating secrets without downtime for running agents.
Mapping business roles to scopes that represent least privilege.
Observing which agent or user executed automated actions for audit and rollback.

Core patterns for MCP authorization

OAuth2 client credentials for server and service accounts

Use OAuth2 client credentials for non-user flows. Keep clients scope-limited and issue short-lived access tokens, typically with TTLs of 5–15 minutes. Use refresh tokens only when the IdP supports them securely.
Automate rotation of client secrets or use dynamic client registration to avoid manual secret distribution.

Token exchange and on-behalf-of flows

When an agent must act for a user, use token exchange or on-behalf-of flows to propagate user intent while minimizing the agent’s permanent privileges. Enforce strict audience and scope checks and record original user and agent in logs.
RFC 8693 defines token exchange semantics; restrict the resulting token’s lifetime and scopes to the minimum required.

Signed JWTs and JWKS

Use signed, audience-restricted JWTs for stateless validation when low-latency checks are needed. Validate issuer, audience, expiration, and required custom claims.
Fetch signing keys from a JWKS endpoint and implement key rotation with overlap to avoid outages, for example publish new keys 24–48 hours before removal.

Mutual TLS for server-to-server authentication

Use mTLS where cryptographic client binding is required. Automate certificate issuance through an internal PKI or ACME-based workflow and issue short-lived certificates measured in days rather than months.

API gateway and policy placement

Centralize runtime policy enforcement at an API gateway or policy enforcement point to reduce complexity on MCP servers. Gateways handle token validation, rate limits, attribute-based policy checks, and centralized logging.

Role-based and attribute-based controls

Map enterprise roles and attributes, such as department and sensitivity, onto OAuth scopes and resource permissions. Combine RBAC and ABAC for fine-grained control and separation of duties.

Securing server-to-server authentication

Use mTLS when strong identity binding is required

Server-to-server calls use their own credentials, such as mutual TLS, rather than passing the client's token upstream.

Mutual TLS binds a certificate to a server identity and prevents token replay from other hosts. Automate certificate issuance via an internal CA or ACME and enforce automatic revocation and rotation, with short cert TTLs for ephemeral instances.

When bearer tokens are used, ensure token hygiene

Issue short-lived tokens, recommended at 15 minutes or less for access tokens. Enforce audience and scope checks and prefer sender-constrained tokens when possible. Support token introspection for revocation checks.

Establish secure trust-material distribution

Never bake long-lived secrets into images or code. Use instance metadata or signed ephemeral bootstrap tokens to fetch credentials from a control plane or secrets manager. Use least-privilege IAM roles for the bootstrap step.

Validate tokens and certificates strictly

Validate issuer, audience, expiration, and required claims. Verify signatures against JWKS endpoints and enforce clock skew limits, such as two minutes. Log validation failures centrally.

Plan for compromise

Have revocation mechanisms, including a token-introspection endpoint, short token TTLs, revocation lists for certificates, and control-plane ability to isolate or decommission individual MCP servers quickly via orchestration.

Centralized management and security profiles

In Koodisi, a Security Profile defines the scopes and claims an API requires, a published API collection becomes an MCP server, each client gets its own OAuth app, and every tool call is recorded as a traceable event. The secured MCP server quickstart walks through it step by step, and exposing an API as a governed MCP server covers the identity layer in depth. For deciding which tools need which controls, see classifying MCP tools by risk and the wider AI agent governance framework.

One security profile defines the scopes and claims, and is applied consistently across every MCP server.

Define a security profile

A security profile is a versioned object containing the authentication method, required scopes and roles, certificate policy, rotation cadence, secrets references, telemetry settings, and policy attachments. Profiles should be attachable to MCP servers at provisioning time.

How to apply profiles

Use the control plane to push profiles during provisioning and treat certain baseline settings as immutable to prevent drift. Profiles enable rolling updates and staged rollouts across environments.

Integration points

Store keys and certificates in a secrets manager. Integrate client registration and SCIM provisioning with your IdP. Use CI/CD to bake policy-as-code and rely on telemetry backends for centralized audit logs.

Automation to reduce risk

Enable dynamic client registration, automated credential rotation, and policy-as-code for authorization rules. Implement periodic health checks that assert profile compliance and fail fast if drift is detected.

Operational governance

Assign owners for each profile, schedule access reviews, and document rollback and incident processes so profile changes do not cause outages.

Comparing MCP authorization options

Options to compare include API keys, OAuth2 client credentials, token exchange and on-behalf-of, signed JWTs validated via JWKS, mutual TLS, and SAML assertions for legacy integrations.

Option	Security posture	Delegation support	Scalability (rotation/provisioning)	Operational complexity	Enterprise IdP support	Auditability
API keys	Low: long-lived, easily leaked	None	Poor: manual rotation	Low config, high risk	Limited	Low
OAuth2 client credentials	Medium: bearer tokens; short TTLs improve security	Limited; use token exchange to delegate	Good: supports automation and dynamic registration	Moderate	Widely supported (OIDC)	Good
Token exchange / OBO	Medium-high: supports least-privilege delegation	Strong: designed for agent on behalf of user	Good: depends on IdP features	Higher: needs careful claims and consent	Supported by modern IdPs (RFC 8693)	High
Signed JWTs (JWKS)	High when signed and audience-restricted	Stateless; delegation requires exchange	Very scalable: stateless validation	Moderate: JWKS rotation required	Supported	Good
mTLS	Very high: cryptographic client binding	Delegation usually via tokens layered on mTLS	Scalable with automated PKI	High: PKI automation needed	Supported for server certs	Very high
SAML assertions	Medium: legacy SSO use cases	Limited for machine-to-machine	Poor for short-lived machine auth	High for legacy SSO	Supported in enterprise	Medium

High-level recommendations

Use OAuth2 client credentials for standard server identities and short-lived tokens. Add token exchange or on-behalf-of when agents must act for users. Prefer mTLS where cryptographic client binding is required. Avoid long-lived API keys except for constrained legacy cases.

When to choose which

For proof-of-concepts, start with client credentials in a restricted environment. For high-assurance flows use mTLS with short-lived certificates plus short-lived tokens. For agent OBO flows use token exchange with strict claim restrictions and consent.

Quick decision guide

Need a fast start and limited scope: OAuth2 client credentials with strict scopes.
Must prove cryptographic identity: mTLS with automated PKI.
Agent must act for users: token exchange or on-behalf-of with minimal resulting scopes.

Implementation checklist and best practices

Inventory

Catalog every MCP server, agent type, and service account. Classify by data sensitivity and required minimal privileges.

Choose auth methods per class

Map which servers require mTLS, which use client credentials, and which need token-exchange or on-behalf-of based on sensitivity and delegation needs.

Integrate with IdP and provisioning

Configure client registrations, enable SCIM for lifecycle, and automate dynamic registrations where supported by the IdP.

Secrets and certificates

Keep secrets only in a secure store. Use short-lived credentials and automate rotation. Never embed long-lived secrets in images or configuration files.

Policy enforcement and telemetry

Centralize PDP/PEP or gateway checks and enable token introspection and logging. Capture access logs and audit trails, and set alerts for abnormal patterns.

Test and validate

Run threat models. Simulate token theft and server compromise. Perform chaos testing for auth failures and validate profile rollouts in staging before production.

Operational runbook

Document steps for key compromise, certificate revocation, and emergency credential rotation. Ensure on-call staff have clear incident playbooks.

Want to see how this works on your own systems? Book a Koodisi demo.

Frequently asked questions

What is mcp authorization and how is it different from traditional API auth?

MCP authorization secures autonomous agent and server calls, not just user-driven APIs. The difference is the threat model: agents act without a human operator and often at scale. That requires short-lived, audience-bound tokens, centralized policy, and automated revocation to limit blast radius.

How should MCP servers authenticate to my enterprise IdP

Choose based on risk. Use client credentials for standard machine identities and short-lived tokens for scale. Add mTLS for high-assurance or regulation-required flows. Combining mTLS for identity with OAuth2 tokens for authorization gives strong guarantees.

Can I safely let an MCP agent act on behalf of a user, and how do I implement that?

Yes. Implement RFC 8693 token exchange or an on-behalf-of flow, limit the delegated token's scope and TTL, and log both the original user and agent for audit.

How do I scale credential rotation and avoid configuring every MCP server manually?

Use dynamic client registration, a secrets manager such as Vault or cloud KMS, control-plane security profiles applied at provisioning, and short-lived bootstrap tokens to fetch credentials at runtime.

What telemetry and audit data should I collect to prove compliance for MCP flows?

Collect structured access logs, token introspection events, certificate issuance and revocation history, and OpenTelemetry traces that tie user, agent, and action together. Export traces and logs to a centralized observability stack.

MCP authorization and authentication: how it works and how to secure it