OAuth en la capa MCP: cómo resolvimos la gestión de tokens empresarial para agentes de IA

Un recorrido por la arquitectura de autenticación dentro del MCP Gateway de TrueFoundry —tres planos, dos flujos OAuth, una bóveda de credenciales— contado desde la perspectiva de un cliente que lo despliega en producción.

Un lunes por la mañana en Northwind. A las 8:47 a. m. de un lunes, el ingeniero de guardia en Northwind Logistics —una plataforma de cadena de suministro ficticia pero lamentablemente plausible de 50 ingenieros— recibe una notificación en Slack. Su asistente interno de IA, Cargo Copilot, está devolviendo errores 401 para cada llamada a las herramientas de Jira y GitHub. La causa raíz es el portátil de un desarrollador, perdido en el aeropuerto durante el fin de semana. El departamento de TI ha revocado la sesión SSO del portátil. Sin embargo, el portátil también contenía tokens OAuth para GitHub, Slack, Jira y un servicio interno de analítica, todos ellos copiados en la configuración del editor y en los dotfiles del desarrollador. El equipo de seguridad no puede confirmar con certeza qué permisos quedaron expuestos, en qué otras máquinas se duplicaron esos tokens (porque los desarrolladores se ayudan entre sí) o cómo revocarlos todos sin interrumpir la mañana de todo el equipo.

El incidente de Northwind no es algo insólito. Es el estado habitual de la gestión de credenciales en la mayoría de las empresas tras seis meses de adopción entusiasta de MCP. El resto de este artículo cuenta la historia arquitectónica de cómo Northwind —y otros clientes de TrueFoundry— evitan que este incidente se repita.

1. El problema de la proliferación de credenciales: cómo se ven realmente 50 desarrolladores × 8 servidores MCP

Northwind cuenta con aproximadamente cincuenta ingenieros que utilizan activamente IDEs compatibles con MCP conectados a ocho servidores: GitHub, Slack, Google Workspace, Jira, un servicio interno de analítica, una API interna de logística, Zendesk y un servicio propio de planificación de rutas. Eso suma cuatrocientas conexiones activas según la aritmética básica, y en la práctica sustancialmente más ubicaciones de credenciales si se contabilizan las entradas del llavero de claves, la configuración del editor, los archivos de entorno de la shell, las variables de CI y las copias que se realizan al incorporar a un compañero de equipo.

El radio de impacto de una estación de trabajo filtrada no es un solo token. Es un token multiplicado por los ámbitos asociados a ese proveedor, la duración del token (a menudo 90 días o más para los tokens de acceso personal), el número de máquinas que lo duplicaron y la ausencia de una revocación centralizada. Si un token OAuth de Slack permite la lectura del historial de canales y un token de GitHub ubicado en la misma máquina permite la lectura de repositorios, una sola filtración se convierte en un incidente multisistema antes de que el equipo de seguridad tenga la oportunidad de responder. Las credenciales MCP locales también son invisibles a nivel operativo: sin un registro de auditoría unificado, sin rotación forzada, sin verificación de directivas antes de ejecutar una herramienta y sin una forma rápida de responder quién puede llamar a qué.

El patrón gateway elimina esa brecha. Los desarrolladores se autentican una sola vez en el gateway y este gestiona la autenticación hacia los servicios de destino según el modelo configurado para cada servidor, que es exactamente el diseño descrito en la visión general del TrueFoundry MCP Gateway y en la documentación de autenticación y seguridad. El beneficio no es solo la consolidación. Es que la autenticación pasa a ser una propiedad de la infraestructura en lugar de una propiedad de cada portátil de la empresa.

2. La arquitectura de autenticación en tres planos: entrada, control de acceso y salida

La primera decisión de diseño consiste en separar tres planos que las configuraciones locales de los desarrolladores suelen mezclar. La documentación de autenticación y seguridad de TrueFoundry describe esto como un sistema de tres partes: autenticación de entrada, control de acceso y autenticación de salida. La documentación especifica con claridad que las capas de entrada y salida son independientes, lo cual constituye el gran logro arquitectónico.

