Complete Guide to MCP Identity

Agents don't ask permission. They act. MCP identity is how a Model Context Protocol deployment keeps that power in check, by answering three questions every time an AI agent calls a tool: who is the human behind this request, which agent is acting on their behalf, and what is that agent actually allowed to do on this MCP server. It is the authentication and authorization layer that decides whether a given tool call is permitted, and it is the single most important control for running MCP safely in production.

This guide is written for the platform engineers, security and IAM leaders, and AI-platform architects who are connecting agents to real systems through MCP. It assumes you already understand OAuth, SSO, and role-based access control, and focuses on the part that is genuinely new: how those identity primitives map onto MCP servers, clients, and the agents that drive them. We will define MCP identity, walk through the OAuth 2.1 standards the protocol now builds on, show how the authorization flow works end to end, explain how to enforce least privilege per tool, cover the confused-deputy class of failures the spec is designed to prevent, and lay out best practices and an implementation checklist.

What is MCP identity?

MCP identity is the set of mechanisms that authenticate and authorize requests in a Model Context Protocol system. In practice it answers two distinct questions for every tool call: who is making this request (authentication) and what are they allowed to do (authorization). Because MCP sits between AI agents and the tools, data, and APIs they act on, getting identity right is what separates a demo from a deployment you can trust in front of customer data.

The reason MCP identity is harder than ordinary API authentication is that there is rarely just one party in the request. There are three.

The three-party identity problem

A single MCP tool call typically involves three separate identities:

• The human user: the person who ultimately authorized the work and whose permissions should bound what happens.
• The agent, host, and client: the AI application (for example a chat client or an autonomous agent) and the MCP client library acting on the human's behalf.
• The MCP server and tool: the resource being called, which exposes one or more tools that touch real systems. See our guide to MCP servers for how these are built and operated.

The common mistake is to collapse these three into one shared credential. A team wires an agent to an MCP server with a single long-lived API key or a service account, and now every request carries the maximum authority of that credential regardless of which human triggered it or what the task actually needed. That is the root cause of over-privilege, oversized blast radius, and the confused-deputy attacks we cover later. Treating the human, the agent, and the server as distinct identities, and brokering a narrowly scoped delegation between them, is the entire point of MCP identity.

Why MCP identity matters

MCP unlocks agents that can read, write, and act across your systems. That power is exactly why identity cannot be an afterthought. Without a real identity model:

• Over-privilege becomes the default. A shared credential gives every agent every permission, so a single prompt injection or logic error can do far more damage than the task ever required.
• Blast radius is unbounded. If you cannot tell which human or which agent made a call, you cannot contain or revoke access surgically when something goes wrong. This is the heart of the single-entity confused-deputy concern raised against MCP.
• You lose auditability and compliance. Regulators and security teams expect a clear chain of who authorized what. A shared token erases that chain.
• Enterprise adoption stalls. Security review will not approve agents that bypass your existing identity provider, SSO, and MFA.

Identity is the foundation that makes everything else about MCP security possible. You cannot apply least privilege, audit, or policy if you do not first know who is who.

Authentication vs authorization in MCP

These two words are often used interchangeably, but in MCP they are separate steps and you need both. Authentication proves identity; authorization decides what that identity may do.

Aspect	Authentication (MCP authentication)	Authorization (MCP authorization)
Question answered	Who is making this request?	What is this identity allowed to do?
Mechanism in MCP	OAuth 2.1 / OIDC token issued by an authorization server, verified by the MCP server	Scopes, roles (RBAC), and per-tool permissions checked against the token's claims
Failure if missing	Anonymous or spoofed callers reach your tools	Authenticated callers can invoke tools far beyond their need
Where it happens	At the edge, when the token is validated	On every tool call, against policy

A correctly secured MCP server requires a valid access token for any request (authentication) and then checks that the token actually grants the scope the specific tool requires (authorization). Skipping the second step is one of the most common MCP identity mistakes.

The standards behind MCP identity

As of the 2025 revisions to the specification, MCP identity is built squarely on standard OAuth 2.1. An MCP server is formally an OAuth 2.1 Resource Server, an MCP host or client is an OAuth client acting on behalf of the resource owner, and a separate Authorization Server handles user interaction and issues access tokens, as set out in the MCP authorization specification. This reuse of OAuth 2.1 and OpenID Connect (OIDC) means MCP identity can plug into the identity infrastructure enterprises already run rather than inventing something new. Tokens are typically JWTs, and public clients use PKCE to protect the authorization code exchange.

