Última revisión en enero del 2026.
Introducción
Contexto
En uno de mis proyectos quería incorporar algo aparentemente sencillo: permitir que los usuarios introdujeran información usando ChatGPT en lugar del editor habitual, un formulario con múltiples campos, incluida una imagen, que el usuario completa manualmente y guarda al final. Una vez enviada, la entrada se publica junto con otras aportadas por distintos usuarios.
Uso de ChatGPT como cliente MCP
ChatGPT es el cliente MCP que la mayoría de usuarios potenciales ya utilizan y conocen. El esfuerzo adicional que supone para el usuario añadir nuestro servidor MCP como conector en ChatGPT se ve sobradamente compensado por el valor que aporta: la automatización completa del llenado de campos y la capacidad de generar textos enriquecidos con etiquetas, estructuras semánticas y otros recursos avanzados que quedan fuera del alcance de la mayoría de nuestros usuarios potenciales.
El reto principal: la autenticación de los usuarios
El principal problema surgió con la autenticación de los usuarios. La idea inicial era que utilizaran un token que los autenticara y autorizara a realizar acciones durante un periodo de tiempo limitado. Dicho token se obtiene a través del editor del proyecto, y los propios usuarios asumen la responsabilidad de custodiarlo y revocarlo en caso de considerarlo necesario.
Con un cliente MCP local, bajo el control directo del usuario, este enfoque no presenta ningún problema: el cliente puede custodiar secretos de forma segura, fijar un token durante su ventana de validez y renovarlo cuando sea necesario. Sin embargo, ChatGPT no permite credenciales estáticas como client_secret en clientes MCP, y exige flujos seguros como PKCE y registro dinámico. Estas limitaciones nos llevaron a construir un servidor de autenticación propio, específicamente diseñado para operar con Google OAuth2 bajo los requisitos de seguridad impuestos por clientes MCP como ChatGPT.
La implementación
Para su implementación utilicé Quarkus, un framework que estoy empezando a incorporar de forma sistemática en mis proyectos, junto con Firestore en Google Cloud como backend de persistencia. El resultado es un sistema deliberadamente sencillo, pero alineado con los requisitos reales del ecosistema MCP y con las expectativas de seguridad de ChatGPT. Como apunte final, el sistema utiliza Google como upstream Identity Provider (IdP) para la autenticación de usuarios, delegando en él la verificación de identidad y manteniendo el control de la autorización en el servidor propio.
El código está disponible públicamente por si a alguien le resulta útil o simplemente quiera explorar una implementación mínima que funcione correctamente con ChatGPT:
Podéis encontrar el código del servidor de autentificación en GitHub.
ChatGPT - la IA del pueblo
Todo el mundo está usando ChatGPT, y es evidente que los conectores MCP se convierten en un punto crítico de acceso a datos sensibles. Es lógico que OpenAI sea especialmente cautelosa: un fallo grave en este ámbito comprometería no solo la seguridad de los usuarios, sino también su credibilidad y liderazgo. De ahí esa tensión constante entre abrir el ecosistema a integraciones externas y, al mismo tiempo, endurecer los mecanismos de control y validación.
ChatGPT se ejecuta íntegramente en la nube de OpenAI, lo que implica limitaciones claras desde el punto de vista del desarrollo: no puede acceder a nuestro localhost, no asume el rol de entorno de desarrollo y, sobre todo, no quiere responsabilizarse de custodiar secretos como client_id o credenciales estáticas. Estas restricciones tienen consecuencias directas en el diseño del sistema y explican por qué ChatGPT exige flujos como Dynamic Client Registration, PKCE y un modelo de autenticación en el que los secretos de larga duración no viven en el cliente, sino que se negocian dinámicamente y con un alcance limitado.
Dynamic Client Registration
ChatGPT registra dinámicamente cada integración contra el servidor de autenticación, obteniendo un cliente efímero y con capacidades bien delimitadas. Este enfoque reduce el riesgo asociado a credenciales estáticas, permite revocar o limitar clientes sin afectar al resto del sistema y obliga a que la confianza entre cliente y servidor se establezca de forma explícita y verificable desde el primer momento.
PKCE
Proof Key for Code Exchange refuerza el flujo de autorización en un contexto donde el cliente no puede mantener secretos de larga duración. En el caso de ChatGPT, PKCE es esencial para garantizar que el código de autorización no pueda ser reutilizado por un tercero, incluso si es interceptado durante una redirección o a través de un canal comprometido. Este mecanismo previene ataques de authorization code interception y replay, en los que un atacante intenta intercambiar un código robado por un token válido. De este modo, se elimina la necesidad de un client_secret, se reduce la superficie de ataque y se adapta OAuth a un entorno cloud y multi-tenant como el de ChatGPT.
Identity Provider
OpenAI recomienda apoyarse en un identity provider consolidado en lugar de implementar la autenticación desde cero. En el ecosistema Quarkus, esta recomendación suele materializarse en Keycloak, que ofrece soporte completo para OAuth y OIDC. Sin embargo, su uso en producción implica disponer de una base de datos persistente y mantener un servicio permanentemente activo, con el coste y la carga operativa asociados. Dado el tipo proyecto, se optó por una implementación propia en Quarkus, diseñada específicamente para integrarse con ChatGPT y MCP, minimizando complejidad y costes sin perder alineación con las especificaciones requeridas.
Quarkus
Ya nadie habla del "Write once, run anywhere"
En la era de contenedores y Kubernetes, Java ya no se ejecuta en entornos genéricos, sino en plataformas conocidas y predefinidas. En ese contexto, lo relevante no es aislar la JVM, sino optimizar tiempo de arranque, concurrencia y consumo de recursos. Quarkus aborda precisamente estos problemas, adaptando Java a un modelo cloud-native y haciéndolo viable en escenarios modernos como Cloud Run o entornos autoescalados. Con el respaldo de IBM y una comunidad activa, Quarkus representa una apuesta sólida por un Java más eficiente y alineado con la infraestructura actual, razón por la cual fue la elección para este proyecto.
El servidor de autentificación
MCP Inspector
El MCP Inspector es una herramienta de desarrollo pensada para entender, depurar y validar la interacción entre un cliente MCP y un servidor MCP, especialmente durante el flujo de autenticación OAuth. Al ejecutarlo localmente, el Inspector levanta un proxy MCP que actúa como intermediario entre el cliente y el servidor MCP real. Este proxy permite observar paso a paso el proceso: desde el descubrimiento del servidor, la redirección al authorization server, la obtención del código de autorización, el intercambio por tokens y, finalmente, las llamadas autenticadas al MCP. El session token que muestra el Inspector protege el acceso al proxy durante la sesión de depuración, evitando llamadas accidentales o no autorizadas.
Conclusiones
Finalmente, hemos logrado que el usuario no tenga que preocuparse por la gestión de tokens: basta con autenticarse mediante Google una vez al mes. Los access tokens tienen una validez de 60 minutos, y el sistema utiliza un refresh token que permite renovarlos automáticamente sin intervención del usuario, garantizando sesiones continuas durante ese periodo con un flujo seguro y transparente.
Cuando hablamos de ChatGPT, conviene recordar que no es un sistema totalmente fiable. Aunque agiliza enormemente la entrada de datos, en ocasiones puede introducir imprecisiones o interpretaciones excesivamente creativas. Por este motivo, los contenidos generados de forma automática se guardan inicialmente en estado de borrador, obligando al usuario a revisarlos y validarlos mediante el editor convencional antes de hacerlos públicos.
El Código
Podéis encontrar el código del servidor de autentificación en GitHub.
Comentarios
Publicar un comentario