• Autenticación de entrada. ¿Quién llama al gateway? TrueFoundry admite cuatro métodos: TrueFoundry API Key (PAT), Virtual Account Token, Identity Provider Token (un JWT de Okta/Auth0/Azure AD validado mediante un proveedor de identidad configurado) y TrueFoundry OAuth (utilizado por IDEs como Cursor y VS Code).
• Control de acceso. ¿Qué puede hacer la identidad resuelta? Cada servidor MCP tiene colaboradores (usuarios, equipos o cuentas virtuales) con permisos basados en roles. El alcance a nivel de herramienta se logra combinando herramientas de múltiples servidores MCP en un Virtual MCP Server, que expone únicamente un subconjunto seleccionado.
• Autenticación de salida. ¿Cómo llega el gateway a cada servidor de destino? Se admiten siete métodos: OAuth2 (Authorization Code), OAuth2 (Client Credentials), API Key (compartida), API Key (individual), No Auth, Token Passthrough y Token Forwarding a través de x-tfy-mcp-headers.

‍

El principio de diseño es sencillo: la credencial utilizada para llegar al gateway nunca es la credencial que llega a la herramienta de destino. La rotación de entrada no altera ningún estado OAuth del proveedor. Un servidor MCP de GitHub puede utilizar OAuth por usuario mientras que el servicio interno de analítica utiliza Client Credentials, dentro del mismo agente y en el mismo flujo de solicitud. El gateway actúa tanto como punto de aplicación de directivas como intermediario de credenciales.

3. 2LO frente a 3LO: cómo elegir el tipo de concesión OAuth adecuado para cada servidor MCP

En el lenguaje empresarial, 2LO y 3LO se refieren a dos tipos de concesión de RFC 6749 (OAuth 2.0), proyectados según la forma en que participan los usuarios finales.

OAuth de dos patas (2LO) utiliza la concesión Client Credentials. El gateway guarda un client_id y un client_secret, envía una solicitud grant_type=client_credentials al extremo de tokens del proveedor, recibe un access_token de corta duración y utiliza ese token en cada solicitud al servidor MCP. Sin navegador y sin consentimiento del usuario. Es la opción adecuada para integraciones entre servidores: APIs internas de analítica, microservicios de backend y servicios de datos internos.

OAuth de tres patas (3LO) utiliza la concesión Authorization Code. Cada usuario final es redirigido al proveedor (GitHub, Slack, Google) para autorizar el acceso a sus recursos específicos. El gateway almacena un refresh_token por usuario, mantiene un mapa cifrado de user_id → {access_token, expires_at, refresh_token, scopes, provider_metadata} y rota el token de acceso automáticamente.

Cómo eligió Northwind

Los ocho servidores MCP de Northwind se dividen aproximadamente a la mitad. GitHub, Slack, Jira, Google Workspace y Zendesk son herramientas por usuario: el valor de "ejecutar esto como Alice" supera la sobrecarga operativa de gestionar un token individual. Esas se configuran con 3LO. El servicio interno de analítica, la API de logística y el servicio de planificación de rutas exponen datos de toda la empresa; no tiene sentido usar OAuth por usuario, y una única concesión de Client Credentials compartida es tanto más sencilla como más fácil de auditar. Esas se configuran con 2LO.

Cómo se ve el modelo de configuración

Nota sobre esta vista de configuración

TrueFoundry registra los servidores MCP a través de la interfaz de usuario (Settings → MCP Servers → Add MCP Server) en lugar de utilizar un archivo YAML gestionado por el cliente, aunque la configuración también se puede aplicar de forma declarativa a través de tfy apply. El siguiente YAML muestra el modelo de configuración por servidor —los mismos campos que se completan en la interfaz de usuario— utilizando el esquema verificado de TrueFoundry (provider-account/mcp-server-group con integrations anidado).

El comando para aplicar el yaml anterior es:

