Authentication patterns for MCP servers

## Three patterns, three audiences Most MCP servers fall into one of three authentication shapes: 1. **Static credentials** — one shared key for all callers (your own internal tools) 2. **Per-user credentials** — each end user supplies their own token (multi-tenant tools) 3. **OAuth** — full delegated auth, user grants access in their browser ## 1. Static credentials Use this when **you** own the upstream account. A weather API key, an internal CRM token, a shared OpenAI key. Store it once in easyMCP under [credentials](/docs/static-credentials) and every tool call uses it. ## 2. Enduser credentials Use this when **each user has their own account** on the upstream service. The MCP client prompts the user for the token, easyMCP scopes it to that connection, and tool calls forward it as the right header. This is the right pattern for things like "let Claude read my GitHub repos" — each user supplies their own GitHub token. ## 3. OAuth Full OAuth is heavier but unavoidable for some upstreams (Google APIs, Slack, Notion). easyMCP handles the dance: redirect, token exchange, refresh — you just configure the client ID and scopes. ## Which to pick | Audience | Pattern | |---|---| | Internal tool, you own the account | Static | | Multi-tenant SaaS, users have their own keys | Enduser | | Consumer-facing, third-party SaaS upstream | OAuth | ## Read next - [Static credentials](/docs/static-credentials) - [Enduser credentials](/docs/enduser-credentials)