Authentication is the Hardest Part of MCP at Scale
Getting a single MCP server talking to a single agent is straightforward. Getting 30 agents, each authorised to access different subsets of 40 MCP servers, with credentials that expire, refresh, and must never be embedded in code — that is an authentication problem. It is the problem that stops most MCP deployments from reaching production safely, and it is the problem an MCP gateway like TrueFoundry's is specifically designed to solve.
This article explains how MCP authentication works at the protocol level, what OAuth 2.0 and OIDC add to the picture, and how TrueFoundry's token injection at the gateway layer eliminates credential sprawl across your agent fleet.
MCP Authentication at the Protocol Level
The MCP specification defines how agents and servers exchange messages — tool calls, results, context — but intentionally leaves authentication flexible. MCP servers can require no authentication (suitable for local development only), static API keys (simple but unscalable and insecure at team scale), or OAuth 2.0 tokens (the correct choice for production enterprise deployments).
In practice, every MCP server that connects to a real enterprise system — Slack, Jira, GitHub, a production database — requires OAuth 2.0. The agent must present a valid access token when invoking tools. That token must belong to the right identity, have the right scopes, and be refreshed before it expires. Managing this per-agent, per-server is operationally infeasible beyond a handful of servers — which is exactly why teams turn to a centralised solution like the TrueFoundry MCP Gateway.
OAuth 2.0 for MCP: The Basics
OAuth 2.0 is an authorisation framework that allows an application to obtain limited access to a resource on behalf of a user. In the MCP context, the 'application' is the AI agent, the 'resource' is the tool backend (Slack, GitHub, a database), and the 'user' is the human who initiated the agent workflow.
The key flows relevant to MCP are:
Authorisation Code Flow — the user authenticates with the identity provider, receives an authorisation code, which is exchanged for an access token. Standard for user-facing applications.
Client Credentials Flow — the agent authenticates using its own credentials (client ID and secret) without user involvement. Used for system-to-system integrations where no human user is in the loop.
On-Behalf-Of (OBO) Flow — the agent acts on behalf of a specific user, using that user's identity and permissions rather than a broad service account. This is the most important flow for enterprise MCP deployments, and a first-class capability in TrueFoundry's MCP Gateway.
Why OBO matters: Without On-Behalf-Of, agents run with broad service account privileges. A compromised agent can access everything that service account can access. OBO scopes the agent's power to exactly what the initiating user is permitted to do. TrueFoundry enforces OBO flows by default, ensuring agents always operate within the boundaries of the initiating user's permissions.
OIDC: Adding Identity to the Picture
OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. Where OAuth 2.0 answers 'what is this agent allowed to do?', OIDC answers 'who is this agent acting as?' OIDC issues an ID token — a JWT containing claims about the user's identity, group memberships, and the identity provider that authenticated them.
In the TrueFoundry MCP Gateway, OIDC integration means the gateway can verify not just that a request carries a valid access token, but that the token was issued for the right user by the organisation's trusted identity provider — Okta, Azure Active Directory, or a custom IdP. This makes access revocation automatic: when an employee leaves the organisation and their account is deactivated in the IdP, their agents lose access to all MCP tools immediately, without any manual gateway configuration change. TrueFoundry's native IdP integration ensures this revocation propagates instantly across every connected MCP server.
The Token Injection Pattern
Token injection is the mechanism that allows agents to operate without ever handling raw backend credentials. Here is how it works in the TrueFoundry MCP Gateway:
At provisioning, the agent is issued a single gateway token — one credential that grants access to the TrueFoundry gateway endpoint.
When the agent invokes a tool, it sends the request to the TrueFoundry MCP Gateway with its gateway token. The gateway authenticates the agent and resolves its identity.
The gateway looks up the appropriate backend OAuth token for that agent's identity and the target MCP server. If the token is near expiry, TrueFoundry refreshes it automatically.
The gateway injects the backend token into the forwarded request before it reaches the MCP server. The MCP server receives a properly authenticated request. The agent never saw the backend credential.
This pattern — central to TrueFoundry's gateway architecture — has three critical benefits. First, credential rotation becomes a gateway operation, not an agent deployment. Second, backend credentials can be stored in a secrets manager with strict access controls, never touching developer laptops. Third, the TrueFoundry MCP Gateway creates a complete audit record of every credential use, satisfying compliance requirements for credential access logging.
RBAC on Top of Authentication
Authentication answers 'who is this?' Authorisation answers 'what are they allowed to do?' The TrueFoundry MCP Gateway layers RBAC policies on top of OAuth authentication to enforce tool-level access controls.
In a well-configured TrueFoundry deployment, a FinanceAgent might have permission to call the query_ledger tool on the accounting MCP server but not the write_transaction tool. A SupportAgent might have read access to the CRM MCP server but not to the customer PII fields within it. These policies are defined centrally in the TrueFoundry MCP Gateway and enforced at request time, consistently across all agents and frameworks.
TrueFoundry MCP Gateway
TrueFoundry's MCP Gateway handles the full OAuth 2.0 and OIDC stack centrally. It stores and manages OAuth tokens for all MCP servers on behalf of each user, maintains the mapping from gateway tokens to backend OAuth tokens, and refreshes tokens automatically before expiry. Users and agents interact with the TrueFoundry gateway using a single token. OBO flows ensure agents act with the initiating user's identity and permissions — not a broad service account. TrueFoundry's integration with Okta, Azure AD, and custom IdPs means access revocation is immediate and automatic.
Practical Guidance for Engineering Teams
When designing MCP authentication for your organisation, three principles apply regardless of which gateway you use — and TrueFoundry's MCP Gateway is built to enforce all three out of the box. First, never embed provider OAuth tokens in agent code or environment variables — centralise credential storage in the gateway. Second, always use OBO flows for agents that act on user data, so permissions are scoped to the initiating user. Third, integrate your MCP gateway with your corporate IdP from day one — retrofitting SSO into an existing agent fleet is significantly more expensive than starting with it. TrueFoundry supports IdP integration from initial setup, so teams avoid this costly retrofit entirely.
Authentication is where most MCP security incidents originate. Getting it right at the gateway layer means it is right for every agent that flows through the gateway, without relying on individual development teams to implement it correctly. TrueFoundry's MCP Gateway provides this centralised authentication layer, giving engineering teams a production-ready foundation for secure, scalable MCP deployments.
Top comments (0)