Hay tres aspectos que destacar. En primer lugar, tfy-secret:// es el esquema de referencia FQN canónico que TrueFoundry utiliza para los secretos almacenados en un grupo de secretos de TrueFoundry, con el formato separado por dos puntos tfy-secret://<tenant>:<secret-group>:<secret-key> documentado en la guía de variables de entorno y secretos. El valor reside en su gestor de secretos (AWS SSM, GCP Secret Manager, HashiCorp Vault, Azure Key Vault); TrueFoundry resuelve el FQN en tiempo de ejecución, por lo que el archivo anterior se puede guardar de forma segura en un repositorio de Git. En segundo lugar, authorized_subjects es la lista RBAC por servidor —una mezcla de equipos y cuentas virtuales—, que es lo que permite que el mismo servidor MCP atienda a desarrolladores humanos (cuyos PATs se resuelven como pertenencia a un equipo) y a trabajos programados con cuentas de servicio (cuyos Virtual Account Tokens se asignan a sujetos virtualaccount:) sin desviaciones en la configuración. En tercer lugar, la entrada 3LO establece code_challenge_methods_supported: [S256]: hoy en día se recomienda PKCE para todos los clientes de Authorization Code y es obligatorio en la especificación MCP más reciente del 25-11-2025.

En el lado del cliente, el agente nunca enumera los modos de autenticación. Se conecta a una única URL del gateway, presenta una credencial de entrada y el gateway inyecta la credencial de salida adecuada para cada servidor:

4. Gestión del ciclo de vida de los tokens: renovación proactiva y acceso concurrente

El funcionamiento correcto de OAuth no consiste únicamente en obtener tokens. Consiste en operar con ellos de forma segura bajo cargas concurrentes. El diseño ingenuo renueva el token cuando el proveedor devuelve un error 401 o cuando now ≥ expires_at. Ese diseño funciona en demostraciones pero falla el primer lunes que se enfrenta a la realidad.

Analicemos de nuevo el incidente de Northwind con el enfoque de renovación ingenuo: a las 8:47 a. m. del lunes, cincuenta ingenieros se conectan, cada proceso detecta de forma independiente el mismo token caducado de GitHub, se realizan cincuenta llamadas POST /token en paralelo a GitHub desde el mismo gateway y GitHub aplica una limitación de frecuencia a todas ellas. Cargo Copilot devuelve errores 401 a todos los usuarios hasta que la cola se vacía.

El patrón que se mantiene firme en producción consta de dos componentes: renovar proactivamente al 80 % del TTL y serializar la renovación por (usuario, servidor) mediante un bloqueo distribuido.

Renovar al 80 % del TTL deja margen para desviaciones de reloj, reintentos, extremos de tokens lentos del proveedor y solicitudes que ya están en curso. El bloqueo por (usuario, servidor) evita un colapso por solicitudes simultáneas (thundering herd) contra el proveedor. La lectura de doble comprobación dentro del bloqueo no es algo estético: permite que la primera solicitud realice la renovación mientras que las demás reutilizan el token recién escrito.

Hay dos sutilezas importantes a escala. En primer lugar, para integraciones de Client Credentials la clave de caché es (server_id, provider_account); para integraciones de Authorization Code la clave debe incluir user_id. En segundo lugar, los proveedores que rotan los tokens de renovación en cada actualización —como hacen Google y Microsoft según su configuración— requieren que la escritura sea atómica. Si el nuevo access_token se confirma antes que el nuevo refresh_token, un fallo deja al usuario bloqueado con un token de renovación anterior invalidado y la obligación de volver a autenticarse.

5. El flujo de doble autenticación: un diagrama de secuencia completo

Con los planos separados y la ruta de renovación definida, una solicitud MCP de extremo a extremo a través del gateway adopta una estructura precisa. Siga una llamada de Cargo Copilot —"resumir las incidencias críticas abiertas en el repositorio northwind/logistics-core"— desde el agente hasta GitHub y de vuelta:

‍

Vale la pena destacar tres propiedades de este flujo. El agente nunca recibe el token de acceso de GitHub; solo el gateway lo conserva. El servidor MCP nunca ve la credencial de entrada de TrueFoundry de Northwind a menos que Token Passthrough esté configurado explícitamente (más sobre esto en la §7). Y el equipo de seguridad de Northwind obtiene una única ruta de solicitud gobernada con identidad, autorización y auditoría registradas en un solo lugar —la misma propiedad que les habría permitido responder a la pregunta del lunes por la mañana, "¿qué permisos había en ese portátil?", en menos de un minuto.