Protected Resource Metadata and discovery

MCP servers must implement OAuth 2.0 Protected Resource Metadata, defined in RFC 9728, and MCP clients must use it to discover the authorization server. The server advertises where its authorization server lives at the well-known endpoint /.well-known/oauth-protected-resource, so a client can find the legitimate authority to request tokens from instead of guessing. This removes ambiguity and is what lets MCP clients connect to servers they have never seen before in a secure, standard way.

Resource Indicators and audience binding

MCP clients are required to use Resource Indicators, defined in RFC 8707, so that a token is bound to the specific MCP server it is meant for. The server then verifies the audience (aud) claim on every request and rejects any token issued for a different service, even if that token is properly signed and unexpired. Audience binding is a core defense against token replay and the confused-deputy problem.

Dynamic Client Registration

Because an MCP client may encounter a server it has never met, the spec allows Dynamic Client Registration (DCR), defined in RFC 7591. DCR lets a client POST its metadata to a registration endpoint at runtime and receive a client_id automatically, removing the need for someone to manually provision client credentials for every new server. DCR is powerful but also a hardening concern, since an open registration endpoint can be abused, so many enterprises gate or constrain it. The community is also moving toward Client ID Metadata Documents (CIMD), where a client hosts a static JSON metadata file at an HTTPS URL as a more decentralized way to establish trust.

How MCP identity works

Putting the standards together, here is the end-to-end flow when an agent calls a protected MCP server:

1. Discovery. The MCP client reads the server's Protected Resource Metadata (RFC 9728) to learn which authorization server to use.
2. Authorization. The client initiates an OAuth 2.1 authorization flow with PKCE. The authorization server authenticates the human, typically through your enterprise SSO and MFA, and obtains their consent.
3. Token issuance. The authorization server issues a scoped access token, bound to the target MCP server via a Resource Indicator (RFC 8707) and carrying the scopes and role claims the human is entitled to.
4. Validation. On each request, the MCP server validates the token signature, checks expiry, and verifies the aud claim matches its own identifier. Tokens for other services are rejected.
5. Scoped tool call. Before executing a tool, the server checks that the token's scopes and roles permit that specific tool. Only then does the tool run.

The important property of this flow is that the human is authenticated once, through infrastructure you already trust, and what reaches the tool is a narrowly scoped, audience-bound, short-lived token rather than a blanket credential.

Access control: scopes, least privilege, and RBAC

Authentication gets you a trustworthy identity. Access control is how you keep that identity from doing more than it should. In MCP, access control (MCP access control) is built from three layers that work together.

• Scopes per tool. Define granular OAuth scopes that map to individual tools or capabilities, following the principle of least privilege. If a server exposes a sendEmail tool and a readContacts tool, give them separate scopes such as email.send and contacts.read, and only execute a tool if the token grants its scope.
• Roles (RBAC). Map sets of scopes to roles so you can manage permissions at human scale. MCP RBAC commonly works by carrying the user's roles as claims in the token and matching them against the server's policy on each call. Sensitive tools can be restricted to an admin role.
• Per-tool permission checks. Enforce the check at the point of the tool call, not just at the connection. A token that authenticates successfully should still be denied any tool whose scope it does not hold.

MCP tool	Required scope	Roles allowed
readContacts	contacts.read	viewer, agent, admin
sendEmail	email.send	agent, admin
deleteRecord	records.delete	admin

This is what makes MCP tool permissions concrete: least privilege is not a slogan, it is the difference between an agent that can read a calendar and an agent that can wire money.

Connecting MCP to your enterprise identity provider

The strongest pattern in enterprise MCP deployments is to delegate authentication to your existing identity provider rather than building authorization logic inside each MCP server, a pattern explained well in this neutral overview of authentication and authorization in MCP. The MCP server acts as a relying party (an OAuth resource server) that trusts tokens issued by your IdP, verifies their scopes and roles, and reuses the SSO and MFA you already enforce. This gives you MCP SSO without standing up a parallel identity system, and it means deprovisioning a user in your IdP immediately cuts off their agents too.

