Point11

Authentication and rate limiting

Secure your MCP server with OAuth 2.1 authorization, token validation, rate limiting, and attack mitigation.

Production MCP servers handling enterprise product data require robust authentication, authorization, and rate limiting. The MCP specification mandates OAuth 2.1 for remote servers and documents specific attack vectors that must be mitigated.

OAuth 2.1 Authorization

MCP uses OAuth 2.1 on the Streamable HTTP transport:

  • The MCP server acts as an OAuth 2.1 Resource Server.
  • The MCP client acts as an OAuth 2.1 Client.
  • Authorization Code with PKCE is the recommended flow.
  • Dynamic Client Registration is supported for new AI platform integrations.

Required Discovery Endpoints

Your server must implement two well-known endpoints:

  • /.well-known/oauth-protected-resource: Protected Resource Metadata per RFC 9728. Tells clients how to authenticate.
  • /.well-known/oauth-authorization-server: Authorization Server Metadata. Points clients to your token and authorization endpoints.

Token Validation

The specification is explicit about token handling:

  • Servers MUST verify all inbound requests.
  • Servers MUST NOT use sessions for authentication.
  • Tokens MUST NOT be "passed through" from other services. Your server must only accept tokens explicitly issued for itself.
  • Clients MUST implement Resource Indicators (RFC 8707) to specify the target resource for token requests.

Scope Management

Implement progressive scope minimization:

  • Start with minimal scopes (e.g., mcp:catalog-read for product browsing).
  • Elevate incrementally via WWW-Authenticate challenges when the agent needs write access (e.g., mcp:cart-write for adding items).
  • Never use wildcard or omnibus scopes like *, all, or full-access.

Identity Provider Integration

For enterprise deployments, integrate with your existing identity provider (Auth0, Okta, Azure AD). This allows you to leverage existing user directories, SSO configurations, and audit logging.

Rate Limiting

Rate limiting protects your catalog data and backend services from overuse:

  • Define limits per client, per tool, and per resource.
  • Use tiered limits based on client tier (e.g., 1,000 requests per hour for basic, 10,000 for production).
  • Return standard HTTP 429 responses with Retry-After headers when limits are exceeded.

MCP Gateway Pattern

For organizations running multiple MCP servers, deploy a centralized MCP Gateway that handles authentication, authorization, rate limiting, and routing across all servers and tenants. This avoids duplicating security logic in every server.

AWS provides official guidance for deploying MCP servers behind API Gateway with rate limiting controls.

Attack Mitigations

The MCP specification documents five key attack vectors:

  • Confused Deputy Problem: If your server proxies requests to third-party services, implement per-client consent before forwarding authorization.
  • Token Passthrough: Never accept tokens not issued for your server. Validate the audience claim on every request.
  • SSRF (Server-Side Request Forgery): Block private IP ranges, enforce HTTPS, validate redirect targets, and use egress proxies for outbound requests.
  • Session Hijacking: Bind session IDs to user-specific information. Use cryptographically random, non-deterministic session IDs.
  • Local Server Compromise: For local MCP servers, display exact startup commands for user consent and sandbox with minimal privileges.

Monitoring and Audit

Log every tool invocation, including:

  • Client identity and token claims
  • Tool name and input parameters
  • Response status and latency
  • Rate limit state

This audit trail is essential for SOC 2 compliance and incident response.

Sources

Configuring product catalog endpointsTesting with AI agent simulators

Need help implementing this?

Our team can walk you through the setup.

Talk to Sales