Cloudflare anuncia el levantamiento completo de la restricción de OAuth, los desarrolladores de Agentes de IA ya no necesitan revisión manual.

Cloudflare anuncia que su OAuth autogestionado está abierto a todos los desarrolladores, sin necesidad de revisión manual para la incorporación. Detrás de esto está el crecimiento explosivo de la demanda de delegación de autorización por parte de las herramientas de agentes de IA (AI Agent), así como un reemplazo de motor subyacente que implica la migración de 130 millones de filas de datos.
(Resumen anterior: Datos de Cloudflare: el 34% del tráfico en Internet no es humano, los rastreadores de IA crecen 8 veces más rápido)
(Contexto adicional: UBS y TD Cowen elevan simultáneamente el precio objetivo de Arm a 475 dólares, argumentando ingresos futuros por CPU propia)

Índice del artículo

Toggle

• ¿Por qué ahora está abierto?
• Un reemplazo de motor subyacente que implica 130 millones de filas de datos
• Problema de fallo en cadena del token de actualización para clientes MCP

Cloudflare, que gestiona el 20% del tráfico global de Internet, tomó una decisión clave esta semana: permitir que todos los desarrolladores creen y gestionen sus propios clientes OAuth, sin necesidad de revisión manual una por una para la incorporación. La fuerza impulsora detrás de esto es la enorme demanda de "autorización delegada" por parte de las herramientas de agentes de IA. Cuando los modelos de IA necesitan acceder a los recursos de Cloudflare en nombre del usuario, antes solo se podía confiar en tokens API, un método difícil de gestionar y no adecuado para flujos de trabajo de agentes que requieren un alcance de consentimiento claro.

¿Por qué ahora está abierto?

Cloudflare no es nueva en OAuth. Ya desde que los desarrolladores usaban la herramienta CLI Wrangler o se conectaban a servicios de socios como PlanetScale, OAuth funcionaba silenciosamente en segundo plano. Pero estas integraciones eran modos cerrados de "incorporación manual", y los desarrolladores externos no podían crear sus propios flujos OAuth estándar.

Cloudflare señaló en su blog oficial que durante el último año han ido incorporando gradualmente socios tempranos, mejorando continuamente el mecanismo de consentimiento, el proceso de revocación y el modelo de seguridad. Pero a medida que la plataforma de desarrolladores se expande y la demanda de acceso delegado por parte de las herramientas de agentes de IA aumenta rápidamente, "abrir OAuth a todos los usuarios" se ha convertido en una condición necesaria para el éxito de la plataforma, no una opción.

El OAuth autogestionado permite a los desarrolladores ofrecer un flujo de autorización estándar: los usuarios otorgan directamente acceso con alcance limitado, las aplicaciones pueden saber qué se les permite hacer y los usuarios pueden revocar el acceso en cualquier momento. Esto es una infraestructura más limpia que los tokens API para construir integraciones SaaS, plataformas internas de desarrolladores y varios tipos de herramientas de agentes de IA.

Un reemplazo de motor subyacente que implica 130 millones de filas de datos

Sin embargo, para escalar la apertura de OAuth, Cloudflare primero tuvo que resolver un problema de ingeniería: el motor de autorización subyacente Hydra ya no podía soportar la carga.

Hydra es un motor OAuth de código abierto que Cloudflare implementó hace años para soportar la infraestructura OAuth de la plataforma. Se comportaba de manera estable cuando el uso era limitado, pero a medida que la plataforma de desarrolladores se expandió y los flujos de trabajo de IA se popularizaron, los cuellos de botella de rendimiento y las limitaciones funcionales de Hydra original se hicieron cada vez más evidentes.

El plan de actualización se desarrolló en dos fases. La primera fase fue la actualización a Hydra 1.X. Los ingenieros descubrieron que incluso una migración de versión menor implicaba cambios de esquema de base de datos considerables. Reescribieron los scripts de migración SQL, utilizando técnicas como CREATE INDEX CONCURRENTLY que no bloquean la escritura, y personalizaron la versión de compilación de Hydra, reemplazando las consultas SELECT * con campos especificados explícitamente para reducir la transferencia de datos innecesaria.

La segunda fase fue el despliegue azul-verde (blue-green deployment) de Hydra 2.X. El llamado despliegue azul-verde significa mantener dos sistemas, el antiguo y el nuevo, funcionando simultáneamente, cambiando el tráfico gradualmente solo después de confirmar la estabilidad del nuevo sistema, con la capacidad de revertir instantáneamente en cualquier momento, reduciendo el riesgo de interrupción del sistema a casi cero. Cloudflare dijo que bajo este marco construyeron un sistema de colas basado en Cloudflare Queues para sincronizar correctamente los eventos de revocación entre los sistemas antiguo y nuevo.

La escala de la migración de la base de datos fue considerable: se actualizaron un total de 132.5 millones de filas de datos, se insertaron 114.7 millones de nuevas filas de datos, generando 136.97 GB de datos temporales.

Problema de fallo en cadena del token de actualización para clientes MCP

Después de completar el cambio azul-verde, los datos de monitoreo mostraron una señal inesperada: la tasa de error de los tokens de actualización (refresh token) aumentó.

Al investigar la causa, se descubrió que la nueva versión de Hydra adoptó un mecanismo de invalidación más estricto para la reutilización de tokens de actualización. Una vez que se detecta que el mismo token de actualización se reutiliza, todo el conjunto de credenciales de acceso (token de acceso y token de actualización) se revoca junto.

Esto causó problemas a Wrangler y a los clientes MCP, porque en situaciones de red inestable o solicitudes concurrentes, estas herramientas pueden desencadenar la reutilización del token de actualización.

La solución fue agregar un "mecanismo de fusión de tokens de actualización" en el Worker que enruta el tráfico OAuth: cuando se detectan múltiples solicitudes de actualización para el mismo token entrando simultáneamente, el sistema fusiona las solicitudes en una sola, evitando desencadenar la lógica de fallo en cadena. Esta corrección restauró el comportamiento de integración de los clientes MCP a la normalidad.

Este episodio también reveló una realidad: el patrón de comportamiento de autorización de las herramientas de agentes de IA es estructuralmente diferente del flujo OAuth tradicional operado manualmente. Las herramientas de agentes pueden emitir una gran cantidad de solicitudes de actualización de tokens concurrentes en un corto período de tiempo, mientras que la implementación tradicional de OAuth no está diseñada para este escenario de uso.

Después de completar la actualización, la mejora en varios indicadores de rendimiento fue bastante significativa. La latencia P95 de la API disminuyó de 185 ms a 101 ms, una reducción del 45%; la ocupación de memoria residente se redujo de 888 MB a 763 MB, una reducción del 14%; la asignación de memoria Go heap se redujo de 449 MB a 271 MB, una reducción del 40%; el número de Goroutines se redujo de 4,015 a 3,076, una reducción del 23%; el uso de CPU se redujo de 1.07 núcleos a 0.67 núcleos, un ahorro del 37%.

Cloudflare dijo que la apertura del OAuth autogestionado permite a los desarrolladores construir integraciones con un alcance de consentimiento del usuario más transparente y una revocación más fácil, lo cual es especialmente importante para la salud del ecosistema de herramientas de agentes de IA. Cuando los modelos de IA operan servicios en nombre de los humanos, "qué está autorizado a hacer este agente" y "cómo revocar su acceso" serán preguntas inevitables en el marco de confianza.