Authorization and Security
When Auth Applies
The moment a server is remote, anyone who can reach its URL can attempt to use it — so authorization matters. MCP's authorization spec applies at the transport level, specifically for HTTP-based transports. It is optional overall, but if you support auth over HTTP you should follow the spec. Importantly: stdio servers do NOT use this flow — they retrieve credentials from the environment instead, because they're local subprocesses.
| Transport | Authorization approach |
|---|---|
| stdio (local) | Read credentials from the environment (env vars) — the OAuth flow does not apply |
| Streamable HTTP (remote) | OAuth 2.1 flow per the MCP authorization spec (when auth is used) |
Auth is an HTTP-transport concern. Local stdio servers use environment credentials.
OAuth 2.1 and the Roles
MCP authorization is based on OAuth 2.1 (with related standards for metadata and dynamic client registration). The roles map cleanly: a protected MCP server acts as an OAuth 2.1 resource server; the MCP client acts as the OAuth client making requests on behalf of the user; and a separate authorization server handles the user login and issues access tokens. The MCP server validates those tokens — it doesn't issue them.
The client gets a 401 with metadata, runs the OAuth 2.1 flow against the authorization server, then calls the MCP server with a bearer token.
The Non-Negotiable Security Rules
A handful of requirements protect against real, named attacks. These are the ones to remember — they're high-yield both in practice and on the exam:
- 1.Validate token audience: the server MUST verify each token was issued specifically for it. Accepting tokens meant for another service breaks a core OAuth boundary.
- 2.No token passthrough: the server MUST NOT forward a client's token to a downstream API. If it calls an upstream service, it uses its own separate token. Passthrough enables the 'confused deputy' attack.
- 3.Use PKCE: clients MUST use PKCE to prevent authorization-code interception/injection.
- 4.Bearer tokens in the header only: tokens go in the Authorization: Bearer header on every request — never in the URL query string.
- 5.HTTPS everywhere + exact redirect URIs: all auth endpoints over HTTPS; redirect URIs validated against pre-registered exact values.
Token passthrough is explicitly forbidden
This is the single most emphasized rule. An MCP server must validate that a token was issued for IT, and must never pass a received token through to a downstream API. Violating this causes the confused-deputy vulnerability, where a downstream service wrongly trusts a token it shouldn't.
Beyond Tokens: General Hardening
Auth gets a token in the door, but the broader MCP threat model still applies. Because tools take real actions and servers can be third-party code, layer in defense-in-depth:
- •Treat tool inputs/outputs as untrusted; validate and sanitize them.
- •Apply least privilege — give a server only the access it genuinely needs.
- •Keep human approval on high-stakes, model-controlled tool calls (refunds, deletes, transfers).
- •Use short-lived access tokens and rotate refresh tokens to limit blast radius if one leaks.
- •Prefer official or audited servers; a malicious server is code running with whatever access you grant it.
Next
You can now secure a remote server. Next we look at MCP from the user's side — how servers plug into Claude Desktop and Claude Code, and how to configure them.
Key Takeaways
- ✓MCP authorization applies at the transport level for HTTP-based transports and is optional; stdio servers instead read credentials from the environment.
- ✓It is based on OAuth 2.1: the MCP server is the resource server, the client is the OAuth client, and a separate authorization server issues access tokens.
- ✓The server validates tokens (via a 401 + metadata discovery flow) — it does not issue them.
- ✓Two cardinal rules: validate token audience (the token was issued for THIS server) and never pass a client's token through to a downstream API (prevents the confused-deputy attack).
- ✓Clients MUST use PKCE; tokens go only in the Authorization: Bearer header (never the URL); all endpoints over HTTPS with exact-match redirect URIs.
- ✓Layer defense-in-depth: validate tool I/O, least privilege, human approval for high-stakes tools, short-lived/rotated tokens, and prefer audited servers.
Check Your Understanding
Test what you learned in this lesson.
Q1.Which transport does MCP's authorization specification apply to?
Q2.In MCP's OAuth 2.1 model, what role does the MCP server play?
Q3.Why must an MCP server never pass a received token through to a downstream API?
Q4.Which of these is a required client-side protection in MCP authorization?
Practice This Lesson