Repository navigation
Closed
Labels
implementation workShovel-ready to write codeShovel-ready to write code
Description
Summary
Add a configurable OIDC authentication method that allows deployers to configure OIDC login with environment variables, enabling integration with any OIDC provider.
Motivation
- Admin access for @modelcontextprotocol.io accounts: We need a way for people to get admin permissions for management endpoints ("Admin" panel for the official registry API #182). This could enable doing this with @modelcontextprotocol.io Google Cloud Identity accounts.
- Flexibility for other deployments: While not a primary goal, making the codebase more generic allows others to deploy their own registries with their preferred OIDC provider.
Proposed Solution
Add a new OIDC endpoints to enable an OIDC flow:
/v0/auth/oidc/start, which constructs an auth URL with required OIDC parameters (client_id, redirect_uri, scope, state, nonce) and redirects user to the identity provider's authorization endpoint/v0/auth/oidc/callback, which receives the authorization code from the identity provider, exchanges code for tokens via backchannel POST to token endpoint and validates the ID token (signature, issuer, audience, expiry, nonce)
I'm not quite sure what's best to do on the callback - maybe it could do two things:
- If no redirect set in start, it just displays the registry token for easy copy paste into tools (this could change to redirecting to the signed-in UI at a much later date if/when we have a frontend)
- If redirect set, redirect with the registry token to that. This could then be something like localhost:, which could enable CLI tools like publisher (/ a new special tool for admin purposes) to get the token.
Alternative: just have /v0/auth/oidc to exchange the oidc id token for a registry token. And then have some separate frontend/tool responsible for getting the id token.
Configuration (Environment Variables)
# OIDC Provider Configuration
MCP_REGISTRY_OIDC_ENABLED=true
MCP_REGISTRY_OIDC_ISSUER=https://accounts.google.com # any OIDC that provides a `.well-known/openid-configuration`
MCP_REGISTRY_OIDC_AUDIENCE=mcp-registry
# Require special claims (this feels a little jank, open to suggestions about how we format this better...)
MCP_REGISTRY_OIDC_EXTRA_CLAIMS=[{"hd":"modelcontextprotocol.io"}]
# Some Permission Configuration (this feels a little jank, open to suggestions about how we format this better...)
MCP_REGISTRY_OIDC_EDIT_PERISSIONS=*
MCP_REGISTRY_OIDC_PUBLISH_PERISSIONS=* # Or grant specific patternsExpected Claims
The implementation should extract standard OIDC claims:
sub(subject) - unique user identifieremail- user email addressiss(issuer) - must match configured issueraud(audience) - must match configured audience
Related Issues
- Unblocks "Admin" panel for the official registry API #182 (admin management surface)
- Builds on auth: redesign proposal #264 (auth redesign)
- Follows pattern from auth: GitHub Actions OIDC #271 (GitHub OIDC)
Reacted by Tadas Antanavicius
Metadata
Metadata
Assignees
Labels
implementation workShovel-ready to write codeShovel-ready to write code
Activity
domdomegg commentedon Aug 19, 2025
@tadasant @toby would love your feedback/thoughts on doing this to unblock admin management endpoints?
tadasant commentedon Aug 20, 2025
This seems reasonable to me, no objection to proceeding with implementation
(I think it's fine if the initial implementation is janky with some raw copy/paste workflow; will only be used "internally" anyway)
feat: implement OIDC authentication for admin users (#316)
feat: add admin edit endpoint for server moderation (#315)