What is MCP and how does it work?

We’re here today to look MCP through the lens of identities and access. But first, let’s align on the basics. And since we’re going to be talking about Anthropic’s standard, we’ll let their AI generate this next paragraph:

‍MCP (the Model Context Protocol) is an open standard that lets AI applications connect to outside tools and data through one common interface. Anthropic released it in November 2024; OpenAI, Google, and Microsoft adopted it within a year, and it is now the default way agents reach the systems where work happens: code repositories, databases, ticketing queues, chat platforms. The standard analogy calls it USB-C for AI, and the analogy holds as far as it goes: it describes the connector. It says nothing about what passes through the connector, and what passes through, at every point in an MCP architecture, is a credential.

We’ll be following connectivity options to trace the authentication flow and help you understand the identity layer of MCP with a security lens in mind. 

‍Option 1: No auth, local/stdio servers

For local servers (stdio transport), the spec explicitly says don't use the HTTP authorization flow, pull credentials from the environment instead (env vars, OS keychain, local config). Identity here is whatever OS-level user context the process runs under. This is fine for a developer's laptop running a local MCP server, but it's not a model for anything enterprise-facing: there’s no delegation, no scoping, and no audit trail beyond process logs.

Security lens: 

Detect it: consider an AI security tool that has an endpoint client for visibility and the capability to detect hidden MCP servers and any stored hardcoded secrets.

The fix: move credentials off the endpoint, shift to remote MCP server where possible. Where a local server is the only current option, consider the proxy pattern. A central proxy\credential broker (infrastructure, not something living on the laptop) holds the actual credential and injects it on the outbound call. This can be done for stdio servers too, by routing the local subprocess's traffic through an OS-level local proxy that hands off to the credential broker.

Option 2: OAuth 2.1 delegated authorization (the standard for remote/HTTP MCP)

For remote servers, MCP standardizes on OAuth 2.1 with a specific profile:

• The MCP server acts as an OAuth 2.1 resource server
• A separate (or co-located) authorization server issues tokens — this is where you'd plug in your actual IdP (Entra ID, Okta, Auth0)
• The client discovers the auth server via metadata, redirects the user through a browser consent flow, and gets back a scoped bearer token

Security lens:

One risk here is token passthrough: a client taking a token meant for Server A and replaying it against Server B. RFC 8707 addresses this by binding the token to a specific server (the "audience"). 

Detect it: gate the audience-binding test into connector onboarding, and re-run it on a cadence (quarterly, or on vendor version bumps), treat it like you'd treat periodic pen-testing of an API endpoint, not a one-time approval checkbox. Vendor questionnaire answers on "do you support RFC 8707" are a starting point, not a substitute for the detection test.

The fix: require the MCP server to validate token audience, rejecting any token whose aud isn’t its own, and make RFC 8707 resource-parameter support a hard onboarding requirement, not a checkbox.

For a security team, this is the part to scrutinize per-vendor: does the server enforce audience binding, or does it accept any bearer token that looks valid? A lot of early implementations didn't. The current spec now makes both mandatory, clients MUST send the RFC 8707 resource parameter and servers MUST validate token audience, but enforcement still varies in practice, so verify it per vendor rather than assuming compliance.

Option 3: Enterprise identity broker pattern

The pattern most enterprises actually land on is:

• Your real IdP (Entra ID, Okta) sits behind the MCP authorization server
• End users authenticate once via your existing SSO
• The MCP layer issues short-lived, scoped tokens downstream
• Consent/authorization is per-connector, and ideally per-tool-scope, not blanket account access

Security lens:

This is the layer where you'd apply normal enterprise controls, conditional access policies, MFA requirements, session risk scoring, because the MCP auth flow is just another OAuth consent screen from the IdP's point of view.

Additional Considerations

Worth considering for your security team:

• Confused deputy / tool chaining: if an MCP server itself calls other services using a passed-through token, you need to verify it's not just forwarding the user's token as its own credential without re-scoping.
• No mandated token lifecycle: rotation, revocation, and replay protection are best-practice recommendations in some drafts, not spec requirements, so this varies by implementation and is worth putting in vendor security questionnaires or detecting during a connector review process. If you're doing rotating refresh tokens, each refresh should invalidate the old token and issue a new one from the same "family." The moment an already-consumed refresh token gets presented again, that's the compromise signal, it means two parties (the legitimate client and an attacker who captured the token earlier) both tried to use it. The correct response is to revoke the entire family, not just the reused token, forcing re-authentication of every session derived from it.
• Consent fatigue: the browser-based approval flow doesn't scale well when a user (or agent) is authorizing many servers/tools; the MCP roadmap itself acknowledges that authorization today is built around a person approving access in a browser and is actively being reworked. 

‍