GitHub authorization for MCP servers: per-user access without shared creds

At a glance

What this is: This is a how-to on GitHub authorization for MCP servers, with the key finding that proxy-brokered per-user access preserves attribution and least privilege better than shared credentials.

Why it matters: It matters because IAM teams now have to govern MCP-connected workloads as user-linked access paths, not just as server-side integrations, or auditability and privilege boundaries collapse.

👉 Read Stacklok's guide to GitHub authorization for MCP servers

Context

MCP server authorization becomes an identity governance problem as soon as more than one person depends on the same downstream credential path. In a one-user, one-server setup, static credentials can feel convenient, but shared use quickly erodes attribution, least privilege, and the ability to tell which person actually triggered an action.

GitHub authorization for MCP servers is a useful example because the access model is still built around OAuth, yet the deployment pattern is no longer single-operator. Once teams start widening repository access to reduce failures, the credential path starts serving the server rather than the user, which is a weak foundation for enterprise IAM and NHI governance.

The practical question is not whether the MCP server can reach GitHub, but whether the request can still be tied to the individual behind it. That is the difference between a controllable delegated access path and a shared secret that flattens identity into a service-wide entitlement.

Key questions

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. That keeps attribution intact, limits privilege to the actual session, and makes offboarding and incident review possible. If the broker holds the session state, it should also be the place where revocation and audit are enforced.

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. At that point, GitHub can no longer distinguish who acted, and teams often broaden tokens to keep requests from failing. That turns a delegated access path into shared infrastructure privilege.

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. The result is shadow MCP: systems that appear to work but cannot be governed as a single identity estate.

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.

Technical breakdown

Proxy-brokered OAuth for MCP servers

The pattern described here places a proxy authorization server in front of the MCP server so the downstream application does not own the full OAuth lifecycle. The proxy handles sign-in, stores the GitHub access token, issues its own client credential, and then exchanges that credential for the stored token when a request is forwarded. That creates a layered trust boundary: the client authenticates to the proxy, the proxy authenticates to GitHub, and the MCP server receives a credential that is already tied back to the user session. The key architectural change is that the server no longer needs a shared long-lived GitHub secret.

Practical implication: keep OAuth state in a broker layer, not inside every MCP server that needs GitHub access.

Why shared GitHub credentials break attribution

A shared credential collapses multiple users into one effective identity at the downstream service. That means GitHub can no longer distinguish which person initiated a request, and least privilege becomes harder because the token has to be broad enough to satisfy all users and all operations. In identity terms, the access path loses subject continuity: the person who signs in is no longer the same identity represented at the resource layer. For teams governing MCP, that is not just an audit concern. It changes how you evaluate accountability, authorization scope, and offboarding when access is mediated through a proxy.

Practical implication: avoid broadening a single token to cover shared usage, because it destroys per-user auditability.

Session storage, token refresh, and client registration

The article also shows that authorization is not only about the initial login. Session storage must survive restarts if teams want continuity, which is why in-memory storage works for tests but not for resilient deployments. The proxy can also absorb client registration, including dynamic registration patterns such as DCR and CIMD, so the MCP client does not need separate GitHub app setup for each tool. That is useful because many environments are still unevenly implemented across clients and identity providers. Operationally, the broker becomes the place where session durability, registration friction, and token refresh are managed together.

Practical implication: design for persistent session state and centralized client registration before moving MCP auth into production.

NHI Mgmt Group analysis

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.

Shared static credentials are a poor fit for MCP because they turn user intent into infrastructure permission. The article shows why token broadening happens in practice: teams expand repository access to reduce request failures. That is a familiar NHI pattern, but it becomes more visible in MCP because the server sits between the user and GitHub. The result is privilege inflation that is justified as reliability, then inherited as policy. The practitioner takeaway is to separate convenience from entitlement design.

Proxy-based auth shifts responsibility, but it does not remove governance obligations. Moving OAuth handling and token exchange into ToolHive centralizes control, yet the underlying identity model still has to answer who owns the token, how sessions are persisted, and how revocation happens when users leave. That makes this a lifecycle problem as much as an authorization problem. The practitioner implication is to govern the broker as an identity system, not as a transport convenience.

Dynamic client registration reduces setup friction, but it also moves trust decisions into the middle tier. In MCP environments, DCR and CIMD can help avoid manual per-client registration, yet they also make the proxy layer a policy enforcement point. That means teams should evaluate whether the middle tier is now the authoritative place for client identity, token exchange, and session validation. The practitioner takeaway is to formalize that role before it becomes an accidental control plane.

GitHub authorization for MCP servers exposes a broader identity pattern: machine access is increasingly mediated, not direct. That matters across NHI, IAM, and emerging agent workflows because the stable model is no longer a user talking straight to a service. Instead, a broker is often deciding what downstream identity is presented and how long it persists. The practitioner implication is that governance has to follow the broker, not just the endpoint.

From our research:

• 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.
• For a broader control lens, see Ultimate Guide to NHIs , Static vs Dynamic Secrets for the governance difference between static and dynamic credentials.

What this signals

Per-user credential mediation is becoming the baseline for MCP governance. As shared development environments move from proof of concept to operational use, the old pattern of one static credential per server becomes harder to justify. Teams should expect audit and offboarding requirements to drive more brokered auth designs, especially where GitHub, tool access, and session continuity intersect.

Static secret exposure is still the structural problem under the protocol details. Even when the access flow is elegant, leaked or over-broad tokens remain the failure mode that matters most. Our research shows the average time to remediate a leaked secret is 27 days, which means brokered designs still need lifecycle controls, not just better sign-in choreography.

The next governance question is whether the proxy becomes a durable identity layer or just another brittle control point. If it owns registration, session persistence, and token exchange, it should be mapped to standard access control and authenticator management expectations, including NIST SP 800-53 Rev 5 Security and Privacy Controls and the OWASP Non-Human Identity Top 10.

For practitioners

• 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. Preserve request attribution at the broker layer and avoid expanding a single token to satisfy multiple users.
• 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. This reduces duplicated auth logic and gives security teams one place to govern session state and revocation.
• Make session persistence a production requirement Use persistent storage such as Redis when the auth path must survive restarts, upgrades, or infrastructure interruptions. Treat in-memory storage as a test-only option because lost session state breaks continuity and creates avoidable reauthentication churn.
• Treat client registration as part of access governance Document how DCR or CIMD is handled, which clients are allowed through the proxy, and who approves registration changes. If the proxy absorbs registration, it should also own the policy and audit trail for that step.

Key takeaways

• Shared GitHub credentials in MCP deployments erase per-user attribution and weaken least privilege.
• Proxy-brokered OAuth keeps token handling and session state in one place, which is the right control shape for shared use.
• MCP governance now depends on treating the broker, not the server, as the identity control point.

Key terms

• Proxy Authorization Server: A proxy authorization server sits between a client and downstream service to handle sign-in, token exchange, and session handling. In MCP deployments, it can preserve per-user attribution while keeping long-lived credentials out of the application server.
• Per-User Credential Path: A per-user credential path means each request can be traced to the individual who authenticated, even when the request is forwarded through a shared intermediary. It is a governance requirement when multiple users share the same service surface but should not share the same identity.
• Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
• Session persistence: The tendency for access to remain valid after the original authentication event has ended or been revoked upstream. In browser-centric incidents, this is the gap between killing the login and actually terminating the live SaaS or application session that the attacker is still using.

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.

👉 The full Stacklok post covers the proxy flow, session storage choices, and MCP client registration details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.