MCP OAuth: End-User vs Maker Auth Problem

MCP's OAuth problem: should the API key belong to the tool maker (who built the MCP server) or the end user (who runs the agent)? Getting this wrong means either the maker pays for all user traffic or the end user manages API keys they do not understand. Both options create friction.

The Two OAuth Models

Maker auth: the MCP server embeds its own API key. End users connect and use it freely. The maker pays per query and rate limits are shared across all users. This is how most demo MCP servers work today. End-user auth: each user provides their own API key. The MCP server passes it through to the upstream API. Each user pays for their own usage and has independent rate limits.

Maker Auth: Pros and Cons

Pros: zero friction for end users, instant setup, no key management on the user side. Cons: the maker absorbs all API costs, one abusive user can exhaust rate limits for everyone, and the maker needs usage tracking per user to prevent abuse.

This model works for freemium products where the MCP server is a growth channel. It breaks at scale when thousands of agents hit the same API key simultaneously.

End-User Auth: The Scalable Model

Each user supplies their API key in the MCP server configuration. The server passes the key to the upstream API on each request. Users pay for what they use, rate limits are per-user, and the maker has zero variable costs.

{
  "mcpServers": {
    "search": {
      "url": "https://mcp.scavio.dev/mcp",
      "headers": {
        "x-api-key": "USER_OWN_API_KEY_HERE"
      }
    }
  }
}

Scavio's MCP server at https://mcp.scavio.dev/mcp uses end-user auth. Each user signs up, gets their own API key ($0.005/credit, 250 free/month), and configures it in their MCP client. The user controls their spending and rate limits.

The Hybrid Approach

Some MCP servers use maker auth for a free tier (limited queries) and switch to end-user auth for production usage. This gives users a frictionless trial while pushing heavy users to their own API keys.

import requests, os

def create_mcp_config(user_api_key=None):
    """Generate MCP config with user or maker auth."""
    if user_api_key:
        # End-user auth: user pays, user rate limits
        return {
            "mcpServers": {
                "search": {
                    "url": "https://mcp.scavio.dev/mcp",
                    "headers": {
                        "x-api-key": user_api_key
                    }
                }
            }
        }
    else:
        # Maker auth: shared key, limited to free tier
        return {
            "mcpServers": {
                "search": {
                    "url": "https://mcp.scavio.dev/mcp",
                    "headers": {
                        "x-api-key": os.environ.get("MAKER_SHARED_KEY", "")
                    }
                }
            }
        }

# New user: starts with maker auth
config = create_mcp_config()

# Upgraded user: switches to their own key
config = create_mcp_config("user_personal_api_key")

OAuth 2.0 for MCP

The MCP spec supports OAuth 2.0 authorization flows. For enterprise MCP servers, implement OAuth with per-user tokens. The user authorizes the MCP server to make API calls on their behalf, and the server uses their token for each request. This is the cleanest solution for multi-tenant MCP deployments.

Practical Advice for MCP Server Builders

Start with end-user auth. It is simpler to implement, costs nothing to operate, and scales linearly. Add a maker-auth free tier only if you need it for growth. Never embed a production API key with real spending power into a public MCP server -- one leaked config file exposes your entire budget.

Rate Limit Architecture

With end-user auth, rate limits are naturally per-user (enforced by the upstream API). With maker auth, you need a rate limiter in your MCP server that tracks per-user usage against the shared key. Redis with sliding window counters is the standard approach. Without per-user rate limiting on maker auth, a single agent loop can burn through your monthly budget in minutes.