OAuth for MCP Servers: Authenticating Agents, Not Humans

Originally published at lumbox.co

The Model Context Protocol spec recommends OAuth 2.1 + Dynamic Client Registration (RFC 7591) for server authentication. In practice, 90% of MCP servers ship with static API keys. That works for single-user local setups. It breaks the moment you want to expose an MCP server to many agents, many users, or a public marketplace.

Why OAuth beats API keys for MCP

• Scoped access. An agent can request inboxes.read but not inboxes.delete.
• Revocable without rotating. A compromised token is revoked; the long-lived secret never leaves the server.
• Per-user attribution. Every tool call has a user identity. Audit becomes possible.
• Dynamic client registration. An MCP client (Claude, Cursor) can self-register without a human configuring the server.

The minimum viable OAuth surface

• /.well-known/oauth-authorization-server — RFC 8414 metadata.
• /.well-known/oauth-protected-resource — RFC 9728 linking resource to auth server.
• /oauth/register — RFC 7591 Dynamic Client Registration.
• /oauth/authorize — standard OAuth 2.1 authorization code flow with PKCE.
• /oauth/token — token exchange.

Token design for agents

Short-lived access tokens (15 minutes), long-lived refresh tokens (30 days, rotating on use), narrow scopes per tool class. Don't issue a token with * scope unless the client literally needs every tool.

The Lumbox approach

Lumbox's MCP server is moving from API-key auth to full OAuth 2.1 + DCR. When an agent installs @lumbox/mcp-server, the client auto-registers, pops an OAuth consent screen once, and gets scoped tokens for the tools it asked for. No hand-editing a config file with a key. lumbox.co.