Autorización en MCP: según la especificación vigente, primero responde «¿quién eres?»

Introducción

MCP (Model Context Protocol) es el cableado estándar entre las aplicaciones de IA y las herramientas externas: un host MCP (como Claude Code, Claude Desktop o VS Code) crea un cliente por cada servidor MCP, y los servidores exponen tres primitivas —tools, resources, prompts. Este artículo examina su modelo de autorización según la especificación oficial vigente de autorización de MCP (versión 2026-07-28; verificado el 6 de octubre de 2026 que /specification/latest redirige aquí). (Análisis de producto a 6 de octubre de 2026.)[1]

[1] [2]

La autorización sigue siendo opcional

La especificación vigente: Authorization is OPTIONAL. Las implementaciones que usan HTTP SHOULD seguir esta especificación; los servidores locales que usan STDIO SHOULD NOT seguir este flujo OAuth, y en su lugar obtienen las credenciales del entorno. Nótese que es SHOULD NOT, no técnicamente imposible: que lo local sea seguro depende del aislamiento de procesos y la custodia de credenciales, que la especificación deja a los implementadores.[2]

[2]

Tres roles

La especificación vigente establece una sección «Roles» con tres partes: el servidor MCP protegido es el resource server de OAuth 2.1; el cliente MCP es el client de OAuth 2.1, que realiza solicitudes de recursos protegidos en nombre de un resource owner; el authorization server interactúa con el usuario cuando es necesario y emite access tokens, y puede estar alojado con el resource server o como entidad separada — sus detalles de implementación están fuera del alcance de esta especificación. «Quién emite los tokens» y «quién los recibe» quedan formalmente separados.[2]

[2]

Binding de resource y audience

La especificación vigente exige que los clientes implementen Resource Indicators según RFC 8707: el parámetro resource MUST aparecer tanto en las solicitudes de autorización como en las de token, identificando la URI canónica del servidor MCP para el que es el token; el servidor, como resource server, MUST verificar que los access tokens fueron emitidos específicamente para él como audience prevista, aceptando solo tokens emitidos por su propio authorization server para sus propios recursos, y MUST NOT aceptar ni transitar ningún otro token. Tokens ligados a recursos: un token, un lugar.[2]

[2]

DCR obsoleto

En la especificación vigente, el registro dinámico de clientes (DCR) está obsoleto y se conserva solo por compatibilidad; los authorization servers y clientes MCP SHOULD soportar OAuth Client ID Metadata Documents. Antes de iniciar el flujo de autorización, los clientes MUST obtener un client ID por uno de tres mecanismos —Client ID Metadata Documents, prerregistro o DCR— en el orden de prioridad definido por la especificación.[2]

[2]

Desafíos de scope y step-up

La especificación vigente detalla el tratamiento de permisos insuficientes: los servidores MAY incluir un parámetro scope en la cabecera WWW-Authenticate del 401 guiando los permisos requeridos; cuando un token es rechazado por scope insuficiente, el servidor SHOULD responder 403 con insufficient_scope — nótese que este es el caso de scope insuficiente; los tokens inválidos o expirados siguen recibiendo 401. El cliente se reautoriza con un conjunto mayor de scopes vía el flujo step-up y reintenta.[2]

Hay que distinguir dos «humanos» distintos: la reautorización step-up ejecuta el flujo de autorización OAuth, que los clientes que actúan en nombre de un usuario SHOULD intentar según la especificación — y ese flujo puede requerir interacción del usuario; el protocolo de autorización permite y en algunos casos exige autorización interactiva. Pero eso no es lo mismo que «aprobación humana obligatoria para cada llamada a herramienta». Lo primero es un mecanismo dentro del protocolo de autorización; lo segundo es política de llamadas del host. No son lo mismo.[2]

[2]

El handshake 401

Cuando se requiere autorización y el cliente aún no la ha demostrado, el servidor responde HTTP 401 y el cliente inicia entonces el flujo OAuth 2.1; los tokens viajan en la cabecera Authorization, nunca en el query string de la URI (requisito de la Sección 5 de OAuth 2.1 citado por la especificación vigente). Los clientes comparan exactamente cualquier iss recibido con el issuer registrado; solo deben rechazar la ausencia de iss cuando el servidor de autorización declara que lo admite (RFC 9207).[2]

[2]

La respuesta empresarial

La extensión empresarial (con versionado independiente) convierte el IdP de la organización en el decisor autoritativo: los empleados inician sesión una vez y el IdP decide a qué servidores MCP pueden acceder según la política organizacional; según la documentación de la extensión, en los despliegues que implementan y soportan la extensión, la revocación ocurre una vez en la capa IdP, con efecto inmediato en todos los clientes. Sin pruebas prácticas de implementaciones; no se garantiza que todos los despliegues MCP se comporten así. La autorización individual es razonable para consumidores; en empresas crea fricción y brechas.[3]

[3]

Comentario

1. El protocolo solo estandariza el handshake, no la política. La sección «Roles» deja explícitamente la implementación del authorization server fuera del alcance — MCP ni siquiera decide «quién emite los tokens». Es un diseño honesto: al evaluar un despliegue, mire el lado del authorization server, no el cable.

2. La obsolescencia de DCR muestra un protocolo que converge. El paso de «registrar dinámicamente todo» a «declarar primero los metadatos de identidad» traslada la confianza de la negociación en tiempo de ejecución a la declaración en el registro. La conveniencia cede ante la auditabilidad: la trayectoria típica de un protocolo que madura.

3. «En nombre de quién» sigue siendo el origen. La especificación vigente mantiene la distinción en su sección step-up: «clientes que actúan en nombre de un usuario» frente a «clientes client_credentials» siguen flujos distintos [2]. Actuar suplantando a un usuario frente a actuar como la propia aplicación implican lógicas de auditoría y revocación completamente distintas: pregunte esto primero, luego los scopes.

4. El protocolo de autorización no es aprobación por acción. Los desafíos de scope y el step-up son mecanismos de permisos dentro del protocolo, y el step-up puede implicar interacción del usuario; pero «aprobación humana obligatoria para cada llamada» es otro asunto, de la política del host. Al diseñar un pipeline de publicación con agentes, la capa de protocolo («puede usarse este token») y la de políticas («se aprueba esta llamada») deben separarse — igual que redacción, revisión y firma nunca deben ser las mismas manos.

5. Cuatro preguntas para profesionales (especificación vigente). ¿Quién es el authorization server (junto al resource server o independiente)? ¿Se aplica realmente el binding de resource/audience? ¿Cuál es la estrategia de desafíos de scope del servidor (cómo se usa el 403)? ¿Cuál de los tres mecanismos de registro de clientes se usa? Si no puede responder, no conecte aún datos de producción.

[2]

Lo que aún no puede afirmarse

Con qué completitud hosts y clientes implementan la especificación vigente (no probado en la práctica);

El progreso real de la obsolescencia de DCR;

La postura real de seguridad de servidores MCP concretos (según su propia documentación y auditorías).