Notifications
Clear all
Topic starter
20/08/2026 5:26 pm
TL;DR: Token exchange can let an MCP server authenticate to a downstream GraphQL API with short-lived, audience-scoped tokens instead of embedded secrets, while preserving user-level auditability, according to Stacklok. That pattern matters because it shifts MCP security from static credential handling to governed token brokering, where scope separation and trust relationships become the control plane.
NHIMG editorial — based on content published by Stacklok: Token exchange with ToolHive and Okta for MCP authentication to GraphQL
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams govern MCP servers that wrap REST APIs?
A: Security teams should govern MCP servers as agent-facing identity surfaces, not as simple API adapters.
Q: Why do MCP integrations create new NHI risk if they reuse one token everywhere?
A: Because a single bearer token collapses authentication, authorisation, and backend access into one reusable credential.
Q: What breaks when an MCP server is given direct backend secrets instead of exchanged tokens?
A: You lose privilege separation, audit clarity, and revocation precision.
Practitioner guidance
- Separate MCP and backend trust domains Create distinct authorization servers, policies, and scopes for the MCP boundary and the backend API so one token cannot be reused everywhere.
- Constrain token exchange to explicit broker policies Require the exchange client, grant type, audience, and scopes to be approved together so the broker cannot mint broader backend access than intended.
- Preserve user attribution through the downstream call Ensure the exchanged token retains the originating identity context needed for audit and recertification, rather than collapsing everything into a shared service account.
What's in the full article
Stacklok's full blog post covers the implementation detail this post intentionally leaves at the governance level:
- Step-by-step Okta authorization server configuration for separate MCP and backend audiences
- ToolHive command-line examples showing token exchange parameters and issuer validation
- MCP server configuration details for forwarding downstream bearer tokens to the backend API
- Practical token claim examples that show the difference between client and exchanged access tokens
👉 Read Stacklok's blog post on token exchange for MCP server authentication →
MCP token exchange with Okta and ToolHive: what changes for IAM teams?
Explore further
20/08/2026 6:15 pm
Token exchange is a governance control, not just an integration convenience. The article shows that MCP security improves when the intermediary never carries the same credential into both the user-facing and backend-facing legs of the flow. That matters because NHI programmes often fail when a single secret becomes the bridge across domains. Practitioners should see this as identity partitioning, not only OAuth plumbing.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to Astrix Security's The State of MCP Server Security 2025.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how far many implementations still are from least-privilege design.
A question worth separating out:
Q: How do IAM teams decide whether token exchange is enough for MCP governance?
A: Use token exchange when the intermediary only needs to mediate access and should not hold long-lived backend credentials. If the design requires persistent backend privileges, then the architecture is already too broad and should be reworked before it is productionised.
👉 Read our full editorial: Token exchange for MCP servers reduces secret sprawl and audit gaps
