In brief: MCP apps use one of three auth patterns: OAuth 2.1 with PKCE (mandated by the MCP spec for remote servers, used by Claude, Gemini, modern ChatGPT), API key handoff (common in Cursor and AI-first IDEs, weak on revocation and scoping), and enterprise SSO via the host's identity provider (Microsoft Copilot delegates to Entra ID; Gemini to Google OAuth). The MCP spec mandates Dynamic Client Registration (RFC 7591) and authorization server metadata discovery (RFC 8414). For enterprise readiness: OAuth 2.1 + PKCE, scopes structured per-resource and per-verb and per-sensitivity, bounded token lifetimes (≤1 hour) with transparent refresh and immediate revocation, customer-facing audit logs, and SSO support for Entra ID, Okta, and Google Workspace.
The fastest way to lose an enterprise procurement conversation about an MCP app is to lose the auth conversation. Security teams have spent a decade getting good at evaluating OAuth implementations, scope design, and audit posture in third-party SaaS, and they apply the same lens to MCP – with the added question of how a non-human agent's behavior is bounded inside the granted permissions. A sloppy auth story is read, correctly, as a sloppy product. A clean one is the floor that lets the rest of the conversation happen.
The MCP specification mandates OAuth 2.1 with PKCE for remote servers, plus Dynamic Client Registration (RFC 7591) and Authorization Server Metadata (RFC 8414). The spec recommends Resource Indicators (RFC 8707) to prevent token-confusion attacks. For enterprise readiness, scopes should be structured per-resource, per-verb, per-sensitivity, with bounded token lifetimes, immediate revocation, customer-facing audit logs, and SSO support for the major identity providers. This guide walks each piece of that bar in detail.
This guide assumes the working vocabulary in our MCP terminology guide and the level distinctions in MCP embedding types.
Auth Design Is Product Strategy
Auth design is not engineering plumbing. It determines who can install you (which clients accept your auth model), what an agent can do at runtime (coarse vs fine scopes), and how procurement reacts (whether the design maps onto reviewers' existing OAuth review checklists). Treat it as a product decision; let engineering execute the design rather than choose it.
Three auth patterns dominate in 2026:
| Pattern | Where it's used | Strengths | Weaknesses |
|---|---|---|---|
| OAuth 2.1 with PKCE + DCR | Claude, Gemini, modern ChatGPT install paths | Cleanest model; per-tool consent possible; bounded token lifetimes; clean revocation; spec-compliant | Heavier to implement than API key |
| API key handoff | Cursor and AI-first IDEs; lightweight integrations | Cheap to implement; fast first-ship | Weak revocation; weak per-tool scoping; insufficient for enterprise; not spec-compliant for remote servers |
| Enterprise SSO via host IdP | Microsoft Copilot (Entra ID); Gemini (Google OAuth); Claude enterprise (SAML/SCIM) | Strongest procurement story; admin-controlled distribution; existing enterprise IT mental model | Heaviest implementation; per-client identity provider integration |
A serious MCP app shipping to multiple AI clients implements at least two of these, and probably all three. There is no shortcut. The cost of pretending one auth model fits all clients is shipping to fewer of them than your strategy intended.
OAuth 2.1 with PKCE (Proof Key for Code Exchange) is the auth pattern mandated by the MCP spec for remote servers. The user is taken through a standard OAuth flow inside the AI client, grants scopes, and the client receives an access token plus a refresh token bound to the user. PKCE protects the public-client flow against authorization code interception attacks.
/.well-known/oauth-authorization-server metadata document (RFC 8414) to discover the authorization endpoint, token endpoint, supported scopes, supported grant types, and registration endpoint.client_id and (for confidential clients) a client_secret. response_type=code, code_challenge, code_challenge_method=S256, and the requested scopes. Authorization: Bearer ... header on JSON-RPC requests to your MCP server.
OAuth 2.1 + PKCE + DCR is the right default for any MCP app shipping to spec-compliant clients (Claude, Gemini, modern ChatGPT). For enterprise tier on Claude or for Microsoft Copilot, you additionally need to support SAML and SCIM.
Each AI client implements auth differently, with the standing caveat that any specific claim should be verified against current documentation:
| Client | Primary auth | DCR | RFC 8414 | Scope granularity | Notable |
|---|---|---|---|---|---|
| Claude | OAuth 2.1 + PKCE | Yes (mandatory) | Yes | Per-tool consent at install; per-action confirmation | Strongest spec compliance; enterprise tier adds SAML/SCIM |
| ChatGPT | OAuth or API key | Partial | Partial | App-level; per-tool on newer builds | Verify install path before designing scopes |
| Cursor + IDEs | API key dominant; OAuth on remote | Limited | Limited | Permissive; per-server consent | Mature OAuth here is a differentiator |
| Microsoft Copilot | Entra ID | N/A (Entra) | N/A | Admin-granted org-level | Heaviest implementation; strongest procurement story |
| Gemini | Google OAuth | N/A (Google) | N/A | Google's standard scope model | Familiar to enterprise IT |
The practical implication: an MCP app shipping to Claude needs full DCR + RFC 8414 metadata support from day one. A multi-client MCP app needs all three patterns from day one. Greenfielding for a single auth model is fast and is also the most common reason teams cannot ship to client number two without a substantial rebuild six months later.
The most common scope mistake is the binary scope: access your data. This is what API-key-era integrations defaulted to, and it is what enterprise procurement now reflexively pushes back on. The fault lines that produce a defensible scope taxonomy:
tickets:read and tickets:write should be distinct scopes; the user should be able to grant one without the other.tickets:delete. customers:write should be distinct from customers:export. Anything that exfiltrates data or causes irreversible state change deserves its own scope.
A representative scope structure for a mid-complexity B2B SaaS MCP app:
crm:customers:read
crm:customers:write
crm:customers:delete
crm:customers:export
crm:customers:merge // irreversible
crm:deals:read
crm:deals:write
crm:deals:delete
crm:deals:export
crm:deals:close // mark won/lost; high-stakes
crm:contacts:read
crm:contacts:write
crm:contacts:delete
crm:contacts:export
crm:contacts:bulk_email // rate-limited; high-stakes
crm:notes:read
crm:notes:write
crm:settings:read
crm:settings:write // org-level; admin-only
crm:billing:read
crm:billing:write
The taxonomy reflects that delete, export, merge, close, bulk_email, and settings:write are higher-blast-radius than the routine read/write scopes. Procurement teams reviewing this scope list can immediately see what is at stake and which scopes need additional admin approval.
The cost of fine-grained scopes is install-time UX (longer consent screens, more questions). The benefit is two-fold: enterprise procurement moves faster because the scopes map onto reviewers' existing mental models, and the blast radius of any individual mistake is smaller. Most products should err toward fine.
Short-lived access tokens (1 hour or less) with refresh tokens are the right default. Permanent tokens are a procurement red flag.
| Token type | Recommended lifetime |
|---|---|
| Access token (routine scopes) | 30–60 minutes |
| Access token (high-sensitivity scopes) | 15 minutes |
| Refresh token | 30–90 days |
| Re-consent prompt cadence | 90 days for high-stakes scopes |
Refresh should be transparent to the agent and visible to the user. Silent refresh that never surfaces to the user is acceptable for short windows; refresh that extends access indefinitely without re-prompting is not.
Opaque access tokens are the safer default for most MCP apps. Opaque tokens require a database lookup on every request, which gives you immediate revocation – the moment you delete the token from your store, requests using it fail. JWTs are stateless (operationally appealing) but cannot be revoked before they expire without a separate revocation list, which negates most of the JWT advantage.
If you use JWTs, recommended claims include sub (user ID), aud (your MCP server resource indicator), iss (your authorization server), exp (expiration), iat (issued at), client_id (the AI client), scope (granted scopes), and session_id (for cross-call session reconstruction).
Three actors must be able to revoke MCP app access at any time:
Revocation must be effective immediately, not at next token rotation. Many MCP apps have a stated revocation path that, when exercised, leaves stale tokens working for hours. Test this. The gap between policy and practice is the gap that matters when an incident is live.
Every action the agent takes through your MCP app should be auditable. The minimum bar:
The reason this matters is procedural rather than technical. When something goes wrong – and at least once a year, for any MCP app touching real data, it will – the question what did the agent do is a customer-facing, sometimes legally meaningful question. A team that can answer it in five minutes from a query against the audit log keeps the customer. A team that says we'd have to reconstruct from individual logs, give us a few days loses them.
Common Failure Mode
Audit logs have become the highest-leverage feature for enterprise close rates we have observed in MCP apps shipped over the past year. The most common failure pattern at level 2 is a team that built the log internally and never exposed it to customer admins – the audit exists technically and not procedurally, which is worse than not having it because it produces false confidence. Build the log on day one. Surface it to the customer's admin console, even minimally, by month three.
For SOC 2 Type II–compliant environments, the audit log additionally needs tamper-evident storage (append-only log; cryptographic hashing or chained hashing across entries), retention aligned with customer's data retention requirements (typically 1–7 years), and access controls on the log itself.
MCP apps shipping into enterprise commonly need SOC 2 Type II attestation. The mapping of MCP-specific security work to SOC 2 trust services criteria:
| SOC 2 Criterion | What it requires | MCP-specific evidence |
|---|---|---|
| CC6.1 Logical access controls | Restrict access to information and IT systems | OAuth scopes; per-tool consent; revocation procedures |
| CC6.2 New users, periodic review | Onboard/offboard with appropriate access | Token lifecycle; consent re-prompts; revocation logs |
| CC6.3 Access provisioning | Grant access based on role | Scope taxonomy; admin-vs-user scope distinctions |
| CC6.6 Encrypted transmission | Encrypt data in transit | TLS for all MCP transport; bearer tokens in HTTPS only |
| CC6.7 Restrict transmission of information | Restrict data movement to authorized parties | Resource indicators; scope-based data access |
| CC7.2 System monitoring | Monitor for security events | Audit log; anomaly detection on tool invocation patterns |
| CC7.3 Incident response | Detect and respond to incidents | Revocation procedures; audit forensics; communication plan |
For most MCP apps the auth and audit work above maps cleanly onto SOC 2 controls. The work to add for SOC 2 compliance specifically is the documentation, evidence collection, and audit by a third-party assessor – typically 6–9 months and $50K–$150K for first-time SOC 2 Type II attestation. That attestation is part of the true cost of shipping to enterprise clients; auth complexity is one of the five drivers in what an MCP server costs to build.
A working threat model for MCP apps shipping in 2026:
| Threat | Likelihood | Mitigation |
|---|---|---|
| Token theft via AI client compromise | Low–medium | Short-lived access tokens; immediate revocation; bind tokens to client_id and resource indicator |
| Scope sprawl (user grants too much at install) | High | Fine-grained scopes; clear consent UI; per-tool consent where supported |
| Confused-deputy attack | Medium | Treat agent inputs as untrusted; validate parameters server-side; never trust the agent's framing of user intent |
| Prompt injection causing unintended tool invocation | Medium–high | Intent-preview UI; high-stakes scopes require user confirmation per-action; rate limits |
| Replay attack (token replayed against different MCP server) | Low–medium | RFC 8707 Resource Indicators; bind tokens to specific MCP server identity |
| OAuth client impersonation | Low | Strict redirect URI validation; PKCE; verify client_id matches registered client |
| Audit log gap | High | Per-invocation logging from day one; expose to customer admins; tamper-evident storage |
| Stale revocation (revoked tokens still working) | High | Test revocation latency; use opaque tokens; if JWTs, maintain revocation list |
| Privilege escalation via scope inheritance | Medium | No scope inheritance; explicit grants per scope; admin scopes require step-up auth |
The two threats most often missed in initial designs are the confused-deputy attack and prompt injection. Both arise from the agent acting on parameters or framing it received from an untrusted source. Server-side validation of every parameter – not trusting the agent's interpretation of intent – is the primary defense.
If you are selling into enterprise, the auth and security shape of your MCP app needs to clear this bar before procurement begins, not during it:
The two items teams routinely think they have and don't are the customer-facing audit log surface and the SCIM provisioning. Both are pre-procurement work, not post-. Both consistently get pushed past the first ship and consistently delay the first enterprise close by a quarter.
Pre-Procurement Diligence Questions
If a customer's security team asks you these questions and you cannot answer with documented evidence, you have work to do before procurement. Walk through your auth design. Show the scope taxonomy. Demonstrate revocation latency end-to-end. Pull a sample audit log entry. Demonstrate the customer-admin audit surface. Walk through your SOC 2 control mapping. Each of these is a question security teams know how to ask in their sleep – and treating any of them as "we'll figure that out after we close the deal" is how the deal stops closing.
Three patterns recur in MCP auth implementations that teams later regret:
Two additional mistakes worth naming:
Auth and security choices interact tightly with embedding depth (MCP embedding types) and the build-vs-buy decision (MCP build vs buy). Get the auth right and the rest of the work has somewhere to land.
Does MCP use OAuth?
Yes – the MCP specification mandates OAuth 2.1 with PKCE for remote MCP servers, plus Dynamic Client Registration (RFC 7591) and Authorization Server Metadata (RFC 8414). API keys are still common in local-server contexts (Cursor, AI-first IDEs) but are not spec-compliant for remote MCP servers in 2026.
What scopes should my MCP app request?
Request scopes per-resource, per-verb, per-sensitivity. A CRM MCP app should have separate scopes for customers:read, customers:write, customers:delete, customers:export, and customers:merge rather than a single crm:access scope. Fine-grained scopes are slower at install but faster through procurement.
Is MCP HIPAA / SOC 2 compliant?
The MCP protocol itself is not certified for any compliance regime; certification applies to your MCP app's implementation. To meet HIPAA, SOC 2, GDPR, or other regimes, your MCP app's auth, audit, encryption, and data handling must meet the regime's requirements. Most enterprise-grade MCP apps in 2026 hold SOC 2 Type II.
Can I use API keys for my MCP app?
You can, but only for clients that support API key install (primarily Cursor and AI-first IDEs running local servers). API keys are not spec-compliant for remote MCP servers and are insufficient for enterprise procurement. For OAuth-supporting clients with remote-server requirements, OAuth 2.1 + PKCE + DCR is the right choice.
What is Dynamic Client Registration in MCP?
Dynamic Client Registration (RFC 7591) is the OAuth feature that lets an AI client register itself with your authorization server programmatically, rather than requiring you to manually provision a client_id for each AI client. The MCP spec mandates DCR for spec-compliant remote servers. Without DCR, you cannot ship a generally-installable MCP app to clients like Claude that expect spec compliance.
How do I revoke access to my MCP app?
Three revocation paths must work: user-initiated (through the AI client's connector management), admin-initiated (through the customer's identity provider for enterprise installs), and service-initiated (through your own admin tools). All three should be effective immediately; verify this works in practice.
What is per-tool consent in MCP?
Per-tool consent is a UX pattern where, at install, the user sees a list of the specific tools the MCP app exposes (create_ticket, delete_customer, etc.) and can grant or deny access to individual tools. Claude has the strongest per-tool consent UX in 2026; other clients are less granular.
How often should MCP tokens be refreshed?
Access tokens should expire within 30–60 minutes (15 minutes for high-sensitivity scopes); refresh tokens within 30–90 days. Re-consent prompts every 90 days are appropriate for high-stakes scopes; lower-stakes scopes can run longer between re-consents.
Does MCP work with SSO?
Yes, for clients that support enterprise SSO. Microsoft Copilot delegates to Entra ID; Gemini to Google OAuth; Claude's enterprise tier supports SAML and SCIM. Enterprise MCP app sales typically require SSO support for the major IdPs.
Should I use JWTs or opaque tokens?
Opaque tokens are the safer default for most MCP apps because they support immediate revocation. Use JWTs only when token lifetimes are very short (≤5 minutes) or when you have a specific high-throughput need and have built a JWT revocation list.
What is RFC 8707 (Resource Indicators) in MCP?
Resource Indicators is an OAuth extension that binds a token to a specific resource – in MCP's case, your MCP server's identity. Without resource indicators, a token issued for one MCP server could be replayed against another, causing a token-confusion attack. The MCP spec recommends RFC 8707; spec-compliant clients enforce it.
Originally published at launchdayadvisors.com. Launch Day Advisors is a buyer-side advisory firm: we help companies select AI, software, and design partners, and we are paid only by the buyer.