Add registry authorization specification (#756)

Add a standardized OAuth 2.1-based authentication specification for MCP
sub-registries, aligned with the MCP Authorization Specification.

This enables:
- Private registry entries with access control
- Permission-based server visibility
- Client code reuse (clients can use their existing MCP auth
implementation)

The spec is intended for downstream sub-registries. The official
registry remains public for reading.

Fixes #751

---------

Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
adam jones 2025-11-17 19:11:07 +00:00 • committed by GitHub
commit 32b37e71f8
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 30 additions and 2 deletions

View file

@ -5,6 +5,7 @@ Technical specifications and quick lookups for the MCP Registry.
## API Reference
- [Generic Registry API](./api/generic-registry-api.md)
- [Registry Authorization](./api/registry-authorization.md)
- [Official Registry API](./api/official-registry-api.md)
## server.json Reference

View file

@ -4,6 +4,7 @@ A standardized RESTful HTTP API for MCP registries to provide consistent endpoin
Also see:
- For guidance consuming the API, see the [consuming guide](../../guides/consuming/use-rest-api.md).
- For authentication and authorization, see the [registry authorization specification](./registry-authorization.md).
## Browse the Complete API Specification
@ -22,8 +23,8 @@ The official registry has some more endpoints and restrictions on top of this. S
Server names and version strings should be URL-encoded in paths.
### Authentication
- **Read operations**: No authentication required
- **Write operations**: Registry-specific authentication (if supported)
No authentication required by default. Subregistries may optionally require authentication following the [registry authorization specification](./registry-authorization.md).
### Content Type
All requests and responses use `application/json`

View file

@ -0,0 +1,26 @@
# Registry Authorization
MCP registries wishing to implement authentication SHOULD follow the [MCP Authorization Specification](https://modelcontextprotocol.io/specification/draft/basic/authorization).
## How it works
The registry acts as an OAuth 2.1 Resource Server, identical to how MCP servers work. This means:
- **MCP clients** can reuse their existing MCP authorization implementation without any changes
- **Registries** validate access tokens the same way MCP servers do
- **Users** get a consistent login experience across MCP servers and registries
## Registry-Specific Scopes
Registries MAY use these scopes:
- `mcp-registry:read` - List and read server metadata
- `mcp-registry:write` - Publish, update, and delete servers
These are recommendations - registries may use any set of scopes they deem sensible.
Note that scopes only control what *types* of operations a user can perform. Registries should still apply user-level authorization to control which specific resources a user can access. For example, a user with `mcp-registry:write` might only be able to publish servers to namespaces they own, and may not have permissions to edit servers if the registry treats servers as immutable.
## Official Registry Authentication
The official modelcontextprotocol.io registry remains public for reading. For publishing servers, it uses a custom JWT-based authentication system for legacy reasons - see [its API spec](official-registry-api.md#authentication). This may change in future to align with the MCP Authorization Specification.