La especificación de autorización MCP refuerza un aspecto de este esquema: los tokens de acceso de portador deben enviarse en el encabezado de solicitud Authorization y nunca en una cadena de consulta URI. Esa norma es crucial precisamente porque evita que los tokens queden expuestos en los registros de acceso, el historial del navegador y las trazas de los proxies.

6. Integración con la bóveda de credenciales: por qué los secretos sin cifrar nunca tocan la memoria de la aplicación

Un gateway en producción no debe tratar los tokens de renovación de OAuth como filas ordinarias de la aplicación. Los secretos de cliente y los tokens de renovación son llaves de acceso de larga duración; filtrar un token de renovación de Slack equivale, a efectos prácticos, a filtrar todo el espacio de trabajo de Slack.

El patrón estándar es el cifrado de sobre (envelope encryption). El gateway genera una clave de cifrado de datos (DEK) aleatoria para cada registro de token, cifra el secreto de OAuth con esa DEK, cifra la DEK con una clave maestra en un KMS o gestor de secretos y almacena la DEK cifrada junto con el texto cifrado. Al leer, el gateway solicita a la bóveda descifrar únicamente la DEK y luego descifra el token dentro de un bloque de código estrictamente limitado que evita registrar o serializar texto plano.

En despliegues más estrictos, el propio intercambio de tokens se puede delegar a un sidecar o a una operación de tránsito en la bóveda, de modo que el código de la aplicación nunca reciba directamente el material de client_secret. Incluso con un cifrado de sobre básico, el radio de impacto cambia de forma sustancial: un volcado de la base de datos por sí solo es insuficiente (las DEKs no se almacenan descifradas) y es mucho menos probable que un volcado de memoria de un proceso de solicitudes general contenga material de credenciales amplio (solo se descifran las claves solicitadas recientemente y únicamente durante el tiempo que dura la solicitud).

El despliegue de Northwind utiliza AWS KMS como almacén de clave maestra y el almacén de secretos de TrueFoundry para el material cifrado. El gateway nunca lee directamente el client_secret del proveedor; lee un FQN de secreto de TrueFoundry, recupera el texto cifrado y solicita a KMS que lo descifre. El trabajo específico del despliegue que queda pendiente —directiva de rotación de claves KMS, retención de auditoría, procedimientos operativos— es responsabilidad de cada empresa que ejecuta el gateway y merece una revisión dedicada.

7. Token Passthrough frente a Token Forwarding: casos límite y cuándo usar cada uno

Dos patrones suenan parecidos pero tienen implicaciones de seguridad muy diferentes. Conviene distinguirlos con cuidado, ya que el uso incorrecto de cualquiera de ellos anula la mayor parte del valor del gateway.

Token Passthrough es adecuado para servidores MCP internos que validan el mismo token de identidad empresarial que el gateway ya validó en la entrada. La API de logística de Northwind es un ejemplo: tanto el gateway como la API confían en el tenant de Okta de la empresa, por lo que reenviar el JWT de Okta mantiene la identidad del emisor intacta de extremo a extremo. El riesgo reside en la confusión de audiencia de tokens: un token emitido para el gateway no debería ser válido automáticamente para cualquier servidor MCP. El estándar RFC 8707 (Resource Indicators) existe precisamente para vincular tokens a un recurso previsto, y la especificación de autorización MCP exige ahora que los clientes incluyan un parámetro resource y que los servidores validen que los tokens presentados fueron emitidos para ellos.

Token Forwarding funciona de manera diferente. El encabezado x-tfy-mcp-headers de TrueFoundry contiene un JSON en formato de cadena indexado por el identificador del servidor MCP remoto en formato <group>/<server>. A continuación se muestra el formato textual de la documentación de Virtual MCP Server:

Considere Token Forwarding como un mecanismo de emergencia y no como una opción predeterminada. El valor del gateway reside precisamente en la gestión de tokens que este mecanismo omite.

8. Pruebas de rendimiento de latencia: qué añade la gestión de tokens a cada llamada de herramienta

