Cloudflare OAuth para todos os clientes
(blog.cloudflare.com)- A Cloudflare passou a permitir que clientes criem diretamente apps de OAuth autogerenciados, possibilitando oferecer acesso à API da Cloudflare por meio de um fluxo padrão de autorização delegada
- Antes, apenas alguns parceiros integrados manualmente podiam usar OAuth de terceiros, e desenvolvedores de integrações próprias precisavam depender de tokens de API, que não se encaixam bem em fluxos de apps delegados
- Para a abertura geral, a empresa melhorou a tela de consentimento, a revogação e a exibição de propriedade do app, além de atualizar gradualmente o mecanismo OAuth Hydra da versão 1.X para a 2.X
- Durante a atualização, ocorreram migrações de schema, erros de renovação de tokens, risco de perda de eventos de revogação e aumento de 403; a resposta incluiu criação concorrente de índices, fila de replay de revogações e restauração de dados
- Após a atualização, o P95 da API caiu de 185 ms para 101 ms, uma redução de 45%, e o uso de CPU também caiu de 1,07 core para 0,67 core, estabilizando a base operacional para OAuth público
Ampliação do acesso ao Cloudflare OAuth
- A Cloudflare já vinha permitindo criar automações, CI/CD e integrações de infraestrutura com suas APIs de plataforma, e agora abriu o OAuth autogerenciado para todos os clientes
- O Cloudflare OAuth em si não é um recurso novo e já era usado em integrações de parceiros como Wrangler e PlanetScale
- Porém, o OAuth de terceiros existente só era oferecido a um pequeno número de integrações integradas manualmente, não estando aberto ao ecossistema mais amplo de desenvolvedores
- Desenvolvedores que criavam integrações próprias precisavam depender de tokens de API, um modelo difícil de gerenciar e pouco adequado a muitos fluxos de aplicações delegadas
- Com OAuth autogerenciado, desenvolvedores podem oferecer um fluxo OAuth padrão no qual os clientes aprovam diretamente o acesso com escopos definidos
- Os principais casos de uso são integrações SaaS, plataformas internas de desenvolvedores e ferramentas de agentes
- Usuários passam a ter consentimento mais claro, revogação fácil e mais controle sobre permissões de aplicações
Reforço da base de segurança para a abertura geral
- A solução OAuth inicial era suficiente para um pequeno número de parceiros gerenciados, mas seu modelo de permissões, experiência de consentimento e mitigação de abuso ainda não eram maduros o bastante para uma abertura a todos os clientes
- No início deste ano, a Cloudflare melhorou a experiência de consentimento, exibindo com mais clareza qual aplicação está solicitando acesso e quais permissões receberá
- No dashboard, adicionou uma função de revogação, permitindo que desenvolvedores controlem com facilidade quais aplicações podem acessar seus dados
- Para reduzir ataques de phishing via OAuth, também tornou mais visível a propriedade do app
- Para abrir o OAuth autogerenciado a todos os clientes, era necessário atualizar o mecanismo OAuth mantendo a estabilidade dos dados e a segurança, com mínima interrupção para usuários
Preparação da atualização do Hydra 1.X
- Há muito tempo, a Cloudflare usa o mecanismo OAuth open source Hydra como motor interno do Cloudflare OAuth
- Com o crescimento da plataforma de desenvolvedores e o aumento de workflows com agentes, tornou-se necessária uma grande atualização para novos recursos e melhorias de desempenho
- Em vez de fazer uma grande atualização de uma só vez, a empresa escolheu uma abordagem sequencial: primeiro migrar para a versão 1.X mais recente, avaliar mudanças de comportamento e desempenho, e então avançar para a atualização 2.X
- Mesmo a atualização 1.X poderia impactar clientes
- O banco de dados do Hydra criava índices mantendo locks exclusivos em tabelas importantes
- Adicionava colunas a tabelas importantes e movia outras colunas para novas tabelas
- O SDK da versão do Hydra em uso executava
SELECT *, o que poderia causar problemas de desserialização quando o schema mudasse
- Para evitar impacto aos usuários, a Cloudflare reescreveu as migrações SQL usando abordagens como
CREATE INDEX CONCURRENTLYe criou uma versão customizada do Hydra que seleciona colunas explícitas em vez deSELECT *
Estratégia de atualização para o Hydra 2.X
- Como a atualização 2.X envolvia mudanças grandes de schema, uma atualização in-place não era adequada, e a Cloudflare escolheu uma estratégia blue-green
- Simplesmente virar uma chave para a nova versão não seria suficiente
- A atualização e a migração levariam várias horas
- Durante esse período, o sistema precisava continuar funcionando corretamente
- A primeira opção blue-green era bloquear escritas no banco de dados, impedindo novas autorizações
- Novas escritas durante a transição não seriam perdidas
- Usuários sem credenciais já válidas não poderiam usar apps OAuth existentes
- Durante a atualização, usuários não poderiam revogar o acesso de aplicações
- A estratégia final foi manter as escritas no banco de dados, aceitando a possibilidade de perda de algumas escritas e reduzindo esse risco
- Para diminuir novas escritas de tokens, o tempo de expiração dos tokens foi aumentado para várias horas
- Apps que haviam recebido tokens antes da atualização poderiam continuar sendo usados sem nova renovação
- A perda de eventos de revogação foi evitada com um sistema de filas baseado no Cloudflare Queues
- Quando um evento de revogação ocorria, a informação era registrada na fila
- Após mudar para o banco de dados da versão green, a fila era esvaziada para reproduzir as revogações ocorridas durante a janela de atualização
- Se esse processamento falhasse, o acesso de uma aplicação revogada pelo usuário poderia ser restaurado inadvertidamente
Atualização 1.X e problema de renovação de tokens
- A primeira atualização para a versão 1.X mais recente ocorreu sem grandes problemas do ponto de vista operacional
- As migrações customizadas de banco de dados foram executadas mais rapidamente do que o esperado e não afetaram usuários
- Como a versão antiga não conseguia fazer introspecção de tokens criados pela nova versão, foi necessário um hard cutover
- Após o cutover, aumentaram erros de refresh token que antes não eram visíveis
- Isso ocorreu devido ao comportamento mais rigoroso da nova versão na invalidação de refresh tokens
- Se um refresh token fosse reutilizado, o Hydra invalidava toda a cadeia de access tokens e refresh tokens
- Como Wrangler e clientes MCP têm alto volume de requisições, uma única reutilização de refresh token poderia invalidar toda a sessão
- A Cloudflare adicionou um comportamento de coalescing de refresh tokens ao Worker que roteia o tráfego OAuth para o destino correto
- As requisições de refresh token passaram a ser armazenadas em cache por um breve período antes de chegar ao Hydra
- Ao detectar uma nova tentativa, o Worker responde por um caminho curto sem invalidar o token
- O Hydra 2.X inclui um
refresh token grace periodconfigurável, que permite novas tentativas de refresh token por certo período sem invalidar toda a cadeia
Transição para 2.X e processo de recuperação
- Como a Cloudflare não podia aceitar uma interrupção de várias horas com alto impacto para usuários, executou uma atualização blue-green
- Na prática, a transição exigiu mais do que uma simples cópia do banco de dados e a implantação do novo Hydra
- Ativação da fila de captura para replay de revogações
- Cópia do banco de dados e restauração no novo destino
- Limpeza de dados existentes que violavam restrições da nova versão
- Cutover simultâneo do serviço Hydra e de dois sistemas internos essenciais
- Monitoramento e validação após o cutover
- A janela de atualização foi escolhida no horário de menor número de requisições por segundo ao Hydra, para minimizar a perda de escritas de tokens
- A migração em produção rodou bem no novo banco de dados, exceto por alguns ajustes de timeout, e o tempo puro de execução foi de cerca de 3 horas
- Logo após a transição de tráfego, uma tarefa de limpeza de dados do authorization service passou a excluir dados de OAuth policy em excesso
- Esse serviço depende da API de consent session do Hydra
- Uma das migrações do Hydra corrompeu parte do estado de sessões OAuth válidas, marcando sessões válidas como inválidas
- A inconsistência entre o Hydra e o authorization service apareceu como um aumento de 403
- A Cloudflare mitigou o problema com restauração de dados e iniciou melhorias no comportamento de OAuth authorization para reduzir a dependência de dados estáticos de policy
- Outras pequenas correções decorrentes de comportamentos específicos de alguns clientes também foram aplicadas rapidamente
Melhorias de desempenho após a atualização
- Após a conclusão da atualização da versão do Hydra, o tráfego OAuth permaneceu estável, e o desempenho e a confiabilidade do sistema para clientes melhoraram
- A nova base é a mesma das novas APIs OAuth já validadas em staging e possibilitou o lançamento do OAuth autogerenciado em 3 de junho
- Principais números observados durante a migração do banco de dados:
- Linhas atualizadas: 132,5 M
- Linhas inseridas: 114,7 M
- Bytes temporários: 136,97 GB
- Commits de transação: 22,2 mil
- As métricas médias de desempenho do Hydra melhoraram de forma geral após a atualização
- P95 da API: 185 ms → 101 ms, redução de 45%
- Memória RSS: 888 MB → 763 MB, redução de 14%
- Go heap alloc: 449 MB → 271 MB, redução de 40%
- Goroutines: 4015 → 3076, redução de 23%
- CPU: 1,07 core → 0,67 core, redução de 37%
Como começar
- Atualmente, todos os clientes da Cloudflare podem criar suas próprias aplicações OAuth e construir integrações sobre a Cloudflare
- Para começar, consulte a documentação ou crie seu primeiro app OAuth na página OAuth apps do dashboard
1 comentários
Comentários do Hacker News
Sou a pessoa que criou o Ory Hydra. Fiquei muito feliz ao ver este post de blog e a explicação técnica, e jamais imaginei que esse software acabaria protegendo empresas de internet no mundo todo
É bom ver que a versão 2.x funciona bem nessa escala, e o uso de CPU também parece absurdamente baixo
Se aparecer algum problema, também existe uma versão comercial mais rápida. Se você tiver interesse em OAuth próprio, IAM, permissões ReBAC, chaves de API e segurança para agentes, pode ver os produtos open source e comerciais em https://github.com/ory e https://www.ory.com/
No passado, operei em self-hosting o framework identity server para dotnet, processando dezenas de bilhões de requisições por mês, e nessa escala OAuth e OpenID Connect são praticamente um problema resolvido, com baixa carga de manutenção
Era um serviço central da organização e também tinha forte exigência de compliance, mas a equipe responsável provavelmente tinha umas 3 pessoas e ele ainda funciona bem hoje
Eu nunca entendi por que existe tanta confusão em torno desses protocolos, e quase todo engenheiro júnior com quem trabalhei teve dificuldade para entendê-los. O blog do Scott Brady https://www.scottbrady.io/ ajuda muito nesse tema
Parece que autenticação/autorização desperta um “medo” primordial nos engenheiros. Eles estão acostumados a resolver problemas, mas autenticação/autorização entra como uma pré-condição para essa resolução e acaba criando custo cognitivo
Bem típico da Cloudflare. Funciona bem para todo mundo e não é tão caro, mas como resultado de todas essas vantagens ela acaba se tornando o centro de tudo
Sou Grant. Junto com Aeneas, escrevi a maior parte do código de migração 2.0. Obrigado ao time da Cloudflare pelo post
Fiquei curioso se a parte “Nossa investigação mostrou que houve um problema em uma das migrações do Hydra que corrompeu o estado de algumas sessões OAuth válidas, e por isso a migração marcou essas sessões como inválidas” se refere a um dos arquivos de migração open source
Não estou mais envolvido com o projeto, mas queria saber se isso já foi corrigido no upstream
Para o contexto completo, isso pelo menos precisaria incluir um plano para os fluxos de autorização e autenticação dentro do ecossistema da Cloudflare, então tenho sentimentos mistos. Nem exemplo no GitHub existe
Ainda assim, é verdade que a Cloudflare começou na direção certa, mas ainda falta muito em comparação com toda a suíte de produtos subjacente da Ory. O Ory Kratos cuida de identidade, login, cadastro, recuperação, multifator etc.: https://github.com/ory
Acho que o escopo completo também precisaria incluir armazenamento de usuários, SAML e um plano para modelo organizacional multi-tenant. Um bom exemplo é o Zitadel https://github.com/zitadel, que oferece UI de administração para multitenancy organizacional, suporte a OIDC/PKCE e também permite encaixar um pouco de RBAC
O Supabase também oferece autenticação gerenciada e open source: https://github.com/supabase/auth
Tirando a digressão de que “MCP está morto e Skills é para sempre”, estou preocupado que em todos esses casos o plano de acoplar MCP e fazer rotação de chaves vá explodir em breve
Registro dinâmico de cliente no OAuth 2.0 (RFC 7591): https://datatracker.ietf.org/doc/html/rfc7591
https://modelcontextprotocol.io/specification/2025-03-26/bas...
Gostaria especialmente de ouvir opiniões no contexto de SaaS multi-tenant e assistentes de IA embarcados
No fluxo de redirecionamento normalmente usado ao conectar MCP a agentes, a especificação praticamente não diz como tornar isso seguro
Você não quer deixar qualquer um registrar um cliente com um callback arbitrário. Isso é um caminho aberto para phishing
Se alguém registrar um cliente com uma URL de callback maliciosa e depois enganar o usuário para clicar em um link que inicia esse fluxo, um provedor de identidade legítimo autentica o usuário e então entrega o token de acesso ao atacante
A especificação menciona por alto um token de acesso inicial que o cliente obtém antes do registro, mas faltam detalhes, e isso provavelmente não funciona bem quando cada usuário final vira um cliente
O ideal seria poder definir uma allowlist de padrões de redirecionamento para restringir a destinos como o ChatGPT. Mas isso é comportamento fora do padrão, então os fornecedores de IAM não estão com pressa
Não entendo qual é a intenção aqui. Não existe mundo em que isso termine bem. A Cloudflare é quase uma provedora de infraestrutura, e um modelo de infraestrutura em que algum usuário pode delegar permissões da própria conta a um cliente de terceiros tem alto potencial de abuso
Se uma empresa como a AWS não faz isso, imagino que exista uma boa razão
Por exemplo, o IAM pode dar ao GitHub Actions executado a partir de um repositório específico permissão para atualizar uma Lambda
OAuth e autenticação enterprise talvez sejam das piores coisas já criadas. Podem ser a parte mais confusa e irritante de lidar com nuvem
Até ferramentas de IA levaram 1 ano só para lidar com OAuth básico em sistemas headless, sem assumir que podem abrir um navegador
Se vamos cair em toda a toca do coelho de autenticação dos grandes provedores de nuvem, como RBAC/IAM/identidade de workload/contas de serviço, seria bom pelo menos deixar uma forma simples para uso individual
Basta uma chave de API. Guarde em segredo e revogue quando precisar; não precisa de 10 mil camadas de tranqueira de autenticação emaranhadas em todos os níveis de todas as plataformas
É um pesadelo de privacidade
Acabamos de lançar o Ory Talos para chaves de API (https://github.com/ory/talos). É uma boa alternativa quando OAuth2 é demais para o caso de uso
Também existem casos de uso e preocupações de segurança que justificam usar OAuth2. Especificações como DPoP podem tornar esses fluxos mais seguros
O caso de uso apresentado aqui parece adequado para OAuth2, mas não serve para tudo. A complexidade torna mais difícil manter o sistema seguro
A vantagem de OAuth2/OIDC é que a confiança não fica com quem possui a chave de API, mas com a identidade real que precisa do acesso
Dizer que autenticação é difícil vale para autenticação de muitos usuários. Autenticação para você mesmo é muito simples, e fica ainda mais fácil com um framework decente
Se estiver inseguro com a implementação, jogue isso em um dos modelos mais recentes. Eles são bem bons em encontrar problemas em um sistema de autenticação tão simples
“Licença Enterprise da Ory: desbloqueia recursos de nível enterprise como SLA de segurança para CVE, SAML, organizações B2B, multitenancy e melhor escalabilidade” [0]
Ou então você pode simplesmente continuar usando o Keycloak, que oferece um produto totalmente self-hosted [1]
[0]https://github.com/ory
[1]https://www.keycloak.org/
A razão de existir uma versão comercial é a questão de como sustentar financeiramente open source de nível mundial. Não é algo ruim, e sim bom, que exista um modelo de negócio que funcione para open source que sustenta algumas das maiores empresas de software do planeta
Aliás, a IBM também descobriu uma forma de ganhar dinheiro com o Keycloak
Isso é basicamente sobre OAuth para acesso à conta Cloudflare, não algum tipo de recurso genérico de “login” hospedado pela Cloudflare para apps personalizados
Eu achava que entendia o que era OAuth, mas este texto me confundiu. Eu via isso como um protocolo padronizado para fornecer chaves de acesso por cliente
O que seria OAuth autogerenciado aqui? É preciso explicar a que está sendo concedido acesso, quem é o cliente e quem é o parceiro
Isso permite hospedar você mesmo o sistema OAuth que aprova ou nega acesso aos seus próprios recursos. Em vez de esperar a Cloudflare permitir Y sob a condição X, você pode criar a lógica que quiser
Essencialmente, o fluxo é “fazer login na Cloudflare” → a Cloudflare verifica o uso de OAuth autogerenciado → redireciona para o seu OAuth → a Cloudflare confia na resposta → se o usuário aprovar, permite acesso à conta