Authentication and authorization for MCP are defined in the specification and expanded in official security docs. Product hosts may add API keys on top — label those separately.
Where to read the official rules
| Document | Role |
|---|---|
| Authorization — 2025-11-25 | Normative authorization for MCP (OAuth-oriented HTTP model) |
| Security Best Practices | Attacks and mitigations (confused deputy, token passthrough, SSRF, session hijacking, local compromise, …) |
| Understanding Authorization tutorial | Guided implementation tutorial |
| Architecture overview — transport layer | Notes Streamable HTTP + HTTP auth methods; recommends OAuth for tokens |
| Transports — 2025-11-25 | Streamable HTTP security warnings (Origin validation, localhost binding, authentication) |
Spec versions evolve (e.g. 2025-03-26, 2025-06-18, 2025-11-25). Cite and implement the version your client/server negotiate via lifecycle.
Transport matters
- stdio — typically same-machine subprocess; authorization model differs from public HTTP (see local server guidance in Security Best Practices).
- Streamable HTTP — independent remote process; the transports spec requires attention to Origin validation and authentication; architecture docs mention bearer tokens, API keys, custom headers, and recommend OAuth for obtaining tokens.
OAuth-oriented HTTP authorization (spec)
The current authorization specification frames MCP HTTP servers in the OAuth ecosystem (resource servers, metadata discovery, related RFCs). Implementers should follow MUST requirements on the live Authorization page rather than informal summaries.
Related extensions and guides on the official site include enterprise-managed authorization and client-credentials patterns under Authorization extensions.
Patterns (protocol vs product)
| Pattern | Typical use | Notes |
|---|---|---|
| OAuth 2.1 / resource metadata flows | User-delegated access to remote MCP over HTTP | Follow authorization spec + security best practices |
| HTTP bearer / API key headers | Service or team access over HTTP | Architecture overview lists these as HTTP auth methods; still validate audience/issuer if tokens are OAuth-shaped |
| No network auth | Localhost-only experiments | Do not expose powerful tools on the public internet without auth (transports security warning) |
| Platform deploy keys (e.g. MCPLambda auth types) | Who may call your deployment URL | Product feature — see AI clients and deploy settings |
Hard rules from official security docs
From Security Best Practices:
- No token passthrough — servers MUST NOT accept tokens not issued for that MCP server
- Confused deputy — MCP proxy servers that OAuth-proxy to third parties need per-client consent and strict redirect/state handling
- SSRF — clients fetching OAuth metadata URLs must treat malicious metadata as hostile (HTTPS, block private IPs, careful redirects)
- Session hijacking — if using Streamable HTTP sessions, session IDs are not authentication; bind sessions securely; verify authorization on every request
- Local servers — consent before executing one-click install commands; sandbox when possible; prefer stdio to limit exposure
From the Tools specification: human-in-the-loop SHOULD be able to deny tool invocations; servers MUST validate inputs, access-control, rate-limit, sanitize outputs.
Practical recommendations
- Internal company MCP over HTTPS → authenticated HTTP (keys or OAuth) + network controls
- Customer / multi-tenant product MCP → OAuth resource-server model per current spec; no shared god tokens
- Never log access tokens or dump secrets in tool results
- Prefer least privilege scopes (scope minimization section in security best practices)
MCPLambda product note
MCPLambda deploy configuration may offer auth modes such as OAuth, API key, or none for the deployment edge. That is how the platform gates your Deployment URL — still implement correct tool authorization inside the server, and do not confuse platform keys with upstream SaaS OAuth for third-party APIs.
Worked scenario: API key for services, OAuth for users
Internal automation uses a service API key on Streamable HTTP. Customer-facing product MCP uses OAuth so each end user grants scoped access. A third experiment tried “no auth on localhost bound to 0.0.0.0” and got scanned.
You document three patterns with explicit non-goals: no auth only on true loopback demos; never token passthrough; sessions are not authentication. Platform deploy keys (who may hit your deployment) stay distinct from upstream SaaS OAuth the tools use.
Checklist for this topic
- Pick OAuth vs API key based on user-delegated vs service access
- Implement Authorization spec requirements for HTTP OAuth
- Forbid token passthrough
- Authenticate remote powerful tools
- Separate edge auth from upstream credentials
- Rotate credentials on a schedule and on offboarding
Topic-specific failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Open internet, no auth | Demo defaults | Enforce auth |
| Passthrough tokens | Proxy anti-pattern | Audience-bound tokens only |
| Session = login | Misuse of MCP-Session-Id | Auth every request |
| One key forever | No rotation | Expiry + rotation policy |
Related guides
Securing remote · Security best practices · Authorization spec
Mapping patterns to scenarios
| Scenario | Pattern |
|---|---|
| CI bot calling MCP | API key / service credential |
| Employee using shared internal MCP | Per-user key or SSO-backed OAuth |
| End-customer agent product | OAuth resource server per current auth spec |
| Laptop-only experiment | stdio; avoid public bind |
When unsure, choose the stricter pattern for anything that can move money or personal data.
Sources
- Authorization — specification 2025-11-25
- Security Best Practices
- Understanding Authorization in MCP
- Architecture overview
- Transports — 2025-11-25
- Tools — security considerations