An MCP identity provider in this model is simply your standard enterprise IdP, configured as the authorization server for your MCP servers. That keeps agent access governed by the same policies, lifecycle, and audit as the rest of your workforce identity.

Okta, Microsoft Entra, Auth0, and Keycloak

The major identity platforms can all serve as the authorization server for MCP. Teams commonly wire MCP to Okta or Microsoft Entra for workforce SSO (MCP Okta and MCP Entra integrations), or use Auth0 or Keycloak where they want fine-grained control over scopes and the JWT claims that carry roles. The practical OIDC setup steps for connecting an identity provider such as Okta follow the same configuration pattern regardless of which provider you choose. Whichever you use, the pattern is the same: the IdP authenticates the human and issues the scoped, audience-bound token; the MCP server only validates and enforces.

The hard problems: confused deputy and token passthrough

The reason MCP identity gets its own discipline, rather than just reusing API keys, is a specific class of failure: the confused deputy. A confused deputy is a privilege-escalation flaw where a trusted component (the MCP server) is tricked into using its own higher privileges to do something the requester was never authorized to do.

The classic trigger is token passthrough: an MCP server receives a user's token and forwards it unchanged to a downstream API. The MCP specification explicitly prohibits this, because the downstream API then sees the agent acting with the user's full identity and permissions rather than a narrowly scoped delegated authority. Instead, an MCP server must either use a token scoped to its own service identity or perform a distinct on-behalf-of (OBO) token exchange to obtain a narrowly scoped derived token for the downstream call.

Two related realities make this worse if ignored. First, MCP does not carry human user context from host to server by default, so a server only knows it received an authenticated JSON-RPC message, not whether the underlying instruction came from the user or from an injected payload. Second, that means a prompt-injection attack can cause tool calls that the human never intended. Both are why identity, scoping, and audit have to be enforced rigorously rather than assumed. For the broader attack surface, see our coverage of MCP security risks and MCP tool poisoning.

Where to enforce MCP identity: the gateway

Implementing OAuth 2.1, token validation, scope checks, OBO exchanges, and audit correctly inside every individual MCP server does not scale, and it invites inconsistency. That is where the MCP gateway comes in, sometimes called an MCP proxy or control plane. The gateway sits in front of your MCP servers and acts as the identity broker and policy enforcement point: it authenticates the human against your IdP, issues or exchanges scoped tokens, applies per-tool authorization policy, and produces a single, consistent audit trail of who called what. This is also where you connect MCP identity to the rest of your enterprise MCP platform and agent governance program.

Challenges and mistakes to avoid

• One shared credential for everything. A single API key or service account collapses the three-party model and maximizes blast radius.
• Token passthrough. Forwarding the user's token downstream creates a confused deputy; use OBO derived tokens instead.
• Over-broad scopes. Granting * or coarse scopes defeats least privilege.
• Skipping the audience check. Failing to verify the aud claim allows tokens minted for other services to be replayed.
• Per-server identity logic. Re-implementing auth in each server leads to drift and gaps; enforce centrally.
• Ignoring agent identity. Treating the agent as invisible removes any way to attribute or revoke its actions.
• No audit trail. Without a recorded delegation chain you cannot investigate or prove compliance.

MCP identity best practices

• Authenticate humans through your enterprise IdP using OAuth 2.1 and OIDC, reusing existing SSO and MFA.
• Use on-behalf-of (OBO) derived tokens for downstream calls; never pass the user's token through.
• Define granular per-tool scopes and grant only what each task needs.
• Verify the token signature, expiry, and aud claim on every request.
• Layer RBAC on top of scopes so permissions are managed at human and agent scale.
• Enforce identity centrally at an MCP gateway so policy and audit are consistent.
• Give each agent its own distinguishable identity, typically via scoped machine-to-machine tokens, so its actions can be attributed and revoked.
• Log the full delegation chain (human, agent, server, tool) for audit and compliance.

MCP identity vs traditional API authentication

It helps to see exactly how MCP identity differs from the API-key model many teams reach for first.

