A Cloudflare abre um ecossistema OAuth para todos os clientes, chamado OAuth autogerenciado. Empresas e desenvolvedores agora podem criar seus próprios aplicativos OAuth que podem acessar contas Cloudflare e, assim, construir integrações baseadas na API Cloudflare. Até agora, o OAuth de terceiros estava disponível apenas para alguns parceiros aprovados manualmente. Qualquer pessoa que queira desenvolver suas próprias conexões geralmente precisa usar tokens de API, que muitas vezes são menos adequados para acesso delegado e mais difíceis de gerenciar.
Leia mais depois do anúncio
OAuth é um padrão que permite que aplicativos acessem recursos limitados em nome de usuários sem obter senhas. O processo utiliza uma caixa de diálogo de consentimento, limitando as permissões (escopo) e permitindo que os usuários revoguem o acesso concedido centralmente.
Mais controle para desenvolvedores e usuários
No blog, a Cloudflare justificou a introdução com as necessidades da plataforma do desenvolvedor. À medida que mais clientes utilizam ferramentas de integração, automação e agentes, o acesso delegado se torna mais importante para conexões SaaS e plataformas internas de desenvolvedores.
Paralelamente à inauguração, a Cloudflare expandiu suas funções de segurança e gerenciamento. Isso inclui uma caixa de diálogo de consentimento mais precisa, melhor visibilidade da propriedade do aplicativo para evitar phishing e uma função central de cancelamento no painel.
Renovações elaboradas em segundo plano
Essas versões exigem mudanças profundas na infraestrutura do OAuth. A Cloudflare continua usando o mecanismo Hydra de código aberto, mas precisa migrar para uma versão mais recente. O provedor divide a conversão em duas etapas: primeiro a atualização para a atual série 1.x, depois a mudança para 2.x.
Leia mais depois do anúncio
A primeira atualização trouxe obstáculos técnicos. A migração do banco de dados bloqueia temporariamente as tabelas exclusivamente e, portanto, bloqueia as operações OAuth em andamento. Portanto, a Cloudflare adaptou a migração SQL e a utilizou CREATE INDEX CONCURRENTLY e alterar as consultas do Hydra SDK para serem desserializadas SELECT *– A cirurgia deve ser evitada.
Para o grande salto para 2.x, a Cloudflare escolheu um processo azul esverdeado. A nova versão é executada em paralelo com a cópia do banco de dados de produção. Os operadores mudam somente após a conclusão da migração. Para evitar a perda de dados durante a fase de transição, a Cloudflare intercepta as revogações por meio de uma fila e as reproduz após mudar para um novo ambiente.
Comportamento do token e efeitos de migração
Depois de mudar para 1.x, a Cloudflare registrou mais erros com tokens de atualização. O motivo é o comportamento estrito da nova versão: se o token de atualização for usado novamente, o Hydra invalidará toda a cadeia de acesso e o token de atualização. Isso afeta principalmente clientes com alta frequência de solicitações, como clientes Wrangler e MCP. A Cloudflare intercepta isso temporariamente em trabalhadores que encaminham tráfego OAuth: tentativas duplicadas de atualização são temporariamente armazenadas em buffer lá e não são passadas para o Hydra.
A mudança para 2.x também não foi tranquila. O trabalho de limpeza no serviço de autorização remove agressivamente os dados da política OAuth. Isso é causado por uma migração defeituosa do Hydra que destrói o estado válido da sessão. Isso causa uma discrepância entre o Hydra e o serviço de autorização, o que resulta em um erro 403. A Cloudflare então reproduz os dados e otimiza o comportamento de autorização.
Segundo a empresa, assim que a migração for concluída, o tráfego OAuth ficará mais estável e melhor. O sistema ativo atual é baseado na mesma base da API OAuth mais recente que a Cloudflare validou no ambiente de teste. Os clientes agora podem criar seus próprios aplicativos OAuth e desenvolver integrações com base nisso, sem qualquer acordo especial.
Leia também
(foo)
