auth: Configurable OIDC authentication method

[domdomegg]

Summary

Add a configurable OIDC authentication method that allows deployers to configure OIDC login with environment variables, enabling integration with any OIDC provider.

Motivation

1. 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.
2. 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 patterns

Expected Claims

The implementation should extract standard OIDC claims:

• sub (subject) - unique user identifier
• email - user email address
• iss (issuer) - must match configured issuer
• aud (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)

[domdomegg]

@tadasant @toby would love your feedback/thoughts on doing this to unblock admin management endpoints?

[tadasant]

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)