Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[proposal] Add auth as a capability with support for OAuth 2.0 and secrets. #101

Closed
wants to merge 8 commits into from
Closed
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 81 additions & 0 deletions docs/specification/auth/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
---
title: Authentication
type: docs
weight: 50
---

{{< callout type="info" >}}
**Experimental Section!**
{{< /callout >}}
k6l3 marked this conversation as resolved.
Show resolved Hide resolved

The Model Context Protocol (MCP) provides a standardized way for clients and servers to establish secure communication channels. The authentication framework supports multiple authentication methods to accommodate different security requirements and use cases.

## User Interaction Model

Authentication in MCP is designed to be flexible and secure, supporting various authentication flows that may require different levels of user interaction:

- OAuth 2.0 for standardized authorization flows
- Credential-based authentication for API keys and similar secrets

k6l3 marked this conversation as resolved.
Show resolved Hide resolved
## Capabilities

Clients that support authentication **MUST** declare their supported authentication methods during [initialization]({{< ref "/specification/basic/lifecycle#initialization" >}}):
k6l3 marked this conversation as resolved.
Show resolved Hide resolved

```json
{
"capabilities": {
"auth": {
"oauth2": true,
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
"credential": true,
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
}
}
}
```

The `auth` capability can include any combination of the following authentication methods:

- `oauth2`: Indicates support for [OAuth 2.0]({{< ref "/specification/auth/oauth2" >}}) authentication flows
- `credential`: Indicates support for [credential-based]({{< ref "/specification/auth/credential" >}}) authentication

k6l3 marked this conversation as resolved.
Show resolved Hide resolved
## Server Response

Servers that support authentication **MUST** include their supported authentication methods in their initialization response:

```json
{
"capabilities": {
"auth": {
"oauth2": {
"token": true,
"revoke": true
},
"credential": {
"list": true
},
}
}
}
```

k6l3 marked this conversation as resolved.
Show resolved Hide resolved
## Security Considerations

1. Clients **MUST**:
- Store and manage authentication tokens and credentials securely
- Implement proper token refresh and revocation flows where applicable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would move this into the guidelines below and change to SHOULD, because a client that doesn't do these is still workable, it will just get de-authed frequently.

Or maybe it's more like:

  • MUST implement a flow to allow users to revoke their token
  • SHOULD implement automatic token refresh

k6l3 marked this conversation as resolved.
Show resolved Hide resolved
- Validate server authenticity before sending credentials
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
- Monitor authentication state and handle expiration
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
k6l3 marked this conversation as resolved.
Show resolved Hide resolved

2. Servers **MUST**:
- Implement proper security measures for storing and managing secrets
- Provide clear error messages for authentication failures
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be better as SHOULD, because I could conceive of server implementations where indicating an authentication failure exposes too much information. (Similar in principle to why private GitHub repos you can't access return 404 rather than 403/401.)

k6l3 marked this conversation as resolved.
Show resolved Hide resolved

## Implementation Guidelines

1. Clients **SHOULD**:
- Prompt users for consent before initiating authentication flows
- Provide clear user interfaces for authentication management
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
- Handle authentication errors gracefully

2. Servers **SHOULD**:
- Provide clear documentation for authentication requirements
- Implement proper logging and monitoring
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
119 changes: 119 additions & 0 deletions docs/specification/auth/credential.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,119 @@
---
title: Credential Authentication
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this term is too ambiguous, since don't all forms of "client giving details to the server" (including OAuth) involve some kind of credentials?

What about "token authentication" or "bearer authentication" or something like that? Neither is quite expansive enough (e.g., to include use cases like providing a raw password), but that might be OK.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no strong feelings about naming; my take is that OAuth is a fancy wrapper on top of this. Let's see if anyone is an advocate for a particular name and I can go rename the file + references to "credential".

type: docs
weight: 52
---

{{< callout type="info" >}}
**Protocol Revision**: {{< param protocolRevision >}}
{{< /callout >}}
k6l3 marked this conversation as resolved.
Show resolved Hide resolved

The Model Context Protocol (MCP) supports credential-based authentication for scenarios requiring API keys or similar secrets.

## Capabilities

Clients supporting credential authentication **MUST** declare it during initialization:

```json
{
"capabilities": {
"auth": {
"credential": true
}
}
}
```

Servers supporting credentials **MUST** include their capabilities:

```json
{
"capabilities": {
"auth": {
"credential": {
"list": true
}
}
}
}
```

## Protocol Messages

### Credential Requirements

Servers can list required credentials using the credential/list capability:
k6l3 marked this conversation as resolved.
Show resolved Hide resolved

```json
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"credential": [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: probably obviated if we rename per my comment above, but if we keep as-is, I think this should be plural:

Suggested change
"credential": [
"credentials": [

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving unresolved until naming is settled

{
"name": "X-API-KEY",
"description": "An API key must be provided to call this tool."
},
{
"name": "X-MISC-PASSWORD",
"description": "A password must be provided to list this resource"
}
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
]
}
}
```

### Providing Credentials

Clients provide credentials through headers during initialization:
k6l3 marked this conversation as resolved.
Show resolved Hide resolved

```json
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"capabilities": {
"auth": {
"credential": true
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
}
},
"headers": {
"X-API-KEY": "api_key",
"X-MISC-PASSWORD": "password"
}
}
}
```

## Error Handling

When credentials are missing or invalid, servers **SHOULD** respond with:

```json
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": 32004,
"message": "See required configuration",
"data": {
"requiredConfiguration": [
{
"name": "X-API-KEY",
"description": "An API key must be provided to call this tool."
}
]
}
}
}
```
k6l3 marked this conversation as resolved.
Show resolved Hide resolved

## Security Considerations

1. Clients **MUST**:
- Securely obtain/store credentials
- Only transmit credentials over secure channels

2. Servers **MUST**:
- Maintain secure storage of credentials if needed
k6l3 marked this conversation as resolved.
Show resolved Hide resolved
Loading
Loading