Identity and access guide
How to secure MCP access with OAuth and explicit entity binding
Secure MCP access by authenticating the caller, binding that identity to the correct customer or workspace, issuing only the scopes required for one workflow, and checking authorization again when each tool executes. Keep secrets server-side, separate reads from writes, and record decisions without exposing tokens or sensitive payloads.
- Good fit
- Use delegated OAuth when a person or customer must authorize access to their own third-party account and the runtime needs revocable, scoped credentials tied to that identity.
- Pause when
- Do not force user OAuth onto a service-owned batch process with no user delegation, and do not use a shared static bearer token as a substitute for tenant-aware authorization.
Signals this guide applies
- The same MCP endpoint serves more than one user, client, workspace, or data boundary.
- A provider connection can be valid while still belonging to the wrong entity inside the broker.
- Operators need to revoke access or explain which scopes and identity authorized a tool call.
A bounded way to proceed
- 01
Model identities and entities
Document the person, application, provider account, customer tenant, and internal workspace identifiers. Define which mapping is authoritative and reject connections that authenticate successfully but cannot be bound to the requested entity.
- 02
Request minimal scopes
Map each resource and tool to provider scopes and begin read-only where possible. Explain the requested access in user-facing language, and require a new consent path before adding permissions rather than silently broadening an existing grant.
- 03
Enforce at execution
Validate token audience, issuer, expiry, connection status, entity binding, role, tool policy, and approval state close to the action. Never rely solely on a successful login or on instructions inside the model context.
- 04
Protect and revoke
Store credentials in an approved secret boundary, redact logs, rotate service secrets, support user disconnect, and test provider revocation. Preserve identifiers and outcomes needed for audit without retaining unnecessary sensitive content.
Artifacts an operator can inspect
Identity binding record
The record connects internal user and tenant identifiers to the provider account and authorization grant, with status, timestamps, and revocation state.
Scope-to-tool matrix
Each exposed operation lists its provider scopes, internal role, approval need, data sensitivity, and response redaction rules.
Access audit receipt
A safe receipt captures caller, tenant, policy version, connection identifier, tool, decision, and result status while excluding bearer credentials and private bodies.
Questions operators ask
Does OAuth make an MCP server secure by itself?
No. OAuth can establish delegated access, but the server must still validate tokens, bind the right tenant, enforce tool-specific policy, protect secrets, limit data, handle revocation, and preserve evidence for each action.
Why can an MCP connection succeed for the wrong user?
Authentication may prove control of a provider account while the broker or application maps that grant to the wrong internal user or workspace. Verify the full identity chain and entity identifiers before changing scopes or tool code.
When is a static bearer token acceptable for MCP access?
It can be appropriate for a tightly bounded service-to-service control with secure storage, rotation, narrow policy, and no need for user delegation. It should not impersonate multiple customers or replace revocable per-user authorization.