Ciberseguridad · Seguridad MCP · 8 min
Tokens, OAuth y “confused deputy”: evitar accesos no autorizados
Cuando un servidor actúa en nombre de una persona frente a otro servicio, debe preservar la identidad, el consentimiento y el alcance de cada autorización.
Introducción
Un token no es solo una cadena que permite “conectar” un servicio: representa una autoridad delimitada. En sistemas con proxies o integraciones encadenadas, la confusión sobre a quién representa esa autoridad puede convertir al servidor en un confused deputy.
Qué especifica MCP y qué no
La autorización MCP es opcional. Para implementaciones que la ofrecen sobre HTTP, la especificación 2025-11-25 define un flujo basado en OAuth y exige, entre otros puntos, que el servidor implemente Protected Resource Metadata (RFC 9728) y que el cliente la use para descubrir servidores de autorización. El servidor actúa como resource server y el cliente como OAuth client. No hay que extrapolar automáticamente ese flujo a stdio: la especificación recomienda no usarlo allí y recuperar credenciales del entorno.
Esas obligaciones son específicas del mecanismo de autorización descrito por MCP. No sustituyen el análisis de la autorización entre el servidor MCP y una API de terceros.
Evitar el “confused deputy”
El riesgo aparece, por ejemplo, cuando un proxy usa sus propias credenciales para una API externa, pero no comprueba adecuadamente a qué cliente MCP está atendiendo ni conserva una aprobación individual. Las buenas prácticas de MCP describen un escenario particular que combina un identificador OAuth estático, registro dinámico de clientes, una cookie de consentimiento del tercero y ausencia de consentimiento por cliente. No implica que todo flujo OAuth de MCP sea vulnerable.
Vincula cada flujo a su cliente y usuario; valida redirect_uri, estado y destino; no reutilices tokens entre usuarios o clientes; solicita consentimiento claro antes de delegar; restringe scopes y audiencia; protege tokens en almacenamiento y logs. Aplica también RFC 9700, Best Current Practice de OAuth 2.0, como guía de seguridad de OAuth, sin confundirla con una especificación de MCP.
Conclusión
La pregunta clave no es solo “¿hay token?”, sino “¿quién lo obtuvo, para qué recurso, por cuenta de quién y bajo qué consentimiento?”. Conserva esas relaciones a lo largo de cada salto.
Fuentes y rigor
Referencias
Referencias verificadas el 25 de septiembre de 2026. La especificación puede cambiar; comprueba las versiones vigentes antes de tomar decisiones de implementación.
Conclusión
La pregunta clave no es solo “¿hay token?”, sino “¿quién lo obtuvo, para qué recurso, por cuenta de quién y bajo qué consentimiento?”. Conserva esas relaciones a lo largo de cada salto.
Sigue explorando