Un gateway añade trabajo antes de realizar la llamada al servidor MCP de destino: validación de la autenticación de entrada, consulta de directivas, búsqueda de tokens y, ocasionalmente, una renovación. En un despliegue saludable, la ruta habitual es un acierto de caché: los metadatos del token son válidos y la referencia cifrada del token está cargada en memoria.

Márgenes por escenario

Al combinar los costos de los componentes anteriores, el gateway añade aproximadamente:

Hay dos conclusiones principales. En primer lugar, la ruta común es un acierto de caché y, con unos pocos milisegundos, resulta imperceptible frente a la llamada general al LLM (que suele llevar de cientos de milisegundos a segundos) y la llamada al servidor MCP de destino (normalmente de decenas a cientos de milisegundos). En segundo lugar, el escenario de fallo de caché con renovación es infrecuente pero lo suficientemente pesado como para importar cuando se acumula bajo carga —razón por la cual la §4 especifica la renovación proactiva al 80 % del TTL con un bloqueo por (usuario, servidor). Con la renovación proactiva, los usuarios reales casi nunca experimentan la latencia de renovación en la ruta de la solicitud; el gateway ya ha obtenido un nuevo token con antelación.

Aun así, cada equipo debe medir por separado los encabezados de temporización del servidor, la duración en el extremo del token, el tiempo de espera de los bloqueos, el tiempo de descifrado en la bóveda y la latencia del servidor MCP de destino. El objetivo es comprobar que la gestión de tokens no sea el costo dominante en la llamada a la herramienta del agente; las estimaciones anteriores sugieren que casi nunca lo es, pero conviene verificarlo con su propia combinación de proveedores.

La solución operativa para los fallos de caché es la renovación en segundo plano. Cuando el gateway detecta que un token supera el umbral del 80 %, ejecuta la renovación en la ruta de la solicitud una sola vez y programa las siguientes renovaciones antes de que los usuarios lo perciban. En integraciones de Client Credentials compartidas y de alto volumen, esto elimina casi por completo la latencia de renovación visible para el usuario. En integraciones de Authorization Code por usuario, el sistema puede priorizar a los usuarios activos y a los servidores MCP más utilizados.

Antes y después: postura de seguridad en Northwind

9. Preguntas frecuentes (FAQs)

¿Es obligatorio OAuth en la capa de MCP?

No. La especificación de autorización de MCP hace que la autorización sea opcional, pero las implementaciones basadas en HTTP que la admitan deben cumplir con la especificación. En la práctica, las empresas con un conjunto no trivial de herramientas deberían centralizar la autenticación mucho antes de considerarla estrictamente obligatoria.

¿Debería cada servidor MCP utilizar 3LO?

No. Utilice Authorization Code (3LO) cuando el agente actúe sobre los recursos de un usuario humano: Slack, GitHub, Gmail, herramientas de CRM. Utilice Client Credentials (2LO) cuando el servidor descendente autentique la aplicación o el gateway como sí mismo. Combinar ambos dentro de un mismo Virtual MCP Server es normal y esperado.

¿Un gateway elimina los permisos del lado del proveedor?

No. Los complementa. Slack, GitHub, Google y las API internas siguen aplicando sus propios ámbitos (scopes) y permisos de recursos. El gateway añade una capa de política más amplia y rápida por encima (a nivel de servidor, de herramienta, de equipo) y una traza de auditoría uniforme en todos ellos.

¿OAuth 2.0 u OAuth 2.1?

El gateway de TrueFoundry admite las concesiones de OAuth 2.0 que los proveedores del mundo real soportan hoy: Authorization Code (con PKCE), Client Credentials y tokens de refresco. La propia especificación de autorización de MCP apunta a OAuth 2.1, que es básicamente OAuth 2.0 más las mejores prácticas de seguridad que ya se consideran obligatorias en los despliegues modernos (PKCE en todas partes, sin concesión implícita, sin concesión de contraseña). Para fines prácticos, ambos son convergentes; seguimos las directrices de OAuth 2.1 allí donde endurecen el comportamiento.