Dimension	Traditional API key / service account	MCP identity (delegated)
Parties represented	One (the application)	Three (human, agent, server/tool)
Whose authority is used	The key's full, static authority	The human's, narrowed by scope and delegation
Granularity	Usually all-or-nothing	Per-tool scopes and roles
Lifetime	Long-lived, rarely rotated	Short-lived, audience-bound tokens
Revocation	Manual, coarse	Via IdP lifecycle, immediate
Auditability	"The key did it"	Full delegation chain

MCP identity implementation checklist

1. Choose your enterprise IdP as the authorization server (Okta, Entra, Auth0, Keycloak, or equivalent).
2. Make each MCP server an OAuth 2.1 Resource Server that requires a valid token.
3. Publish Protected Resource Metadata (RFC 9728) at /.well-known/oauth-protected-resource.
4. Require Resource Indicators (RFC 8707) and verify the aud claim on every request.
5. Decide your client-registration policy: gated DCR (RFC 7591) or CIMD.
6. Define per-tool scopes and map them to RBAC roles via token claims.
7. Replace any token passthrough with on-behalf-of token exchange.
8. Front your servers with an MCP gateway as the central enforcement and audit point.
9. Log the full delegation chain and feed it into your monitoring and compliance program.

Frequently asked questions

What is MCP identity? MCP identity is the authentication and authorization layer of a Model Context Protocol deployment. It establishes who the human behind a request is, which agent is acting on their behalf, and what that agent is allowed to do on a given MCP server and tool.

What is the difference between MCP authentication and authorization? Authentication proves identity, usually by validating an OAuth 2.1 access token. Authorization decides what that identity may do, by checking the token's scopes and roles against per-tool policy. A secure MCP server does both.

Does MCP use OAuth, and which version? Yes. The current specification builds MCP identity on OAuth 2.1, with the MCP server acting as a Resource Server and a separate authorization server issuing tokens. OpenID Connect and PKCE are used alongside it.

What is an MCP Resource Server vs Authorization Server? The MCP server is the OAuth Resource Server that validates tokens and enforces access. The Authorization Server is the component, typically your IdP, that authenticates the user and issues the access token.

Is Dynamic Client Registration required for MCP? No. DCR (RFC 7591) is optional. It is useful when clients encounter servers they have not been pre-provisioned for, but many enterprises gate it for security or use Client ID Metadata Documents instead.

Can I use Okta or Microsoft Entra for MCP SSO? Yes. Okta, Microsoft Entra, Auth0, and Keycloak can all act as the authorization server for MCP, letting you reuse existing SSO and MFA and govern agent access with your standard identity lifecycle.

What is the confused deputy problem in MCP, and why is token passthrough banned? A confused deputy is when the MCP server is tricked into using its own higher privileges on behalf of an under-privileged requester. Forwarding the user's token unchanged to downstream APIs causes exactly this, so the spec prohibits token passthrough and calls for on-behalf-of derived tokens instead.

How do you enforce least privilege for MCP tools? Define granular scopes per tool, grant only the scopes a task needs, map scopes to RBAC roles, and check the required scope on every individual tool call.

Should MCP identity be enforced in each server or at a gateway? Centralizing enforcement at an MCP gateway is the more scalable and consistent approach. It keeps authentication, authorization, OBO exchange, and audit uniform across all your MCP servers.

How do you give an AI agent its own identity? Issue the agent a distinct, scoped identity (rather than reusing a human or shared credential), bind tokens to it, and record it in the delegation chain so its actions can be attributed and revoked independently.

Related MCP resources

• Model Context Protocol: the complete guide - what MCP is and how it works.
• MCP servers guide - how MCP servers are built, deployed, and secured.
• MCP gateway - centralizing identity, policy, and audit at the gateway.
• MCP security - the broader MCP security model and best practices.
• MCP security risks - the MCP threat landscape.
• MCP tool poisoning - tool-description poisoning and related attacks.
• MCP platform - running and governing MCP at enterprise scale.
• AI agent governance - governing what agents are allowed to do.

Bringing MCP identity into production

MCP identity is the foundation of safe agentic AI: get the three-party delegation model right and least privilege, audit, and compliance follow; get it wrong and a single shared credential becomes your largest attack surface. If you are operationalizing this, see how Agen.co secures AI agent access across your workforce, so your agents authenticate through the identity infrastructure you already trust and act only within the permissions you grant.