MCP Security with a gateway

Most MCP‑capable hosts converge on the same security profile: HTTPS only, OAuth2.0/2.1 as the primary mechanism for user‑initiated auth, and bearer/API‑key support for automation.geminicli+3​

Security & Authentication for Remote MCP Servers Across Hosts

Remote MCP servers sit at an awkward intersection: they must be easy to plug into hosted AI UIs, but also secure enough to guard internal APIs, filesystems, and production data. MCP itself is deliberately auth‑agnostic, so each host (ChatGPT Dev Mode, Claude, Gemini CLI, Manus, etc.) layers its own security expectations and UX on top of standard HTTP/SSE transports.modelcontextprotocol+1​

This article compares those expectations in a single security profile table, then extracts patterns you can implement once and reuse across all major clients.

---

Shared MCP security fundamentals

Before diving into hosts, there are some protocol‑level constants:

• Transport security

  • Remote MCP is always over HTTPS, with SSE or streamable HTTP layered on top; plain HTTP is only tolerated for localhost/dev and is rejected for production redirect URIs in many examples.openai+2​

  • TLS termination usually happens at a gateway or reverse proxy fronting your MCP server.developers.cloudflare+1​

• Auth model (MCP‑agnostic, HTTP‑centric)

  • MCP messages are just JSON‑RPC over HTTP/SSE; authentication is done with standard HTTP mechanisms: OAuth2 bearer tokens, API keys, JWTs in headers, etc.roocode+1​

  • The emerging best practice is OAuth 2.1 with discovery (.well-known/oauth-authorization-server) and dynamic client registration.scalekit+1​

• Authorization & scopes

  • The spec pushes authorization concerns to the server: implement RBAC, scopes, and audit logging yourself; hosts simply attach tokens.manus+2​

With that in mind, the interesting part is what each host expects and supports.

---

Security profile table: major MCP hosts

Remote MCP security profiles

