Arquitectura de autorización MCP para empresas: un diseño de referencia multi-tenant

La especificación del Model Context Protocol por fin dice algo concreto sobre autorización: usar OAuth 2.1, vincular cada token a una audiencia específica con resource indicators y no reenviar nunca un token del cliente a una API downstream. Los requisitos son reales. El problema es que están repartidos entre la especificación central, un documento de buenas prácticas de seguridad y media docena de RFC del IETF, y casi toda página que rankea para estos términos es una checklist de un proveedor de seguridad que se detiene en el caso de un solo servidor.

Este es el diseño de referencia que usamos cuando un cliente necesita un servidor MCP que sirva a más de un tenant, se conecte a un proveedor de identidad empresarial y sobreviva a una revisión de seguridad de compras. Es neutral respecto al proveedor, se volvió a comprobar el 2 de septiembre de 2026 contra la revisión 2026-07-28 y dibuja toda la frontera de confianza, del proveedor de identidad al plano de datos por tenant. Escrito a partir del trabajo de Wavect en productos de IA y endurecimiento de seguridad.

Esta página implementa la capa de autorización MCP. Si todavía decides si MCP puede ser el límite, empieza por por qué MCP no es un límite de seguridad y cómo el control a nivel de datos cierra la brecha.

Quién es responsable de qué: el servidor MCP es un resource server, no un authorization server

El error más común es construir el servidor MCP como su propio sistema de login. No lo es. Bajo la especificación actual, el servidor MCP es un resource server de OAuth 2.1. Su trabajo es validar tokens, no emitirlos. Un authorization server aparte, que en una empresa es tu proveedor de identidad (Entra ID, Okta, Auth0, Keycloak, Ping), interactúa con el usuario y emite los tokens de acceso.

Esta separación es reciente. La primera especificación de autorización (2025-03-26) esperaba que el servidor MCP actuara como authorization server y resource server a la vez. La revisión 2025-06-18 separó los roles mediante la pull request 284, lo que permite integrar limpiamente proveedores de identidad empresariales. El authorization server aún puede estar junto al resource server, pero la responsabilidad obligatoria del servidor MCP es validar tokens. Acierta con este modelo de roles y todo lo demás encaja. Fállalo y reconstruyes identidad, mal.

¿Qué exige realmente la especificación actual?

Dos advertencias antes de la tabla. Primera, la autorización en MCP es opcional y está definida para transportes basados en HTTP. Un servidor con STDIO no debería seguir esta especificación de autorización; toma las credenciales del entorno. Segunda, OAuth 2.1 sigue siendo un borrador del IETF, no un RFC publicado, así que no cites un número de RFC para él. Esta es la superficie de estándares de la revisión 2026-07-28.

La revisión 2026-07-28 declara formalmente obsoleto Dynamic Client Registration a favor de Client ID Metadata Documents, vincula las credenciales de cliente guardadas al issuer del authorization server que las creó y añade la validación del issuer en la respuesta de autorización según RFC 9207. PKCE sigue siendo obligatorio: los clientes deben comprobar code_challenge_methods_supported antes de continuar y usar S256 cuando sea técnicamente posible.

¿Cómo funciona el flujo de autorización de principio a fin?

Todo el handshake es un paso de descubrimiento seguido de un authorization code flow estándar. El cliente llega al servidor sin token, le dicen dónde autenticarse, se autentica y vuelve con un token acuñado para este servidor concreto.

Dos detalles obligatorios viven dentro de ese diagrama. El servidor debe exponer Protected Resource Metadata de RFC 9728 mediante una cabecera WWW-Authenticate en una respuesta 401 Unauthorized o en una URI well-known. Los clientes deben soportar ambos mecanismos, usar la URL de la cabecera cuando exista y, si no, probar primero la URI específica del endpoint y luego la de la raíz. En las peticiones de autorización y token, el cliente debe enviar un parámetro resource con la URI canónica del servidor MCP, aunque el authorization server no anuncie soporte.

¿Por qué se prohíbe el token passthrough y cómo validas la audiencia?

Este es el corazón de seguridad de la especificación, y es donde fallan la mayoría de los servidores caseros. La regla es contundente: el servidor MCP debe validar que cada token de acceso se emitió para él como audiencia prevista, y debe rechazar cualquier otra cosa. No debe aceptar un token acuñado para otro servicio ni reenviar el token que recibió a una API downstream. Ese último antipatrón es el token passthrough, y la especificación lo prohíbe sin rodeos.

