MCP server identity and token exchange: what should teams change?

TL;DR: Static API keys and shared service accounts break user-level attribution and least-privilege in MCP deployments, while token exchange and federation let backend calls inherit the right identity context across trust domains, according to Stacklok. For practitioners, the real shift is that MCP authorization must be paired with downstream identity translation, because shared credentials hide who acted and widen blast radius.

NHIMG editorial — based on content published by Stacklok: Beyond API keys: token exchange, identity federation, and MCP

Questions worth separating out

Q: How should security teams handle identity in MCP servers that call backend tools on behalf of users?

A: They should preserve user context end to end by using short-lived tokens, token exchange, or federation instead of shared service credentials.

Q: Why do shared service accounts create problems in MCP deployments?

A: Shared service accounts make the backend see one identity for many users, so attribution disappears and privilege usually expands to make the account usable everywhere.

Q: What breaks when API keys are used as the main MCP credential?

A: Persistent API keys create a standing secret that can outlive the task, the session, and sometimes the user who triggered it.

Practitioner guidance

• Eliminate shared backend credentials for MCP services Inventory every MCP server and tooling path that still relies on a service-account key or long-lived API key.
• Map every MCP backend to a specific token audience Define the expected issuer, audience, and scope for each downstream service before you wire up token exchange.
• Treat federation trust as a governed asset Document every cross-domain trust relationship, including which IdP or STS mints the token, what claims are required, and which downstream APIs accept it.

What's in the full article

Stacklok's full blog covers the operational detail this post intentionally leaves for the source:

• A step-by-step token exchange flow for same-IdP deployments, including the claim changes between front-end and backend tokens.
• A second pattern for cross-domain federation, with the trust-service sequence used when the downstream service sits in another cloud or IdP.
• Concrete token examples showing how issuer, audience, scope, and subject differ across the MCP and backend layers.
• ToolHive deployment details for containerised MCP servers, including where policy enforcement and backend token acquisition sit in the request path.

👉 Read Stacklok's analysis of token exchange, federation, and MCP identity →

MCP server identity and token exchange: what should teams change?

Explore further

View Full Forum →  |  NHI Foundation Course →