Learn MCP - Authorization (OAuth 2.1) & Security

#Introduction

Episode 9 deployed the MCP server to HTTP and unlocked horizontal scaling. But a public endpoint without authentication is an open door — anyone can call your tools, including dangerous ones. This episode closes that gap with OAuth 2.1 Authorization plus the security practices you must understand before a server touches production.

Roadmap: understand the two main roles (resource server and authorization server), the authorization code flow with PKCE, the use of the Mcp-Authorization header and refresh tokens, step-up authorization with scope accumulation, DPoP bound tokens, then SSRF and CRLF mitigation on server URLs.

#Two Roles: Resource Server and Authorization Server

OAuth 2.1 divides responsibility between two entities:

• Authorization server — the identity that holds user credentials and issues tokens. Examples: Auth0, Keycloak, or a self-hosted implementation. It also manages consent — the user's approval of specific scopes.
• Resource server — the entity that protects data/actions and validates tokens. In our case, this is the MCP server itself. It checks the token's signature, expiry, and scopes before allowing a request.

The common flow: the host application directs the user to the authorization server to log in, obtains an authorization code, then exchanges it for an access token. This token is then sent to the MCP server on every request. The MCP server doesn't need to understand the user's password — it just validates the token it receives.

#Authorization Code Flow with PKCE

The flow recommended by OAuth 2.1 is Authorization Code + PKCE. Before directing the user, the application creates a code_verifier (a random string) and a code_challenge (its hash). After the user logs in and approves the scopes, the authorization server returns a code; the application exchanges it for a token while sending the code_verifier as proof of possession.

curl -X POST https://auth.example.com/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=authorization_code" \
  --data-urlencode "code=abc123" \
  --data-urlencode "redirect_uri=https://host.example.com/callback" \
  --data-urlencode "code_verifier=verifier-rahasia"

PKCE prevents authorization code interception attacks: without the correct code_verifier, a stolen code can't be exchanged for a token. Replay attacks are also mitigated because every code is valid only once and is very short-lived.

#The Mcp-Authorization Header and Refresh Tokens

Once you have an access token, every request to the MCP server carries the token in the Mcp-Authorization header:

curl https://mcp.example.com/mcp \
  -H "Content-Type: application/json" \
  -H "Mcp-Authorization: Bearer access-token-123" \
  --data '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Mcp-Authorization is the MCP-specific header read by the resource server to extract the token — its separation from regular Authorization prevents conflicts when MCP is embedded in an application that already uses OAuth for its own API.

Access tokens are usually short-lived (e.g. 15 minutes). When one expires, the application doesn't need to force the user to log in again — it just exchanges a valid refresh token for a new access token. The refresh token is stored securely by the host application and rotated each time it's used; never expose it to the resource server.

#Step-Up Auth with Scope Accumulation

Sometimes a request needs a higher permission than what was already approved — for example transfer-funds may only be executed after the user reconfirms. OAuth 2.1 handles this via scope accumulation: the application submits an additional authorization request with more specific scopes, the user approves, and the new token combines the old scopes with the new ones.

This step-up pairs perfectly with MRTR from episode 8: when the MCP server replies pending because it needs additional permission, the host runs the OAuth step-up flow, then continues the request with the same messageId and a new token. The user experience: a single "allow fund transfer" dialog appears exactly when needed — not at the start of the session.

#Bound Tokens and DPoP

Plain (bearer) tokens are "whoever holds them uses them" — if a token leaks in logs or a proxy, an attacker can use it. Bound tokens (e.g. via DPoP, RFC 9449) bind the token to a public key owned by the client: every request must include proof of possession of the matching private key, so a stolen token without the private key is useless.

const headers = {
  Authorization: `DPoP ${accessToken}`,
  DPoP: dpopProof,
};

dpopProof is a JWS signing the combination of the HTTP method, URL, and a random jti. DPoP significantly raises the security bar for tokens passing through many hops. For production MCP servers handling sensitive data, it's worth making a requirement.

#SSRF and CRLF Mitigation on Server URLs

An MCP server that accepts URLs from users — for example a "fetch page" tool — is vulnerable to SSRF (Server-Side Request Forgery): an attacker tells the server to access localhost or internal metadata services. Validate strictly before connecting:

function sanitizeUrl(raw: string): string {
  const url = new URL(raw);
  if (url.protocol !== "https:") {
    throw new Error("Hanya URL https yang diizinkan");
  }
  if (/[\r\n]/.test(raw) || /%0d|%0a/i.test(raw)) {
    throw new Error("CRLF terdeteksi pada URL");
  }
  return url.toString();
}

new URL(raw) parses the input into separate components, making validation easier. Protections to put in place:

• Protocol allowlist: only https, reject http and other schemes.
• Block internal IPs: reject localhost, private ranges (e.g. 10.x, 172.16-31.x, 192.168.x), and link-local.
• Clean CRLF: make sure users can't slip in \r\n characters (or %0d/%0a encodings) for HTTP header injection.
• One level further: if possible, use an isolated outbound proxy for tool-triggered requests.

#Conclusion

Episode 10 closes the access security side: the OAuth 2.1 model with resource server and authorization server separation, the PKCE flow, the Mcp-Authorization header, refresh tokens, scope accumulation for step-up auth, bound tokens/DPoP, and SSRF and CRLF mitigation.

Key takeaways:

• Separate the roles: the authorization server issues tokens, the MCP server only validates them.
• PKCE is mandatory in the authorization code flow for public applications.
• Short access tokens, long rotated refresh tokens — and never leak them to the resource server.
• Step-up auth combined with MRTR grants permission exactly when needed.
• Validate tool URLs with a protocol allowlist, internal IP blocking, and CRLF sanitization.
• Never put secrets in logs: tokens, authorization codes, and the code_verifier must always be filtered from logging output.

In the next episode 11 we explore the official MCP Apps & UI Resources extension — tools that don't just return text, but also interactive interfaces rendered by the host in a sandboxed iframe. See you there!