Cloudflare OAuth para todos los clientes
(blog.cloudflare.com)- Cloudflare ahora permite que los clientes creen sus propias apps de self-managed OAuth, para ofrecer acceso a la API de Cloudflare mediante un flujo estándar de autorización delegada
- Antes, solo algunos socios incorporados manualmente podían usar OAuth de terceros, y los desarrolladores de integraciones propias tenían que depender de tokens de API, que no encajan bien con los flujos de apps delegadas
- Para abrirlo al público general, mejoró la pantalla de consentimiento, la revocación y la visibilidad de la propiedad de las apps, y actualizó gradualmente el motor OAuth Hydra de la versión 1.X a la 2.X
- Durante la actualización surgieron migraciones de esquema, errores de renovación de tokens, riesgo de pérdida de eventos de revocación y un aumento de errores 403, que se mitigaron con creación concurrente de índices, una cola de reprocesamiento de revocaciones y restauración de datos
- Después de la actualización, el P95 de la API bajó de 185 ms a 101 ms, una reducción del 45%, y el uso de CPU también cayó de 1.07 núcleos a 0.67, estabilizando la base operativa para OAuth público
Ampliación del alcance público de Cloudflare OAuth
- Cloudflare ha permitido crear automatización, CI/CD e integraciones de infraestructura con su API de plataforma, y ahora abre self-managed OAuth a todos los clientes
- Cloudflare OAuth en sí no es una función nueva; ya se venía usando en integraciones de socios como Wrangler y PlanetScale
- Sin embargo, el OAuth de terceros existente solo estaba disponible para un pequeño grupo de integraciones incorporadas manualmente, y no estaba abierto a un ecosistema más amplio de desarrolladores
- Los desarrolladores que creaban integraciones propias tenían que depender de tokens de API, un enfoque difícil de administrar y poco adecuado para muchos flujos de aplicaciones delegadas
- Con self-managed OAuth, los desarrolladores pueden ofrecer flujos OAuth estándar en los que el propio cliente autoriza acceso con alcances definidos
- Los casos de uso principales son integraciones SaaS, plataformas internas para desarrolladores y herramientas de agentes
- Los usuarios obtienen un consentimiento más claro, una revocación más sencilla y mayor control sobre los permisos de las aplicaciones
Reforzando la base de seguridad para abrirlo a todos
- La solución OAuth inicial era suficiente para un pequeño grupo de socios administrados, pero no tenía un modelo de permisos, una experiencia de consentimiento ni mecanismos de mitigación de abuso lo bastante maduros para una apertura total al público
- A comienzos de este año, Cloudflare mejoró la experiencia de consentimiento para mostrar con más claridad qué aplicación solicita acceso y qué permisos recibirá
- En el dashboard añadió una función de revocación para que los desarrolladores puedan controlar fácilmente qué aplicaciones pueden acceder a sus datos
- Para reducir ataques de phishing en OAuth, también hizo más visible la propiedad de la app
- Para abrir self-managed OAuth a todos los clientes, hacía falta actualizar el motor OAuth manteniendo la estabilidad y seguridad de los datos y minimizando interrupciones para los usuarios
Preparación para la actualización de Hydra 1.X
- Desde hace tiempo, Cloudflare usa el motor OAuth open source Hydra como motor interno de Cloudflare OAuth
- A medida que creció la plataforma para desarrolladores y aumentaron los flujos de trabajo con agentes, se volvió necesaria una actualización grande para incorporar nuevas funciones y mejoras de rendimiento
- En lugar de hacer una gran actualización de una sola vez, eligió un enfoque secuencial: primero pasar a la versión 1.X más reciente, evaluar cambios de comportamiento y rendimiento, y luego avanzar a la actualización 2.X
- Incluso la actualización a 1.X podía afectar a los clientes
- La base de datos de Hydra creaba índices tomando bloqueos exclusivos sobre tablas críticas
- Añadía columnas a tablas importantes y movía otras columnas a una tabla nueva
- El SDK de la versión de Hydra en uso hacía
SELECT *, lo que podía causar problemas de deserialización con cambios de esquema
- Para evitar impacto a los usuarios, reescribieron las migraciones SQL usando métodos como
CREATE INDEX CONCURRENTLYy crearon una versión personalizada de Hydra que selecciona columnas explícitas en lugar deSELECT *
Estrategia de actualización a Hydra 2.X
- La actualización a 2.X implicaba cambios de esquema mucho más grandes, por lo que una actualización in-place no era adecuada, y Cloudflare eligió una estrategia blue-green
- No bastaba con simplemente pasar el switch a la nueva versión
- La actualización y la migración tomarían varias horas
- Durante ese tiempo, el sistema tenía que seguir funcionando correctamente
- La primera opción blue-green consistía en bloquear escrituras en la base de datos para impedir nuevas autorizaciones
- Durante la transición no se perderían nuevas escrituras
- Los usuarios sin credenciales válidas existentes no podrían usar las apps OAuth ya desplegadas
- Los usuarios no podrían revocar el acceso de las aplicaciones durante la actualización
- La estrategia final fue mantener las escrituras en la base de datos, aceptando cierta pérdida limitada y reduciendo ese riesgo
- Para disminuir nuevas escrituras de tokens, extendieron el tiempo de expiración de los tokens a varias horas
- Las apps que recibieron tokens antes de la actualización podían seguir usándolos sin renovarlos
- La pérdida de eventos de revocación se evitó con un sistema de colas basado en Cloudflare Queues
- Cuando ocurre un evento de revocación, esa información se registra en la cola
- Después de cambiar a la base de datos de la versión green, la cola se vacía para reproducir las revocaciones ocurridas durante la ventana de actualización
- Si este proceso fallaba, podía restaurarse sin querer el acceso de aplicaciones que el usuario ya había revocado
Actualización a 1.X y problema con la renovación de tokens
- La primera actualización a la versión 1.X más reciente avanzó sin grandes problemas desde la perspectiva operativa
- La migración personalizada de base de datos se ejecutó más rápido de lo esperado y no tuvo impacto en los usuarios
- Como la versión antigua no podía introspectar los tokens creados por la nueva versión, fue necesario un hard cutover
- Después del cutover, aumentaron errores de refresh token que antes no eran visibles
- La causa fue el comportamiento más estricto de invalidación de refresh en la nueva versión
- Si se reutiliza un refresh token, Hydra invalida toda la cadena de access tokens y refresh tokens
- Los clientes Wrangler y MCP manejan un alto volumen de solicitudes, así que un solo reuso de refresh token podía invalidar toda la sesión
- Cloudflare añadió comportamiento de refresh token coalescing al Worker que enruta el tráfico OAuth al destino correcto
- Las solicitudes de refresh token se almacenan brevemente en caché antes de llegar a Hydra
- Si detecta un reintento, responde de forma abreviada sin invalidar el token
- Hydra 2.X incluye un
refresh token grace periodconfigurable que permite reintentos durante cierto tiempo sin invalidar toda la cadena
Transición a 2.X y proceso de recuperación
- Cloudflare no podía permitirse una interrupción de varias horas con impacto importante para los usuarios, así que ejecutó una actualización blue-green
- La transición real requirió más trabajo que una simple copia de base de datos y un nuevo despliegue de Hydra
- Activación de la cola para capturar y reproducir revocaciones
- Copia de la base de datos y restauración en el nuevo destino
- Limpieza de datos existentes que violaban restricciones de la nueva versión
- Cutover simultáneo de los servicios Hydra y de dos sistemas internos clave
- Monitoreo y validación después del cutover
- La ventana de actualización se eligió en el horario con menor cantidad de solicitudes por segundo hacia Hydra, para minimizar la pérdida de escrituras de tokens
- La migración en producción funcionó bien en la nueva base de datos salvo algunos ajustes de timeout, y el tiempo puro de ejecución fue de unas 3 horas
- Justo después del cambio de tráfico, una tarea de limpieza de datos del authorization service comenzó a borrar en exceso datos de políticas OAuth
- Ese servicio depende de la API de sesiones de consentimiento de Hydra
- Una de las migraciones de Hydra dañó parte del estado válido de sesiones OAuth, marcando sesiones válidas como inválidas
- La inconsistencia entre Hydra y el authorization service apareció como un aumento de errores 403
- Cloudflare mitigó el problema con restauración de datos e inició mejoras en el comportamiento de autorización OAuth para reducir la dependencia de datos estáticos de políticas
- También aplicó rápidamente pequeños ajustes derivados de comportamientos específicos de algunos clientes
Mejoras de rendimiento después de la actualización
- Una vez completada la actualización de versión de Hydra, el tráfico OAuth se mantuvo estable y mejoraron el rendimiento y la confiabilidad del sistema para los clientes
- La nueva base es la misma que ya se había validado en staging para la nueva API de OAuth y fue la que permitió el lanzamiento de self-managed OAuth del 3 de junio
- Métricas principales observadas durante la migración de base de datos:
- Filas actualizadas: 132.5M
- Filas insertadas: 114.7M
- Bytes temporales: 136.97GB
- Commits de transacción: 22.2k
- Las métricas promedio de rendimiento de Hydra mejoraron en general después de la actualización
- API P95: 185 ms → 101 ms, 45% menos
- Memoria RSS: 888 MB → 763 MB, 14% menos
- Go heap alloc: 449 MB → 271 MB, 40% menos
- Goroutines: 4015 → 3076, 23% menos
- CPU: 1.07 núcleos → 0.67 núcleos, 37% menos
Cómo empezar
- Ahora todos los clientes de Cloudflare pueden crear sus propias aplicaciones OAuth y construir integraciones sobre Cloudflare
- Para comenzar, puedes consultar la documentación o crear tu primera app OAuth desde la página de OAuth apps en el dashboard
1 comentarios
Comentarios de Hacker News
Soy la persona que creó Ory Hydra. Me alegró mucho ver esta publicación del blog y la explicación técnica; jamás imaginé que este software terminaría protegiendo a empresas de internet de escala mundial
Qué bueno saber que la versión 2.x funciona bien a esa escala, y el uso de CPU también parece ridículamente bajo
Si surge algún problema, también hay una versión comercial más rápida. Si te interesa OAuth propio, IAM, permisos ReBAC, claves API y seguridad para agentes, puedes ver los productos open source y comerciales en https://github.com/ory y https://www.ory.com/
Antes operé en self-hosting el framework identity server para dotnet, manejando decenas de miles de millones de solicitudes al mes, y a esa escala OAuth y OpenID Connect eran prácticamente un problema resuelto, con una carga de mantenimiento baja
Era un servicio central de la organización y con fuertes requisitos de compliance, pero el equipo encargado probablemente era de unas 3 personas, y todavía sigue funcionando bien
Nunca entendí por qué hay tanta confusión alrededor de estos protocolos, y casi todos los ingenieros junior con los que trabajé tuvieron dificultades para entenderlos. El blog de Scott Brady https://www.scottbrady.io/ ayuda mucho en este tema
Parece que cuando entra autenticación/autorización, a los ingenieros les surge un “miedo” primordial. Están acostumbrados a resolver problemas, pero autenticación/autorización aparece como una especie de prerrequisito para resolverlos, y eso añade carga cognitiva
Cloudflare muy en su estilo. Funciona bien para todos y no es tan caro, pero como resultado de todas esas ventajas termina ocupando el centro de todo
Soy Grant. Junto con Aeneas escribí la mayor parte del código de migración 2.0. Gracias al equipo de Cloudflare por la publicación
Me pregunto si la parte que dice “nuestra investigación mostró que había un problema en una de las migraciones de Hydra que corrompió el estado de algunas sesiones OAuth válidas, y como resultado la migración marcó esas sesiones como inválidas” se refería a uno de los archivos de migración open source
Ya no participo en el proyecto, pero me gustaría saber si eso ya se corrigió upstream
Como mínimo, al contexto completo le tendría que acompañar un plan de autorización y flujo de autenticación dentro del ecosistema de Cloudflare, así que tengo sentimientos encontrados. Ni siquiera hay ejemplos en GitHub
Aun así, es cierto que Cloudflare arrancó en la dirección correcta, pero todavía le falta bastante si se compara con toda la suite base de productos de Ory. Ory Kratos maneja identidad, inicio de sesión, registro, recuperación, autenticación multifactor, etc.: https://github.com/ory
Creo que el alcance completo también debería incluir planes para almacenamiento de usuarios, SAML y un modelo organizacional multi-tenant. Como buen ejemplo, Zitadel https://github.com/zitadel ofrece una UI de administración para multi-tenancy organizacional, soporte para OIDC/PKCE y también se le puede sumar algo de RBAC
Supabase también ofrece autenticación gestionada y open source: https://github.com/supabase/auth
Dejando de lado que “MCP murió y Skills es para siempre”, me preocupa que en todos estos casos el plan de conectar MCP y rotar claves vaya a explotar pronto a gran escala
Registro dinámico de clientes en OAuth 2.0 (RFC 7591): https://datatracker.ietf.org/doc/html/rfc7591
https://modelcontextprotocol.io/specification/2025-03-26/bas...
En especial me gustaría escuchar opiniones en el contexto de SaaS multi-tenant y asistentes de IA integrados
En el flujo de redirección que normalmente se usa para conectar MCP a un agente, la especificación casi no dice cómo volver eso seguro
No querrías permitir que cualquiera registre un cliente con un callback arbitrario. Eso abre la puerta al phishing
Si alguien registra un cliente con una URL de callback maliciosa y luego engaña a un usuario para que haga clic en un enlace que inicia ese flujo, un proveedor de identidad legítimo autenticaría al usuario y luego entregaría el token de acceso al atacante
La especificación menciona por encima un token de acceso inicial que el cliente obtiene antes del registro, pero faltan detalles y probablemente sea difícil que funcione en una situación donde todos los usuarios finales son clientes
Idealmente querrías definir una allowlist de patrones de redirección para limitarlo a destinos como ChatGPT. Pero eso es comportamiento no estándar, así que los vendors de IAM no tienen apuro
No entiendo cuál es la intención aquí. No hay ningún mundo en el que esto termine bien. Cloudflare es casi un proveedor de infraestructura, y un modelo para infraestructura en el que algún usuario pueda delegar permisos de su cuenta a clientes de terceros tiene mucho potencial de abuso
Si una empresa como AWS no lo hace, supongo que será por algo
Por ejemplo, IAM puede dar a GitHub Actions que corren en un repositorio específico permiso para actualizar Lambda
OAuth y la autenticación empresarial quizá sean de lo peor que se ha inventado. Cuando trabajas con la nube, puede ser la parte más confusa y frustrante.
Incluso las herramientas de IA tardaron un año solo en manejar OAuth básico en sistemas headless, sin asumir que podían abrir un navegador.
Si vamos a meternos en toda la madriguera de autenticación de los grandes proveedores de nube —RBAC/IAM/identidad de cargas de trabajo/cuentas de servicio y demás—, ojalá al menos dejaran una forma simple para uso personal.
Basta con una sola API key. La guardas en secreto y la revocas si hace falta; no hace falta enredar 10 mil capas de basura de autenticación en todos los niveles de todas las plataformas.
Es una pesadilla de privacidad.
Acabamos de lanzar Ory Talos para API keys (https://github.com/ory/talos). Es una buena alternativa cuando OAuth2 es demasiado para el caso de uso.
También hay casos de uso y preocupaciones de seguridad que sí justifican usar OAuth2. Especificaciones como DPoP pueden hacer estos flujos más seguros.
El caso de uso presentado aquí sí parece adecuado para OAuth2, pero no aplica en todos lados. La complejidad hace más difícil asegurar un sistema.
La ventaja de OAuth2/OIDC es que no deposita la confianza en quien posee la API key, sino en la identidad real que necesita acceso.
Que la autenticación sea difícil aplica cuando es para muchos usuarios. La autenticación para ti mismo es muy simple, y con un framework decente es todavía más fácil.
Si no confías en tu implementación, puedes pasársela a uno de los modelos más recientes. Son bastante buenos encontrando problemas en un sistema de autenticación tan simple.
“Ory Enterprise License: desbloquea funciones de nivel empresarial como SLA de seguridad para CVE, SAML, organizaciones B2B, multitenencia y mejor escalabilidad” [0]
O simplemente puedes seguir usando Keycloak, que ofrece un producto completamente self-hosted [1]
[0]https://github.com/ory
[1]https://www.keycloak.org/
La razón de tener una versión comercial es la cuestión de cómo sostener financieramente software open source de clase mundial. Que exista un modelo de negocio que funcione para open source que respalda a las empresas de software más grandes del planeta no es algo malo, sino bueno.
Por cierto, IBM también encontró la forma de cobrar por Keycloak.
Esto básicamente trata sobre OAuth para acceder a cuentas de Cloudflare, no sobre una función genérica tipo “iniciar sesión” alojada por Cloudflare para apps personalizadas.
Creía que entendía qué era OAuth, pero esta publicación me confunde. Pensaba que era un protocolo estandarizado para proporcionar claves de acceso por cliente.
¿Qué significa aquí OAuth autoadministrado? Hace falta explicar a qué se otorga acceso, quién es el cliente y quién es el socio.
Te permite alojar tu propio sistema OAuth para aprobar o denegar acceso a tus propios recursos. En vez de esperar a que Cloudflare permita Y bajo la condición X, puedes crear la lógica que quieras.
Esencialmente, el flujo es: “iniciar sesión en Cloudflare” → Cloudflare verifica el uso de OAuth autoadministrado → redirige al OAuth del usuario → Cloudflare confía en la respuesta → si el usuario aprueba, se permite el acceso a la cuenta.