MCP authentication is how an MCP server checks who is calling it. The spec defines an optional OAuth flow for servers reached over HTTP. Local servers skip that and read credentials from environment variables. MCPifex uses a simple API key for each instance.
A simple way to picture it
Say you connect Claude to a database through MCP. Two separate logins are in play. Claude has to prove itself to the server, and the server has to prove itself to the database. The first is MCP authentication. The second is whatever the database needs, like a password.
Local and remote servers differ
The split follows where the server runs:
- Local (stdio). Your AI app starts the server as a subprocess on your machine. A credential in an environment variable is enough, because nothing crosses a network.
- Remote (HTTP). Anyone who can reach the URL can try to call it. The MCP authorization spec covers this with an OAuth 2.1 flow, but it's optional. Many remote servers just check a bearer key their operator issued.
Getting this wrong is how secrets end up in the wrong place, like a static key inside a browser app.
How it works on MCPifex
As of October 2026, there are two credentials, kept apart. The first is your mcpx_... API key, which authenticates your MCP client to the gateway. You send it as an Authorization: Bearer header, or as the first part of the URL path for clients that can't send headers.
The second is whatever the server behind it needs. That might be a database password, or an OAuth connection to a Google account for Search Console. You save it once in the portal, and the gateway attaches it on every call. You never type it into your AI client.
Keys you can revoke
If a key leaks, revoke it in the portal. Full details are in API keys and authentication, and the marketplace shows what each server needs.
Related terms
See MCP gateway, the component that usually sits at this boundary, and MCP server. For safer setups overall, read the MCP security guide.
Quick answers
No. The MCP authorization spec defines an optional OAuth 2.1 flow for servers reached over HTTP. Local stdio servers read credentials from environment variables, and many remote servers simply check a bearer API key issued by their operator.
Each MCPifex instance uses an mcpx_ API key. Clients send it as an Authorization: Bearer header, or as the first segment of the URL path when a client cannot send headers. You can revoke a key in the portal at any time.
They stay on the server side. You save the upstream credential once in the MCPifex portal and the gateway attaches it on every call, so you never type it into your AI client.
Sources
Ready to try it?
Run hosted MCP servers behind one endpoint and choose exactly which tools your AI can use.