La razón es el problema del confused deputy. Si tu servidor acepta y reenvía tokens que no verificó, un token filtrado o emitido para un servicio se convierte en llave maestra de otro, se saltan los rate limits basados en audiencia y el rastro de auditoría downstream muestra la identidad equivocada. Validar la audiencia es una comprobación de un claim, y es la línea entre un resource server y una responsabilidad legal.

on every tool call:
  token = bearer_from_authorization_header()   # every request is self-contained
  claims = verify_signature(token, jwks_of(trusted_issuer))
  assert claims.iss == expected_issuer          # pinned per tenant
  assert this_server_uri in claims.aud          # RFC 8707 audience
  assert not expired(claims) and not before(claims)
  assert required_scope_for(tool) in claims.scope
  tenant = claims["tenant"] or claims["org_id"]
  enforce_tenant(tenant)                         # every query, every secret

El núcleo 2026-07-28 eliminó el handshake del protocolo y Mcp-Session-Id. Cada petición es autocontenida y la especificación de autorización exige el bearer token en cada petición HTTP. El pseudocódigo presupone access tokens JWT porque este diseño usa claims verificados; MCP no exige JWT. Con tokens opacos, obtén un contexto equivalente y verificado de issuer, audiencia, scope y tenant mediante introspección o un gateway de confianza.

¿Cómo llega el servidor a las APIs downstream sin filtrar el token?

Si el servidor MCP necesita llamar a una API downstream, actúa como cliente OAuth ante esa API y usa un token aparte emitido para ella. La especificación te dice qué no hacer (no reenviar el token entrante) pero deja el cómo al ecosistema. Una opción estandarizada es el token exchange, definido en RFC 8693: el servidor cambia el token entrante, cuya audiencia es el servidor MCP, por un token nuevo cuya audiencia es la API downstream.

El servidor juega aquí un doble rol: resource server ante el cliente, cliente OAuth ante la API. Prefiere la delegación a la suplantación, para que el usuario original quede en el claim sub y la cadena de actuación quede registrada en el claim act, que es lo que mantiene honesto tu rastro de auditoría a través del salto. El token exchange y los flujos on-behalf-of quedan fuera de la especificación central de MCP, así que trátalos como responsabilidad del proveedor de identidad o del gateway, no como un requisito de MCP.

¿Cómo es la arquitectura de referencia multi-tenant?

Esta es la topología. Un proveedor de identidad emite tokens vinculados a una audiencia, con un realm por tenant. Los clientes presentan esos tokens a un resource server o gateway compartido dentro de la frontera de confianza empresarial. El servidor valida la audiencia, aplica el scope por herramienta, fija el realm del tenant y solo entonces llega a herramientas, datos y APIs downstream, cada uno aislado por tenant.

El error en la mayoría de los textos multi-tenant es tratar el aislamiento como un asunto de base de datos. No lo es. La multitenencia hay que aplicarla en cada capa, y la identidad del tenant sale de un claim de token verificado, nunca de una entrada de herramienta que el modelo pueda influir. La tabla de abajo es la checklist que recorremos por capa.

"La identidad del tenant es un claim de token verificado. En el momento en que sale de un argumento de herramienta que el modelo puede escribir, tu aislamiento es puro teatro."

¿Cómo funcionan los scopes por herramienta y la autorización step-up?

El protocolo central gestiona los scopes a nivel de OAuth, no por herramienta individual, así que la autorización por herramienta real la construyes encima. La especificación te da las primitivas. Empieza en mínimo y evita scopes ómnibus como all o full-access. Cuando una herramienta necesita más de lo que concede el token actual, el servidor debería devolver 403 con WWW-Authenticate: Bearer error="insufficient_scope", todos los scopes requeridos para la operación actual y la URI resource_metadata. Un cliente que actúa por un usuario debería solicitar la unión de esos scopes y los solicitados anteriormente, y limitar sus reintentos.

En la práctica mapeamos grupos del proveedor de identidad y roles SCIM a scopes, y luego condicionamos cada herramienta a un scope requerido. Un rol de analista lleva invoices:read y ve las herramientas de lectura; nunca lleva ledger:write. Es la misma disciplina que aplicamos en una revisión de autorización, y es lo que un equipo de compras de verdad prueba.

¿Cómo añades SSO empresarial a un servidor MCP?

Hay dos formas, y la elección determina la mayor parte de tu coste operativo.

La primera es OAuth por servidor: cada servidor MCP apunta su metadata authorization_servers al proveedor de identidad corporativo. Limpio para uno o dos servidores, repetitivo a escala de flota. La segunda es un gateway MCP: una única entrada con políticas aplicadas delante de cada servidor, que centraliza descubrimiento, validación de tokens, mapeo de scopes, token exchange y auditoría. Para una empresa con muchos servidores y muchos tenants, el gateway suele ser la respuesta correcta porque te da un solo sitio donde aplicar el aislamiento y un solo sitio donde auditar.

