Also see #264
People will probably want to publish to the registry from CI environments. DNS auth can work here fine (#270). But for people who haven't set up DNS, the standard GitHub device flow won't really work here. We could make this nice by supporting GitHub Actions OIDC.
The registry would expose a /v0/auth/github-oidc endpoint that accepts GitHub's OIDC tokens directly. When a GitHub Action wants to publish, it would request an OIDC token from GitHub (using the built-in ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL - see here for more details), configured with aud: "mcp-registry" or similar. The action would then pass this token to the registry's /v0/auth/github-oidc endpoint.
The registry would validate the token using GitHub's public keys (from https://token.actions.githubusercontent.com/.well-known/openid-configuration / https://token.actions.githubusercontent.com/.well-known/jwks), verify the issuer is https://token.actions.githubusercontent.com, and check the audience matches mcp-registry. From the validated claims, it would extract the repository field (e.g., "octo-org/octo-repo") and grant publish permissions for the corresponding namespace - e.g. io.github.octo-org (or possibly io.github.octo-org/octo-repo - not sure what is most sensible here).
The registry would then issue its own short-lived JWT with appropriate publish permissions, just like with the other auth flows.
Also see #264
People will probably want to publish to the registry from CI environments. DNS auth can work here fine (#270). But for people who haven't set up DNS, the standard GitHub device flow won't really work here. We could make this nice by supporting GitHub Actions OIDC.
The registry would expose a /v0/auth/github-oidc endpoint that accepts GitHub's OIDC tokens directly. When a GitHub Action wants to publish, it would request an OIDC token from GitHub (using the built-in ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL - see here for more details), configured with aud: "mcp-registry" or similar. The action would then pass this token to the registry's
/v0/auth/github-oidcendpoint.The registry would validate the token using GitHub's public keys (from https://token.actions.githubusercontent.com/.well-known/openid-configuration / https://token.actions.githubusercontent.com/.well-known/jwks), verify the issuer is https://token.actions.githubusercontent.com, and check the audience matches
mcp-registry. From the validated claims, it would extract the repository field (e.g., "octo-org/octo-repo") and grant publish permissions for the corresponding namespace - e.g. io.github.octo-org (or possibly io.github.octo-org/octo-repo - not sure what is most sensible here).The registry would then issue its own short-lived JWT with appropriate publish permissions, just like with the other auth flows.