Notifications
Clear all
Topic starter
19/08/2026 3:48 pm
TL;DR: Shared MCP deployments break clean attribution and least privilege when a single GitHub credential is expanded for multiple users, according to Stacklok. The article describes a proxy-based pattern that keeps OAuth handling, session state, and token exchange outside the MCP server so access remains user-linked rather than shared.
NHIMG editorial — based on content published by Stacklok: GitHub authorization for MCP servers
Questions worth separating out
Q: How should security teams govern shared GitHub access in MCP deployments?
A: Security teams should avoid a single shared GitHub credential for multiple MCP users and instead preserve a distinct downstream identity path per user.
Q: Why do MCP servers create identity governance problems for GitHub access?
A: MCP servers create problems when the access path stops representing the individual user and starts representing the server itself.
Q: What breaks when MCP OAuth is implemented independently by each team?
A: Coverage fragments, redirect handling becomes inconsistent, token validation drifts, and security teams lose visibility into which servers exist or what they can call.
Practitioner guidance
- Define per-user downstream identity paths Ensure each MCP user maps to a distinct downstream GitHub credential path so shared server use does not collapse into one identity.
- Centralise OAuth handling in a broker layer Keep sign-in, token storage, and token exchange in a proxy authorization server rather than embedding them in each MCP server.
- Make session persistence a production requirement Use persistent storage such as Redis when the auth path must survive restarts, upgrades, or infrastructure interruptions.
What's in the full article
Stacklok's full how-to covers the operational detail this post intentionally leaves for the source:
- Exact GitHub OAuth and redirect URI setup for the proxy authorization server.
- How ToolHive stores and exchanges credentials across client sessions and downstream requests.
- When in-memory session storage is acceptable and when Redis is the better deployment choice.
- How DCR and CIMD fit into the MCP client registration path in practice.
👉 Read Stacklok's guide to GitHub authorization for MCP servers →
GitHub auth for MCP servers: what changes for shared access?
Explore further
19/08/2026 4:25 pm
Per-user attribution is the control boundary that shared MCP deployments most often erase. Once a GitHub token is widened to support a shared MCP server, the system can no longer preserve a clean link between actor and action. That creates an identity governance problem, not just an operational one, because audit, offboarding, and incident review all depend on that linkage. The practitioner lesson is to treat attribution as a first-class access requirement.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to GitGuardian & CyberArk research.
A question worth separating out:
Q: When should teams use a broker for MCP client registration and session state?
A: Teams should use a broker when multiple clients, shared deployments, or restart resilience make direct per-server registration and in-memory sessions too fragile. A broker is the right pattern when the identity problem is coordination, not just connectivity. The tradeoff is that the broker must then be monitored, audited, and versioned as part of the access path.
👉 Read our full editorial: GitHub authorization for MCP servers: per-user access without shared creds