Sobre protocolos: la revisión 2026-07-28 exige que el authorization server proporcione metadata RFC 8414 u OpenID Connect Discovery; los clientes deben soportar ambos mecanismos de descubrimiento. Protected Resource Metadata puede enumerar varios authorization servers. El cliente elige uno y debe mantener credenciales y tokens separados por issuer. En MCP no hay un flujo SAML nativo. Una empresa solo-SAML hace de puente mediante su proveedor de identidad o un broker que expone OAuth u OIDC para el servidor MCP.

¿Cómo gobiernas el registro de clientes y los tiempos de vida de las credenciales?

La revisión 2026-07-28 declara formalmente obsoleto Dynamic Client Registration. Los clientes que soportan todas las opciones deberían preferir credenciales preregistradas, luego Client ID Metadata Documents si el authorization server anuncia soporte, DCR solo como fallback retrocompatible y, por último, información de cliente introducida por el usuario. Las credenciales preregistradas o obtenidas mediante DCR deben quedar vinculadas al issuer que las creó y no reutilizarse con otro authorization server. Los authorization servers que obtienen Client ID Metadata Documents deberían mitigar SSRF, validar exactamente las redirect URIs y advertir claramente sobre redirects solo a localhost. Las empresas deberían vincular el registro a un tenant y pasar clientes desconocidos por revisión administrativa.

La especificación MCP actual dice que los authorization servers deberían emitir access tokens de vida corta, deben rotar refresh tokens para clientes públicos y pueden no emitir refresh tokens. Los clientes deben protegerlos en tránsito y almacenamiento, mantener los access tokens fuera de los query strings y enviar el bearer token en cada petición HTTP. Valores concretos que usamos como punto de partida:

¿Qué eventos de auditoría debes capturar?

La especificación central no tiene un requisito propio de logging de auditoría, pero el análisis del token passthrough construye el argumento por ti: el passthrough rompe el rastro de auditoría porque los logs downstream muestran la identidad equivocada. En un sistema multi-tenant, la auditoría es cómo demuestras que el aislamiento aguantó. Registra estos, por tenant, con un correlation ID que sobreviva al salto downstream.

• Resultados de validación de tokens: aceptado, rechazado por audiencia, rechazado por issuer, caducado.
• Decisiones de autorización: herramienta invocada, scope requerido, scope concedido, allow o deny.
• Eventos de step-up: scope solicitado y el subconjunto concedido.
• Token exchange: qué audiencia downstream se acuñó, para qué subject y qué actor.
• Contexto de tenant: el claim de tenant verificado en cada entrada, para que una consulta sea atribuible a un tenant, un usuario y una herramienta.

Por servidor, gateway o identidad gestionada: ¿cuál eliges?

Una matriz de decisión rápida para las tres topologías viables.

Pasar de un servidor de un solo tenant a uno multi-tenant no es una reescritura si lo secuencias: primero introduce el claim de tenant y fija el issuer, mueve los secretos a un vault por tenant, añade row-level security basada en el claim, luego filtra la visibilidad de herramientas y enciende la auditoría por tenant. Cada paso se puede entregar y probar por su cuenta. Prueba el aislamiento de forma adversaria: reproduce el token del tenant A contra los datos del tenant B y confirma que se rechaza en la capa de token, no solo que se filtra en la capa de consulta.

Fuentes y lecturas adicionales

• Model Context Protocol, Authorization specification (2026-07-28 revision)
• Model Context Protocol, Authorization server discovery
• Model Context Protocol, Client registration
• Model Context Protocol, Authorization security considerations
• Model Context Protocol, 2026-07-28 specification release
• Model Context Protocol, Authorization specification (2025-06-18 revision)
• MCP pull request 284, separating the resource server and authorization server roles
• RFC 9728, OAuth 2.0 Protected Resource Metadata
• RFC 8707, Resource Indicators for OAuth 2.0
• RFC 8414, OAuth 2.0 Authorization Server Metadata
• RFC 9207, OAuth 2.0 Authorization Server Issuer Identification
• RFC 7591, OAuth 2.0 Dynamic Client Registration
• OAuth Client ID Metadata Document (IETF draft)
• OpenID Connect Discovery 1.0
• RFC 8693, OAuth 2.0 Token Exchange
• RFC 9068, JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
• RFC 6750, OAuth 2.0 Bearer Token Usage
• OAuth 2.1 Authorization Framework (IETF draft)