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:
parent
da835059b3
commit
32b37e71f8
3 changed files with 30 additions and 2 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
|
|||
26
docs/reference/api/registry-authorization.md
Normal file
26
docs/reference/api/registry-authorization.md
Normal 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.
|
||||
Loading…
Reference in a new issue