Cloudflare anuncia desbloqueio total de OAuth, desenvolvedores de Agente de IA já não precisam de revisão manual.

Cloudflare anuncia que o OAuth auto-gerido está disponível para todos os programadores, sem necessidade de revisão manual para adesão. Por trás disso, está o crescimento explosivo da procura por delegação de autorização por parte de ferramentas de agente de IA (AI Agent), bem como uma substituição de motor subjacente que envolve a migração de 130 milhões de linhas de dados. (Contexto anterior: Dados da Cloudflare: 34% do tráfego na Internet não é humano, crawlers de IA estão a crescer 8 vezes mais rápido) (Contexto adicional: UBS e TD Cowen aumentaram o preço-alvo da Arm para 475 dólares no mesmo dia, com base na receita futura da CPU desenvolvida internamente)

Índice deste artigo

Alternar

• Por que abrir agora?
• Uma substituição de motor subjacente que envolve 130 milhões de linhas de dados
• Problema de falha em cadeia do token de atualização em clientes MCP

A Cloudflare, que gere 20% do tráfego global da Internet, tomou uma decisão crucial esta semana: permitir que todos os programadores criem e gerenciem os seus próprios clientes OAuth, sem necessidade de revisão manual individual para adesão. A força motriz por trás disso é a enorme procura de ferramentas de agente de IA por "autorização delegada". Quando os modelos de IA precisam de aceder aos recursos da Cloudflare em nome dos utilizadores, no passado apenas podiam depender de tokens de API, uma abordagem difícil de gerir e inadequada para fluxos de trabalho de agentes que exigem âmbitos de consentimento explícitos.

Por que abrir agora?

A Cloudflare não é novata no OAuth. Desde que os programadores usaram a ferramenta Wrangler CLI ou integraram serviços de parceiros como a PlanetScale, o OAuth já operava silenciosamente em segundo plano. Mas estas integrações eram um modelo fechado de "adesão manual", e os programadores terceiros não conseguiam criar os seus próprios fluxos OAuth padrão.

No blogue oficial da Cloudflare, indicaram que, no ano passado, foram introduzindo gradualmente parceiros iniciais, aperfeiçoando continuamente o mecanismo de consentimento, o processo de revogação e o modelo de segurança. Mas com a expansão da plataforma de programadores e o rápido aumento da procura de acesso delegado por ferramentas de agente de IA, "abrir o OAuth a todos os utilizadores" tornou-se uma condição necessária para o sucesso da plataforma, e não uma opção.

O OAuth auto-gerido permite que os programadores forneçam um fluxo de autorização padrão: os utilizadores concedem diretamente acesso com âmbito limitado, as aplicações sabem o que lhes é permitido fazer e os utilizadores podem revogar a qualquer momento. Para construir integrações SaaS, plataformas de programadores internos e vários tipos de ferramentas de agente de IA, esta é uma infraestrutura mais limpa do que os tokens de API.

Uma substituição de motor subjacente que envolve 130 milhões de linhas de dados

No entanto, para escalar a abertura do OAuth, a Cloudflare teve primeiro de resolver um problema de engenharia: o motor de autorização subjacente, Hydra, já não estava a aguentar a carga.

Hydra é um motor OAuth de código aberto que a Cloudflare implementou há vários anos para suportar a infraestrutura OAuth da plataforma. Teve um desempenho estável durante períodos de uso limitado, mas com a expansão da plataforma de programadores e a proliferação de fluxos de trabalho de IA, os gargalos de desempenho e as limitações funcionais do Hydra original tornaram-se cada vez mais evidentes.

O plano de atualização foi dividido em duas fases. A primeira fase foi a atualização do Hydra 1.X; os engenheiros descobriram que, mesmo com uma migração de versão menor, a escala das alterações na estrutura da base de dados não era insignificante. Reescreveram o script de migração SQL, adotando técnicas como CREATE INDEX CONCURRENTLY que não bloqueiam escritas, e personalizaram a versão de construção do Hydra para substituir as consultas SELECT * originais por campos explicitamente especificados, reduzindo a transferência desnecessária de dados.

A segunda fase foi a implantação azul-verde (blue-green deployment) do Hydra 2.X. A implantação azul-verde consiste em manter dois sistemas, antigo e novo, a funcionar simultaneamente, com o tráfego a ser gradualmente transferido apenas após confirmar a estabilidade do novo sistema, permitindo reversão instantânea a qualquer momento, reduzindo o risco de interrupção do sistema para perto de zero. A Cloudflare afirmou que, neste quadro, criaram um sistema de filas baseado no Cloudflare Queues para garantir que eventos de revogação fossem corretamente sincronizados entre os sistemas antigo e novo.

A escala da migração da base de dados foi considerável: um total de 132,5 milhões de linhas de dados foram atualizadas, 114,7 milhões de novas linhas foram inseridas e foram gerados 136,97 GB de dados temporários.

Problema de falha em cadeia do token de atualização em clientes MCP

Após a conclusão da transição azul-verde, os dados de monitorização revelaram um sinal inesperado: a taxa de erros de tokens de atualização aumentou.

Após investigar a causa, descobriu-se que o novo Hydra adotou um mecanismo de invalidação mais rigoroso para a reutilização de tokens de atualização: uma vez detetada a reutilização do mesmo token de atualização, todo o conjunto de credenciais de acesso (token de acesso e token de atualização) é revogado em conjunto.

Isto causou problemas para os clientes Wrangler e MCP, porque estes tipos de ferramentas, em cenários de rede instável ou pedidos concorrentes, já podiam naturalmente desencadear a reutilização do token de atualização.

A solução foi adicionar um "mecanismo de fusão de tokens de atualização" no Worker que encaminha o tráfego OAuth: quando são detetados múltiplos pedidos de atualização para o mesmo token a entrar simultaneamente, o sistema combina-os num único pedido, evitando desencadear a lógica de falha em cadeia. Esta correção fez com que o comportamento de integração dos clientes MCP voltasse ao normal.

Este episódio também revelou uma realidade: o padrão de comportamento de autorização das ferramentas de agente de IA tem diferenças estruturais em relação ao fluxo OAuth tradicional operado por humanos. As ferramentas de agente podem enviar um grande número de pedidos concorrentes de atualização de token num curto período de tempo, enquanto a implementação tradicional do OAuth não foi concebida para este cenário de uso.

Após a atualização, as melhorias nos indicadores de desempenho foram bastante significativas. A latência P95 da API caiu de 185 ms para 101 ms, uma redução de 45%; a memória residente ocupada reduziu de 888 MB para 763 MB, uma diminuição de 14%; as alocações de heap Go passaram de 449 MB para 271 MB, uma redução de 40%; o número de goroutines caiu de 4.015 para 3.076, uma redução de 23%; o uso de CPU passou de 1,07 núcleos para 0,67 núcleos, uma poupança de 37%.

A Cloudflare afirmou que a abertura do OAuth auto-gerido permite que os programadores construam soluções de integração com âmbitos de consentimento mais transparentes e revogação mais fácil, o que é particularmente importante para a saúde do ecossistema de ferramentas de agente de IA. Quando os modelos de IA operam serviços em nome dos humanos, "o que este agente está autorizado a fazer" e "como revogar o seu acesso" serão questões incontornáveis no quadro de confiança.