¿Qué ocurre con la especificación MCP más reciente del 25-11-2025?

La revisión de noviembre de 2025 añade PKCE obligatorio para todos los clientes, formaliza los Documentos de Metadatos de ID de Cliente (CIMD) como el método de registro de clientes preferido e introduce la autorización escalonada para el consentimiento de ámbito incremental. Esto refuerza la seguridad sin invalidar la arquitectura de esta publicación. Estamos haciendo un seguimiento e incorporando soporte a medida que madura en todo el ecosistema.

¿Dónde encaja TrueFoundry?

El TrueFoundry MCP Gateway es una implementación en producción de esta arquitectura: un registro de servidores centralizado, autenticación de entrada configurable, control de acceso, múltiples modos de autenticación de salida y gestión del ciclo de vida de los tokens. Esta publicación describe el diseño; la documentación de autenticación y seguridad es la referencia operativa. Para ver los patrones de implementación cubiertos aquí, consulte también la documentación sobre Auth Overrides y Virtual MCP Server.

Siguiente paso

Si es un líder de plataforma, seguridad o infraestructura de IA que ejecuta MCP a una escala no trivial, la acción de mayor impacto es hacer un inventario de cada servidor MCP en uso activo, mapear cada uno con el modelo correcto de entrada, política y autenticación de salida, y decidir dónde gana realmente la centralización. El mapeo de Northwind llevó dos tardes; la migración en sí llevó un solo sprint. Estaremos encantados de revisar ese ejercicio con su equipo.

Lea la arquitectura: TrueFoundry MCP Gateway authentication and security. O concierte una revisión de arquitectura de seguridad empresarial con nuestro equipo.

Lecturas complementarias

Todas las citas de esta publicación están enlazadas en el texto. Las siguientes referencias recopilan las mismas URL para facilitar su impresión y garantizar la validez de los enlaces.

• Descripción general de TrueFoundry MCP Gateway. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-overview
• Autenticación y seguridad de TrueFoundry MCP Gateway. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-gateway-auth-security
• TrueFoundry Auth Overrides. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-server-auth-overrides
• TrueFoundry Virtual MCP Server. https://www.truefoundry.com/docs/ai-gateway/mcp/virtual-mcp-server
• Uso de MCP Gateway en su agente con TrueFoundry. https://www.truefoundry.com/docs/ai-gateway/mcp/use-mcp-gateway-in-agent
• Proveedores de identidad de TrueFoundry. https://www.truefoundry.com/docs/platform/identity-providers
• TrueFoundry Secret Manager en AI Gateway. https://www.truefoundry.com/docs/ai-gateway/secret-manager-in-ai-gateway
• Variables de entorno y secretos de TrueFoundry (formato FQN tfy-secret://). https://www.truefoundry.com/docs/environment-variables-and-secrets
• Uso de tfy apply en TrueFoundry (patrón YAML provider-account / integrations). https://docs.truefoundry.com/docs/using-tfy-apply
• Límites de concurrencia de Okta (guía de tiempo de respuesta de API). https://developer.okta.com/docs/reference/rl2-concurrency/
• WorkOS: RS256 frente a HS256 (pruebas de rendimiento de verificación JWT). https://workos.com/blog/rs256-vs-hs256-jwt-signing-algorithms
• Documentación de AWS KMS (guía de latencia de descifrado). https://aws.amazon.com/kms/faqs/
• Especificación de autorización de Model Context Protocol, 18-06-2025. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• RFC 6749: El marco de autorización OAuth 2.0. https://datatracker.ietf.org/doc/html/rfc6749
• RFC 8707: Indicadores de recursos para OAuth 2.0. https://datatracker.ietf.org/doc/rfc8707/
• RFC 9728: Metadatos de recursos protegidos de OAuth 2.0. https://datatracker.ietf.org/doc/html/rfc9728/

Nota: Northwind Logistics es una empresa ficticia utilizada para fundamentar el diseño en un despliegue concreto. El modelo de configuración mostrado en la §3 es ilustrativo; los servidores MCP de producción se registran a través de la interfaz de usuario de TrueFoundry o se aplican mediante tfy apply.

‍