Ahora con autenticación

La autorización en MCP es opcional. Si la implementas sobre HTTP, deberías seguir esta especificación; con STDIO no deberías hacerlo: ahí las credenciales se toman del entorno.

Se apoya en OAuth 2.1 y en un conjunto de RFC: 6750 (bearer), 8414 (metadatos del servidor de autorización), 8707 (indicadores de recurso) y 9728 (metadatos de recurso protegido).

Los papeles

Tu servidor MCP protegido es el resource server de OAuth 2.1. El cliente MCP es el cliente. El authorization server emite los tokens y puede ser una entidad separada.

El desafío

Todo empieza con un 401:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

El servidor MCP DEBE implementar RFC 9728 (Protected Resource Metadata), y el cliente DEBE usarla para descubrir el servidor de autorización.

El parámetro resource

El cliente DEBE enviar el parámetro resource de RFC 8707 en la petición de autorización y en la de token, con la URI canónica del servidor MCP. https://mcp.example.com/mcp es válida; mcp.example.com (sin esquema) y https://mcp.example.com#fragment (con fragmento) no lo son.

Del lado del servidor

El token va en Authorization: Bearer <access-token> en cada petición, y nunca en la cadena de consulta. El servidor DEBE validar que el token fue emitido para él como audiencia, y NO DEBE aceptar ni retransmitir otros tokens.

Los códigos

401 autorización requerida o token inválido · 403 permisos o alcances insuficientes · 400 petición mal formada. Ante alcances insuficientes se responde 403 con error="insufficient_scope" y el scope necesario.