Host / Context	Supported auth mechanisms for remote MCP	Redirect URI & browser‑flow behavior	Secret / token handling on the host side	Notable constraints & quirks	Best way to design a portable MCP server for this host
ChatGPT – Developer Mode (Connectors)	- OAuth2.0/2.1 with authorization code + PKCE (primary). developers.openai+2​ - No‑auth servers for public/low‑risk tools. linkedin+1​ - API‑key style headers technically work but are non‑UX‑integrated (you manage them yourself behind your MCP gateway). gelembjuk.hashnode​youtube​	- OpenAI’s Apps SDK auth docs specify production redirect URL https://chatgpt.com/connector_platform_oauth_redirect. developers.openai​ - Tutorials recommend including legacy URIs like https://chatgpt.com/oauth/callback and https://chat.openai.com/oauth/callback for compatibility. linkedin​ - Dev Mode opens a browser window and expects your authorization server to redirect back to one of those HTTPS URLs with code and state. linkedin+1​	- Tokens are stored inside ChatGPT’s workspace context, not visible to the model, and sent as Authorization: Bearer <token> to your MCP endpoint. developers.openai+1​ - You never share long‑lived passwords or API keys directly with ChatGPT; your OAuth server mints revocable tokens. auth0+1​	- Redirect URIs must be HTTPS or localhost; invalid schemes are rejected in reference implementations. openai​ - CORS must allow https://chatgpt.com and https://chat.openai.com plus headers like Authorization and MCP-Protocol-Version. linkedin​ - Misconfigured OAuth often manifests as “tools don’t load after auth” due to incorrect redirect or token endpoints. openai​	- Implement a standard OAuth 2.1 server with discovery and PKCE. modelcontextprotocol+1​ - Whitelist ChatGPT’s redirect URIs and configure CORS for ChatGPT origins. linkedin+1​ - On 401, return structured metadata (e.g. oauth_authorize_url) so Dev Mode knows it must launch login. linkedin+1​ - Use short‑lived access tokens and refresh tokens; treat Dev Mode as a public client (no client secret enforcement). scalekit+1​
Claude (web / desktop / mobile) – Remote MCP / Custom Connectors	- OAuth2.0 is the default path for custom connectors; users “sign in” to the app and grant specific permissions. claude+1​ - Some guides and examples also describe API‑key‑based connectors for simpler integrations (key configured in Claude or injected on your server). getclockwise+1​ - No‑auth is allowed for public servers. infoq​	- When a remote MCP server returns 401 with proper metadata, Claude opens a browser window to your OAuth authorization endpoint; user authenticates; you redirect back to a Claude‑managed redirect URI. claude+1​ - Claude stores tokens and silently attaches them to subsequent MCP requests until revoked or expired. claude+1​	- Tokens are held by Claude as connector credentials; Claude never sees the user’s password, just the OAuth tokens. claude​ - Permissions can be revoked either in Claude’s connector settings or via the third‑party account’s security settings. claude+1​	- Reports show some inconsistencies in Claude Code’s handling of OAuth scopes (e.g. not propagating offline_access from scopes_supported), leading to frequent re‑auth in that specific client. github​ - Anthropic and third‑party guides increasingly treat OAuth as required for serious remote MCP hosting. zuplo+1​	- Expose an OAuth 2.1 authorization server with explicit scopes per connector (e.g. mcp:crm.read). modelcontextprotocol+1​ - Use least‑privilege scopes and record them in your .well-known metadata; Claude will request them on first connection. modelcontextprotocol+2​ - Implement granular RBAC on your side and log every tool call for audit. modelcontextprotocol+1​ - Support revocation and token rotation without user re‑provisioning the connector. modelcontextprotocol+1​
Gemini CLI – MCP client	- OAuth2 with automatic discovery and dynamic client registration for remote MCP over HTTP/SSE. geminicli+1​ - Special authProviderType values: dynamic_discovery, google_credentials, service_account_impersonation. geminicli+1​ - JWT/API‑key‑like schemes are also possible behind your own gateway. geminicli+1​	- CLI detects 401 responses, discovers OAuth endpoints from your server metadata, then launches a local browser for the authorization code flow. geminicli+1​ - Tokens are stored locally (e.g. in config files) and reused by the CLI until expiration; /mcp auth lets users re‑auth or inspect status. google-gemini.github+1​	- Access and refresh tokens are kept in the user’s environment, not shared with Google’s backend; the CLI simply attaches them to MCP requests. google-gemini.github+1​ - For google_credentials and service_account_impersonation, the CLI leverages Google ADC or service‑account keys on the user’s machine. google-gemini.github+1​	- Requires a graphical browser for the full OAuth flow; headless or remote servers may need special handling (e.g. device code flows or SSH port forwarding). geminicli+1​ - When used with Google Cloud Security MCP servers, you can enforce org‑level security via IAP and service‑account impersonation. security.googlecloudcommunity​	- Implement .well-known OAuth metadata so Gemini CLI can auto‑discover endpoints. geminicli+1​ - Support short‑lived tokens with refresh, and align scopes with specific MCP tools. geminicli+1​ - If you target Google environments, front your MCP with Cloud Run/IAP and accept Google‑issued tokens; Gemini CLI’s service_account_impersonation will handle the rest. security.googlecloudcommunity+1​
Manus – Custom MCP Servers	- Manus docs explicitly recommend API keys or OAuth tokens as the primary auth methods for custom MCP servers. manus​ - Typically you configure secrets (API key, OAuth access token) once in Manus, and it injects them into requests. manus​	- Manus itself does not run an interactive browser OAuth flow for you; instead, you usually generate tokens externally (OAuth or API key) and paste them into the integration config. manus​ - For more advanced flows, you can front your MCP server with a gateway that does OAuth on Manus’s behalf and issues downstream tokens. manus+1​	- Secrets are stored in Manus as connector credentials and sent over HTTPS as headers or query params (headers strongly recommended). manus​ - You must ensure they are not logged or echoed by your MCP server. manus​	- Primary risk is long‑lived tokens/API keys sitting in a SaaS config; rotation and least‑privilege access become critical. manus​ - Manus focuses on automation scenarios, so per‑user identity is often not propagated unless you encode it yourself in custom headers or tokens. manus​	- Design your MCP server to accept bearer tokens or API keys with well‑defined scopes. manus+1​ - Provide lightweight admin tooling (or CI) to rotate those tokens regularly. manus​ - For highly sensitive systems, use an OAuth‑aware gateway (e.g. Zuplo/Scalekit/Custom) that exchanges a Manus‑stored API key for short‑lived downstream tokens. zuplo+2​

---

Unifying pattern: one OAuth‑secured MCP gateway

Given this landscape, a practical pattern emerges: put an OAuth‑aware gateway in front of your internal MCP servers, and make all hosts talk to that gateway over HTTPS.

Key elements of this design:

