MCP y OAuth 2.1: la validación de aud separa una demo de una brecha
La especificación de autorización de MCP añade a OAuth 2.1 tres exigencias que muchos despliegues se saltan: descubrimiento del servidor de autorización, PKCE obligatorio y tokens atados a una audiencia.
Que un servidor MCP valide la firma de un token no significa que sea seguro. El punto donde fallan más despliegues no es la criptografía, sino la comprobación de la audiencia: en montajes multi-tenant, un token emitido para un servidor acaba sirviendo contra otro. La receta incluye descubrimiento del servidor de autorización, PKCE obligatorio y separación estricta entre token y sesión.
Descubrimiento y audiencia
La especificación de autorización de MCP se apoya en OAuth 2.1, pero añade restricciones que muchas implementaciones se saltan. En producción, el servidor MCP actúa como servidor de recursos: valida tokens, no los emite. El cliente no debe llevar la URL del servidor de autorización hardcodeada; la descubre leyendo el documento de metadatos de recurso protegido (RFC 9728), publicado en /.well-known/oauth-protected-resource. Ese JSON incluye el campo resource, la URL del servidor MCP, que después se contrasta con el claim aud del token.
PKCE no es opcional: los clientes MCP suelen ser clientes públicos (herramientas de línea de comandos, aplicaciones de escritorio) incapaces de guardar un secreto de cliente. El code_verifier se genera en el cliente y viaja como code_challenge con SHA-256. Y en la petición de autorización va el parámetro resource (RFC 8707), el que indica al servidor de autorización qué audiencia debe grabar en el token. Sin él, un token emitido hoy puede reutilizarse mañana contra otro servidor MCP.
Validar de verdad
Validar un token son cuatro comprobaciones, no una: firma o introspección; que el aud coincida con la URL del recurso; las fechas exp y nbf; y que los scopes cubran la herramienta solicitada. La firma la resuelven las librerías, y la de audiencia es justo la que se olvida, porque obliga a tener claro cuál es la identidad propia del servidor de recursos. Eso implica haber hecho antes el paso del documento de metadatos.
Token no es sesión
Un token válido dice quién llama; no dice en qué estado va su sesión MCP. Mezclarlos produce fallos donde un refresco de token reinicia sin avisar un flujo de varias llamadas a herramientas. El token es corto (entre 15 y 60 minutos), lleva identidad y scopes, y se valida en cada petición. La sesión vive en el servidor, indexada por un ID que el cliente envía junto al token, con su propio TTL y su tiempo de inactividad, independientes de la vida del token. Cuando el token caduca, se renueva sin tocar la sesión. Cuando caduca la sesión, hace falta un nuevo ciclo de autorización aunque el token siga vigente: una sesión inactiva es más superficie de riesgo que un token rotado.
El caso que se ve de verdad: un equipo valida firma y expiración, da el trabajo por hecho, y meses después descubre que un token del servidor MCP de analítica interna también entra en el que mira al cliente, porque nadie comprobó el aud. No es un supuesto teórico. Es exactamente el hueco que cierran el parámetro resource y la validación de audiencia.
