Notifications
Clear all
Topic starter
08/06/2026 4:17 pm
TL;DR: The MCP Registry solves discovery for model context protocol servers, but authentication remains the real governance gap because API keys add friction, sprawl, and weak revocation patterns, according to WorkOS. OAuth aligns registry-based access with scoped, revocable, standardised identity controls instead of standing credentials.
NHIMG editorial — based on content published by WorkOS: Why OAuth is the right fit for the MCP Registry
Questions worth separating out
Q: How should security teams govern access to MCP registry-discovered servers?
A: Security teams should treat registry-discovered servers as governed non-human access, not as simple developer convenience.
Q: Why do API keys create problems in MCP environments?
A: API keys create problems because they are static bearer secrets that do not align with registry-based discovery or delegated consent.
Q: How can organisations tell whether MCP access is actually governed?
A: Governed MCP access shows up as standardised scope definitions, centralised token revocation, and consistent logging across providers.
Practitioner guidance
- Default registry-connected servers to OAuth Make OAuth the standard authentication path for MCP servers discovered through a registry, and reserve API keys for narrow legacy cases where no delegated flow exists.
- Define per-server scope boundaries Map each MCP server to the minimum permissions it needs, then document those scopes in access reviews so teams can verify the purpose of each token.
- Centralise token revocation and audit Route MCP access through identity providers and logging systems that can revoke tokens centrally and preserve traceable consent history across providers.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Implementation patterns for registering an MCP server as an OAuth application and wiring the redirect flow.
- Provider-specific setup considerations for GitHub, Google Workspace, and Slack authentication.
- Backward-compatibility guidance for teams that still need API key support in CI/CD or legacy tool chains.
- Developer-centric examples showing how OAuth reduces context switching during server connection.
👉 Read WorkOS's analysis of why OAuth fits MCP registry authentication →
MCP registry access: why OAuth is the governance fit teams need?
Explore further
08/06/2026 5:51 pm
OAuth is the right control plane for registry-discovered MCP access because it converts discovery into governed consent. The registry solves findability, but findability alone does not establish accountable access. OAuth adds a standard authorisation layer that lets teams scope, revoke, and audit access without turning every server into a bespoke credential island. The practitioner conclusion is that registry ecosystems should be designed around consent-driven access, not static secrets.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: What should IAM teams do when a tool ecosystem still relies on API keys?
A: IAM teams should classify API key use as standing privilege and decide whether it is a transitional exception or a permanent exception. If it is unavoidable, they need rotation, storage controls, and offboarding checks. If OAuth is available, it should become the preferred path because it better matches lifecycle governance.
👉 Read our full editorial: MCP registry discovery needs OAuth to make access governable