1. Single public MCP endpoint + OAuth 2.1

   • Build a gateway that exposes:

     • POST /mcp (or /) for JSON‑RPC requests.

     • GET /mcp/stream (or similar) for SSE streaming.

     • OAuth endpoints: /authorize, /token, and discovery under .well-known/oauth-authorization-server.scalekit+2​

   • Implement PKCE, dynamic client registration, and scopes aligned with your MCP tools (mcp:fs.read, mcp:crm.write, etc.).modelcontextprotocol+1​

2. Host‑specific adapters via config only

   • ChatGPT Dev Mode:

     • Register your OAuth client using redirect URIs from OpenAI’s Apps SDK docs (including https://chatgpt.com/connector_platform_oauth_redirect).developers.openai+1​

     • Configure CORS for https://chatgpt.com and https://chat.openai.com.linkedin​

   • Claude:

     • Treat Claude as a standard OAuth public client; permit its published redirect URIs and scopes.zuplo+2​

   • Gemini CLI:

     • Implement discovery so the CLI can auto‑detect OAuth and perform the flow via /mcp auth.google-gemini.github+1​

   • Manus:

     • Either give Manus a long‑lived machine token that the gateway exchanges for short‑lived access tokens, or expose an API‑key‑secured variant of the gateway for integrations that cannot do interactive OAuth.gofastmcp+2​

3. Internal authorization & auditing

   • The gateway should enforce RBAC and scopes for every MCP tool call, and log which user (from the OAuth identity) invoked which tool with which parameters.manus+2​

   • For especially sensitive operations (e.g. infrastructure control), consider additional confirmation steps or out‑of‑band approvals.getclockwise+1​

4. Token lifecycle & revocation

   • Use short‑lived access tokens and refresh tokens where clients support them; this reduces blast radius.github+1​

   • Provide an admin UI or API for:

     • Forced revocation of tokens per user or per host.

     • Regenerating Manus/automation tokens.zuplo+1​

---

What this means for your stack

For someone running multiple custom MCP servers and wanting them usable from ChatGPT Dev Mode, Claude, Gemini CLI, and Manus without per‑host rewrites:

• Treat OAuth 2.1 + HTTPS as non‑negotiable for any remote MCP that touches real data.zuplo+2​

• Centralize auth and authorization in a gateway MCP server and keep your internal servers on a private network behind that gateway.developers.cloudflare+2​

• Use scopes that map directly to MCP tools; this gives you host‑agnostic least‑privilege enforcement and simpler audits.getclockwise+1​

Once this gateway is in place, adding a new host is mostly configuration and testing rather than a new security architecture.

1. https://geminicli.com/docs/tools/mcp-server/
2. https://manus.im/docs/integrations/custom-mcp
3. https://zuplo.com/blog/building-secure-mcp-servers-with-oauth
4. https://modelcontextprotocol.io/docs/tutorials/security/authorization
5. https://docs.roocode.com/features/mcp/server-transports
6. https://community.openai.com/t/chatgpt-custom-mcp-oauth-fails-to-get-tools-when-auth-enabled/1330136
7. https://developers.cloudflare.com/agents/guides/remote-mcp-server/
8. https://gofastmcp.com/servers/auth/authentication
9. https://www.scalekit.com/blog/ship-secure-mcp-server
10. https://developers.openai.com/apps-sdk/build/auth/
11. https://www.linkedin.com/pulse/building-chatgpt-mcp-developer-mode-complete-tutorial-reuven-cohen-efgoc
12. https://auth0.com/blog/add-remote-mcp-server-chatgpt/
13. https://github.com/ruvnet/chatgpt-dev-mode
14. https://gelembjuk.hashnode.dev/implementing-authentication-in-a-remote-mcp-server-with-sse-transport
15. https://www.youtube.com/watch?v=D-m5J4rTGN8
16. https://gist.github.com/ruvnet/7b6843c457822cbcf42fc4aa635eadbb
17. https://help.openai.com/fr-ca/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt-beta
18. https://support.claude.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp
19. https://www.getclockwise.com/blog/claude-remote-mcp-server-getting-started
20. https://www.infoq.com/news/2025/06/anthropic-claude-remote-mcp/
21. https://github.com/anthropics/claude-code/issues/7744
22. https://google-gemini.github.io/gemini-cli/docs/tools/mcp-server.html
23. https://security.googlecloudcommunity.com/google-security-operations-2/google-cloud-security-mcp-servers-in-gemini-cli-922
24. https://github.com/google-gemini/gemini-cli
25. https://www.speakeasy.com/docs/gram/clients/using-chatgpt-developer-mode-with-gram
26. https://manus.im/docs/integrations/integrations