OAuth for MCP: A Developer’s Guide to Secure Authentication

Modern LLM applications need secure, flexible authentication. MCP (Model Context Protocol) already provides a strong foundation for interactions between clients and servers. But when these applications need to connect with user accounts or enterprise systems, something more is required: a trusted way to handle access. That’s where OAuth 2.1 comes in.

This guide draws from Aaron Parecki’s talk at the MCP Summit and presents a hands-on view for developers, cutting through the typical OAuth jargon.

Why OAuth?

In the past, apps might ask you for your password to another service and then try to fetch data on your behalf. That approach is both insecure and unsustainable.

OAuth solves this by letting users grant access to an application without sharing passwords. Instead, the app receives a time-limited access token that can be used to fetch data securely.

Think of it like checking into a hotel: you don’t get access to the whole building, just a keycard to your room. OAuth tokens work the same way—limited, specific access, no need to understand how the whole system works.¹

Core OAuth Flow for MCP

In a typical setup, the following actors are involved:

MCP Client (e.g., a local LLM app like Claude Desktop)
OAuth Server (e.g., Okta)
MCP Server (e.g., a Slack or Google Drive connector)

Here’s what happens:

The user clicks “Connect Account” in the MCP client
The client redirects the user to the OAuth server via a browser
The user logs in and approves the request
The OAuth server sends back a code to the client
The client exchanges the code for an access token
The client uses the token to call the MCP server

Pseudocode:

fetch('https://mcp-server.com/resource', {
  headers: {
    'Authorization': `Bearer ${accessToken}`
  }
})

At this point, the MCP server only sees a valid request with a token—it doesn't need to know about earlier steps.

MCP + OAuth 2.1 Best Practices

Resource Metadata

To make things simple for the client, the MCP server can host a metadata file that provides OAuth server details.

// /.well-known/oauth-authorization-server
{
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token"
}

Dynamic Client Registration

Rather than requiring a manual setup for every new app, OAuth allows dynamic registration. This lets an MCP client identify itself and receive credentials automatically.

POST /register
Content-Type: application/json

{
  "client_name": "Claude Desktop",
  "redirect_uris": ["https://client.example.com/callback"]
}

Enterprise SSO and App Access

MCP integrates well with enterprise SSO providers like Okta or Azure AD. Here’s a typical flow:¹

The user logs in once using SSO
The client receives an ID token identifying the user
The client then requests access to enterprise resources like Slack, calendars, or document systems
The identity provider issues tokens scoped for those apps

This approach has several benefits:

Users don’t get bombarded with login prompts
IT can manage access centrally
Apps only receive the access they need, improving security

Useful Terms

Term	Meaning
OAuth Server	Issues access tokens
Resource Server	The MCP server being accessed
Access Token	Grants scoped access (like a hotel key)
ID Token	Identifies the user

Acknowledgements

This guide is based on Aaron Parecki's² insightful presentation at the MCP Summit – "Intro to OAuth for MCP Servers"¹, where he clarified how OAuth 2.1 fits cleanly into the MCP architecture.

Special thanks to the Anthropic team and the broader MCP developer community for building secure, extensible tools and workflows that empower LLM applications to connect with the real world.