Comparison + setup guide for the major OAuth-gated providers that ship MCP servers (official or community): Google, GitHub, Slack, Stripe, Notion, Linear, Discord. Shape of OAuth flow, scope model, token storage, integration effort — and where wmcp.sh fits as a centralized OAuth proxy.
MCP supports OAuth 2.1 (RFC 6749 / 9700) with PKCE and Dynamic Client Registration (RFC 7591). Most providers below implement standard OAuth 2.0 + PKCE.
All claims are based on each provider's public documentation as of 2026-05-28. Scopes, flows, and token TTLs change frequently — always check the vendor's docs before implementing. We are not affiliated with the providers listed.
OAuth 2.0 with PKCE; very fine-grained scopes per Google API surface. MCP servers (community + emerging vendor support) typically run as hosted or local with per-user token storage. Refresh tokens supported.
OAuth 2.0 + GitHub Apps (preferred for scoped fine-grained access). Official MCP server ships with both PAT and OAuth flows; community variants exist. Per-installation scope model is well-suited to agents.
OAuth 2.0 with bot tokens + user tokens. Granular scope model (channels:read, chat:write, im:history). Official + community MCP servers available. Workspace-level tokens vs per-user differ in capability.
Stripe Connect uses OAuth for platform-on-merchant access; direct API uses restricted API keys (not OAuth) for first-party use. Official MCP server exists. Match the auth pattern to your agent's role (platform vs merchant).
OAuth 2.0; per-integration scope is bound to specific pages/databases the user shares with the integration — a useful safety property for agents. Community + emerging vendor MCP servers.
OAuth 2.0 with PKCE; relatively small, sensible scope set (read/write across issues, projects, cycles). Vendor-published MCP server. Often cited as the cleanest OAuth onboarding among comms-class tools.
OAuth 2.0 for user tokens; separate bot-token model for server-side automation. Community MCP servers in both flavors. Choose based on whether the agent acts as a user or as a bot account.
One endpoint (wmcp.sh/mcp/<provider>) that handles RFC 7591 DCR + PKCE upstream against any of the providers above, so an agent that can connect to one MCP server but can't drive arbitrary OAuth flows still works.
| Provider | Flow | Scope granularity | Token storage (typical) | Integration effort |
|---|---|---|---|---|
| OAuth 2.0 + PKCE | Very fine | Per-user, refresh-token | Moderate (scope review, consent screen) | |
| GitHub | OAuth 2.0 / GitHub App | Fine (Apps even finer) | Per-user or per-installation | Low (App model is clean) |
| Slack | OAuth 2.0 | Fine (bot vs user) | Per-workspace + per-user | Low–moderate |
| Stripe | Connect OAuth / API keys | Restricted-key roles | Per-account | Low for direct; moderate for Connect |
| Notion | OAuth 2.0 | Page/DB-bound | Per-integration | Low |
| Linear | OAuth 2.0 + PKCE | Small + clean | Per-user | Low |
| Discord | OAuth 2.0 / bot tokens | Moderate | Per-user / per-bot | Low (bot) / Moderate (user) |
| wmcp.sh proxy | RFC 7591 DCR + PKCE | Passed through | Server-side vault | Lowest — single endpoint for many upstreams |
Cells reflect typical/default usage per each provider's documentation. Specific scopes, token TTLs, and refresh policies change — check the vendor's docs before implementing.
Almost every OAuth-MCP integration follows the same shape. Use this as your template.
# 1. Register your client with the provider (or use RFC 7591 DCR)
# → get client_id / client_secret OR rely on dynamic registration.
# 2. Decide token storage:
# a) Local (Claude Desktop / Cursor stores per-user)
# b) Server-side vault (Composio / Arcade / wmcp.sh proxy)
# c) Per-call short-lived (your backend mints)
# 3. Run the OAuth flow with PKCE:
# GET /authorize → user consents → callback → exchange code for token.
# 4. Connect the MCP client to the provider's MCP endpoint:
curl -H "Authorization: Bearer $TOKEN" 'https://<provider>/mcp'
# 5. Or — let wmcp.sh handle steps 1-3:
curl 'https://wmcp.sh/mcp/<provider>'
# wmcp.sh runs DCR + PKCE upstream and injects bearer on every tool call.The shape: an agent (Claude.ai connector, Cursor remote MCP, web agent) connects once to wmcp.sh/mcp/<provider> using standard OAuth 2.1 + PKCE + Dynamic Client Registration. wmcp.sh handles the dance with the upstream provider, stores the refresh token server-side, and forwards every tool call with the right bearer. The agent doesn't have to know provider-specific OAuth shapes.
Claude.ai connectors and other hosted clients can only connect to one MCP server at a time — they can't run the OAuth dance against twelve different providers. wmcp.sh consolidates.
Instead of building per-provider token storage in your app, use wmcp.sh's vault. Tokens never touch your servers; calls go agent → wmcp.sh → upstream.
Provider OAuth registration + token vault + MCP at mcp.yourbrand.com + verified badge. From $499 one-time setup; Managed Retainer $999/mo; Enterprise $4,999+/mo.