Cloudflare cria OAuth com Claude e divulga todos os prompts

• A Cloudflare anunciou um framework provedor de OAuth 2.1 como uma biblioteca TypeScript para Cloudflare Workers
• A maior parte da implementação foi escrita com o LLM Claude, da Anthropic, e revisada minuciosamente por engenheiros de segurança da Cloudflare
• A biblioteca oferece automação da autenticação para endpoints de API e tratamento automático do gerenciamento de tokens
• Suporta recursos importantes como os padrões mais recentes de OAuth e PKCE, registro dinâmico de clientes, definição de escopos de acesso e mais
• Destaca um projeto de segurança com criptografia de ponta a ponta em trechos críticos e refresh tokens de uso único

---

Introdução e importância do framework provedor de OAuth 2.1 para Cloudflare Workers

Este projeto open source é uma biblioteca TypeScript projetada para permitir implementar facilmente um servidor de autenticação OAuth 2.1 no ambiente Cloudflare Workers.
Em comparação com outros projetos semelhantes, seus principais pontos fortes são a escalabilidade e integração fluida voltadas à plataforma Cloudflare, além de um design centrado em segurança.
O foco está em algoritmos, conformidade com padrões de protocolo (RFC-8414, RFC-7591 etc.) e clareza na estrutura da biblioteca.
Em especial, houve um cuidado detalhado com segurança, como armazenamento em hash de tokens e segredos importantes, além de criptografia de ponta a ponta de props.
Como curiosidade, boa parte do código central e da documentação da biblioteca foi escrita com a colaboração do LLM Claude, mostrando um caso interessante de desenvolvimento.

Principais recursos e vantagens

• Envolve o código do Worker com OAuthProvider para adicionar automaticamente autenticação a endpoints de API
• O gerenciamento de tokens (criação, armazenamento, validação, revogação etc.) é tratado automaticamente, sem necessidade de implementar isso manualmente
• Dentro do handler fetch, o usuário pode receber diretamente como parâmetro as informações do usuário já autenticado e utilizá-las
• Não há restrições quanto a gerenciamento de usuários, autenticação ou forma de implementar a UI (o desenvolvedor pode escolher livremente a estrutura e o framework desejados)
• O repositório da biblioteca armazena apenas informações em hash, sem armazenar os próprios segredos, como chaves secretas

Essencial sobre como usar

• É possível exportar uma instância de OAuthProvider como entrypoint do Worker para atuar como handler fetch
• Com as opções apiRoute e apiHandler, define-se respectivamente a área de endpoints de API que exige autenticação e o handler real
• É possível definir os caminhos de cada endpoint OAuth padrão, como authorizeEndpoint, tokenEndpoint e clientRegistrationEndpoint
• Se necessário, também é possível detalhar políticas como escopos ou registro público de clientes
• Com defaultHandler, também é possível tratar de forma flexível requisições fora da API e falhas de autenticação

Objetos auxiliares e API

• É possível usar env.OAUTH_PROVIDER no handler fetch para analisar requisições relacionadas a OAuth, consultar informações de cliente, concluir autorizações e mais
• No processamento de requisições de API, quando o access token é válido, é possível acessar diretamente em ctx.props as informações de props por usuário já autorizadas
• Registro de clientes, lista de permissões (authorization grant), consulta e revogação de grants de um usuário específico também são fornecidos pela API oficial

Token Exchange Callback

• Há suporte ao callback tokenExchangeCallback, que permite atualizar dinamicamente valores de props durante emissão ou renovação de tokens
• Isso permite cenários mais complexos, como troca adicional de tokens integrada ao cliente OAuth (upstream token exchange)
• No callback, é possível retornar accessTokenProps, newProps e accessTokenTTL para implementar comportamentos personalizados
• Com a customização de accessTokenTTL, é possível alinhar o tempo de expiração do token com o sistema OAuth superior
• Como props pode conter informações sensíveis, todo esse valor é armazenado com criptografia de ponta a ponta

Respostas de erro personalizadas

• Com a opção onError, é possível tomar ações externas em caso de erro, como envio de notificações ou logging personalizado
• Se um Response for definido diretamente no retorno, o OAuthProvider pode sobrescrever a resposta de erro apresentada ao usuário no formato desejado

Projeto detalhado de segurança

Criptografia de ponta a ponta

• Dados e segredos relacionados a tokens são armazenados apenas como hash, e as informações de grant props são armazenadas criptografadas com o próprio token, aumentando a capacidade de resposta a incidentes de vazamento
• userId, metadata e afins não são criptografados para fins de auditoria (audit) e revogação, mas o desenvolvedor pode aplicar criptografia adicional se necessário

Projeto de refresh token de uso único

• Seguindo o requisito do OAuth 2.1 de "client binding ou uso único", a biblioteca adota uma solução intermediária que permite no máximo 2 refresh tokens paralelos
• Com isso, mesmo que a gravação do novo token falhe por problemas de rede, ainda existe uma proteção para permitir o uso do token anterior mais uma vez

Processo de desenvolvimento com Claude

• Grande parte desta biblioteca e da documentação foi inicialmente criada com o LLM Claude, da Anthropic, e depois revisada com rigor por engenheiros da Cloudflare conforme RFCs e critérios de segurança
• No início havia ceticismo em relação à geração de código por IA, mas a percepção mudou após a experiência prática com qualidade real e ganho de produtividade
• O fluxo de desenvolvimento, os prompts usados no Claude e o processo de melhoria do código foram todos divulgados com transparência no histórico de commits do Git

Outros pontos

• É obrigatório aplicar o binding do namespace Workers KV (OAUTH_KV); consulte storage-schema.md
• Para toda a API e helpers, consulte a definição da interface OAuthHelpers
• A biblioteca está atualmente em fase beta/pré-lançamento e a API pode mudar no futuro

---

[GN⁺]

Comentários no Hacker News

• Trecho apresentado do README. Esta biblioteca (e o documento de esquema) foi escrita em grande parte com a ajuda do modelo de IA Claude, da Anthropic. Engenheiros da Cloudflare fizeram uma revisão minuciosa e prestaram atenção à segurança e à conformidade com os padrões. Muitas melhorias foram feitas já nas entregas iniciais, principalmente dando prompts adicionais ao Claude e revisando iterativamente os resultados. Dá para verificar diretamente no histórico de commits como o Claude foi instruído e que código saiu disso. No começo, a posição cética tradicional era: “não se deve deixar um LLM escrever uma biblioteca de autenticação”. Até janeiro de 2025, eu também era muito cético em relação à IA e achava que LLMs eram apenas uma espécie de “gerador sofisticado de cadeia de Markov”, incapazes de criar algo realmente novo ou código de verdade. Comecei o projeto por diversão, mas fiquei chocado com a qualidade do código que saiu. Não era perfeito, mas bastava pedir correções para a IA e ela ajustava direito. Revisei linha por linha comparando com vários RFCs, junto com especialistas em segurança. Tentei testar meu ceticismo, mas o resultado acabou provando que eu mesmo estava errado. Vale muito a pena olhar o histórico de commits, especialmente os iniciais, para ver esse processo

  • Eu esperaria mesmo que um LLM conseguisse produzir esse tipo de código quando orientado corretamente por um engenheiro experiente. OAuth não é tecnologia nova, e provavelmente já havia uma enorme quantidade de exemplos open source e implementações em várias linguagens usados como dados. Mas continuo cético em relação à ideia de que LLMs vão contribuir de forma revolucionária para pesquisa realmente nova, ciência dos materiais, economia, invenções etc. Esses são domínios em que a “capacidade de aprender em tempo real” é realmente necessária, e os LLMs atuais só demonstraram habilidade com base em informações antigas que já conheciam. Resultados significativos costumam ser, na maioria dos casos, exemplos cherry-pick em ambientes muito limitados. Acho natural que um engenheiro experiente consiga gerar código novo com base em dados passados, mas ainda questiono se o custo ambiental e social da adoção de LLMs não é excessivo em relação à eficiência real obtida

  • Fiquei confuso com a frase “até janeiro de 2025 eu pensava como o (@kentonv)”, porque kentonv é outro usuário. Fiquei me perguntando se era uma conta alternativa do autor, ou um erro de digitação, ou um mal-entendido. Edit: vi que a maior parte do texto era citação do README. Acho que teria sido menos confuso se tivessem usado > e * para deixar as citações mais claras. Link para o perfil de kentonv

  • “Eu achava que LLM era um gerador sofisticado de cadeia de Markov” e “fiquei surpreso ao ver a IA produzir um código bem bom” não são opiniões contraditórias. Acho LLMs extremamente úteis, mas ainda assim sua essência parece próxima de um gerador de padrões. O ponto importante é que isso já pode ser suficiente, e que os humanos talvez também não sejam estruturalmente tão diferentes assim

  • Hoje estou mais cético do que pró-IA, mas mesmo assim continuo tentando introduzir IA no meu fluxo de trabalho. Na prática, sinto que explicar é mais difícil, então simplesmente fazer eu mesmo acaba sendo mais fácil. Também não acho muito divertido, mas como essa é a ferramenta do “futuro”, parece sensato aprender. Ainda vejo o tooling de IA de verdade como algo bem inicial. Continuo interessado em ver exemplos curiosos de UX surgindo daqui para frente

  • Indicação para olhar diretamente o histórico de commits de como o Claude foi instruído no começo e como gerou o código na prática. Link direto para a página dos primeiros commits. Havia muitas instruções claras e específicas, e também vale olhar o commit de exemplo 1 e o commit de exemplo 2

• Trecho de um commit com problema no workers-oauth-provider da Cloudflare. O Claude introduziu um bug em um commit anterior, e tentaram corrigi-lo várias vezes via prompt, mas continuou falhando. No fim, um humano corrigiu manualmente e até documentou no README a questão da especificação OAuth 2.1. Pessoalmente, isso bate muito com a minha experiência usando IA. Muitas vezes ela vai bem até a metade e depois sofre no restante

  • Chama atenção o fato de a IA ir bem até a metade, mas, quando erra uma vez, tudo depois desanda. Quando se detecta o erro, é preciso reescrever o prompt desde o início da conversa e recomeçar. Depois que ela erra uma vez, mesmo tentando corrigir, os resultados continuam saindo errados. Então é preciso colocar tudo com clareza na mensagem inicial correta e gerar tudo de novo desde o começo para não repetir o erro

  • Para mitigar esse problema, ajuda ter testes ou uma especificação clara e deixar a IA resolver. Alguns meses atrás, a IA levava muito tempo para resolver esse tipo de quebra-cabeça de especificação, e o resultado tinha qualidade inferior à de respostas rápidas. Mas recentemente os modelos melhoraram bastante, e esse tipo de tarefa ficou até bem interessante, especialmente quando dá para formalizar a especificação. Pessoalmente, achei que o Sonnet 3.7 foi um grande salto em relação ao 3.5, e o Gemini 2.5 Pro me impressionou ainda mais. O Sonnet 4 erra menos, mas, mesmo assim, do ponto de vista de engenharia de software (organização de requisitos, exploração de soluções técnicas, design de arquitetura, escrita de user stories e especificações, escrita de código), ainda é preciso conduzir bem a IA para obter resultados de qualidade. Além disso, incluir bons exemplos no contexto da IA maximiza bastante o efeito. Recentemente, ao criar um app com a OpenAI Realtime API, no começo falhei completamente, mas depois de adicionar duas páginas de documentação e um projeto demo ao workspace, o resultado saiu exatamente como eu queria imediatamente (mesmo no meu caso, em que eu precisava usar a API de outra forma)

  • Nos trechos citados das linhas 163 a 172 do commit, encontrei afirmações claramente incorretas ou que dependem da interpretação de cada implementação de A/S. O servidor de autenticação do Auth0 tem configuração de “leeway” levando em conta as condições de rede, mas alguns servidores de autenticação são bem mais rígidos. Como cada implementação tem detalhes de design diferentes, acho que a chance de um LLM implementar isso com segurança apenas com base em padrões (RFCs) e open source público ainda exige, no fim das contas, revisão humana em um nível comparável ao de fazer manualmente

  • Tenho curiosidade sobre estudos de longo prazo que mostrem se ferramentas baseadas em LLM realmente economizam mão de obra ou se apenas criam uma ilusão de produtividade

  • A partir dessas experiências, vejo que essas ferramentas de IA na verdade não estão entendendo de fato, e sim produzindo saídas emergentes a partir de um enorme conjunto de padrões

• O futuro do AI coding provavelmente não é a fantasia estilo LinkedIn/X de que engenheiros de software vão desaparecer e um empresário vai apertar um botão para tudo ficar pronto, e sim um cenário em que engenheiros experientes usam IA para gerar parte do código e depois revisam e testam tudo com cuidado. A pergunta realmente importante é: “o kentonv teria conseguido fazer essa biblioteca mais rápido sozinho, sem IA?”

  • Levei alguns dias para construir a biblioteca com IA. Se fosse fazer tudo manualmente, acho que levaria semanas, talvez até meses. Ainda assim, este é um caso extremamente ideal. Só funcionou porque havia um padrão claro, uma especificação de API clara e uma plataforma já bem conhecida. Quando tentei usar IA para mudar o próprio Workers Runtime, quase não houve ganho de tempo. Mas em codebases de outras pessoas, com as quais eu não tinha familiaridade, a IA realmente ajuda muito. Agora ficou mais fácil entrar em códigos complexos e desconhecidos; antes eu evitaria isso, mas hoje consigo fazer as mudanças de que preciso com muito mais facilidade

  • Sobre a pergunta se teria sido mais rápido fazer sozinho sem IA, eu diria com segurança que não. Com as ferramentas que temos hoje e com o conhecimento de uso que está evoluindo, acho que nos próximos 3 a 6 meses vai ficar mais rápido codificar soluções novas diretamente com IA. Mas considero essencial ter codebases bem documentadas, com estrutura clara e ciclos rápidos de feedback (bons linters e testes unitários). Estamos caminhando nessa direção

  • Pela minha experiência, quando a IA gera parte do código, eu preciso revisar e testar com extremo cuidado, e esse processo acaba sendo <i>mais lento</i> do que codificar tudo eu mesmo. Então, no estágio atual, a IA não me ajuda muito. Como diz o ditado, um ajudante ruim pode ser pior do que nenhum ajudante; nesse sentido, a IA ainda é um “mau ajudante”

  • Se o modelo for “engenheiros experientes deixam a IA gerar parte do código e fazem revisão e testes minuciosos”, então isso não significaria que, no lugar de 20 kentonv, bastariam 2? Será que vai continuar existindo trabalho para os outros 18? O caso do autor é um projeto tecnicamente difícil, mas fico curioso sobre o que muda no desenvolvimento de apps LoB (business line) mais sem graça

  • Se engenheiros experientes ficarem só revisando e testando minuciosamente, e todas as vagas de desenvolvedor júnior forem substituídas por IA, de onde virão os desenvolvedores experientes no futuro? Acho que até tarefas simples e repetitivas têm esse valor

• É curioso por si só ver tantos pontos e opiniões diferentes. Como líder em segurança na internet, a Cloudflare está mostrando uma tentativa de conectar o mundo com esse novo estilo de “vibe coding”, e sou grato por isso. Senti que esses prompts de IA, códigos etc. também incentivam outros desenvolvedores a explorar mais programação. O vibe programming foi um recurso muito significativo para me ajudar a sair de um estado depressivo e voltar a programar de um jeito que me é familiar. Espero que esse tipo de experiência ajude outras pessoas também. Imagino que as gerações presentes e futuras vão usar esse tipo de abordagem. Mas também acho que precisamos discutir como isso pode se relacionar com saúde mental e questões psicológicas. No fim, é importante lembrar que essas ferramentas são meios de apoio aos humanos, e pensar em como usá-las para crescer com entusiasmo. Espero que surjam mais exemplos no open source que mostrem não só capacidade técnica, mas também lógica e uma abordagem ponderada de projeto. Meus elogios novamente à Cloudflare

• Foi reunido um conjunto de exemplos representativos de trocas de prompts. No exemplo de transcrição de prompt, até o custo real total ($6.45) é divulgado. Também há links para materiais como o commit relacionado 1 e o commit 2. É surpreendente como ainda há pouco relato realmente bom sobre fluxos de trabalho com IA (especialmente de gente experiente), porque isso acaba soterrado pelo hype. Além de todo list, queria ver mais exemplos de live coding de verdade. Também pode valer consultar os textos do antirez e do tptacek (caso do antirez, texto do tptacek)

  • Não rastreei exatamente, mas estimo que o custo de uso do Claude tenha ficado em torno de $50. Comparado ao tempo economizado, é um custo irrelevante

• Acho que “vibecoding” no fim não vai sobreviver. Ainda é necessário que ótimos programadores validem e corrijam bugs, e houve bugs que a IA não conseguiu consertar. No fim, essas ferramentas são aceleradores para quem já entende muito bem o trabalho em questão. Talvez até sirvam para uma homepage bem básica, mas ferramentas que automatizam isso já existem há anos

  • No momento, vibecoding é ideal para tarefas de baixo risco. GUI, apps CRUD, experimentos pontuais etc. É útil por dar novos poderes a quem não tem tanta capacidade técnica. Neste caso, eu não chamaria de vibecoding, e sim de LLM-assisted coding

  • Na prática, parece que “vibecoding” às vezes é usado como um espantalho para atacar. Afinal, se alguém pega código feito por LLM e só faz uns pequenos ajustes, isso também não seria vibe coding?

• Sou muito grato ao OP por ter publicado não só o código gerado por IA, mas também os prompts. Pessoalmente, tenho sofrido com alucinações ao tentar usar LLM para desenvolver código não web (especialmente, hoje em dia, engenharia reversa de SAP ABAP para encaixar dados em uma implementação .NET voltada para Snowflake). Como eu via outras pessoas relatando muitos casos de sucesso, achei que o problema eram meus prompts, mas este caso publicado me mostrou que talvez eu não esteja tão longe assim. Acho que o motivo de LLM funcionar mal para mim é que o problema que estou resolvendo é um pouco raro e novo. Se não for um alvo muito treinado, como esse caso de OAuth exposto no GitHub, o LLM não acompanha bem

• Esse tipo de código repetitivo, já implementado centenas de vezes, é perfeito para IA. O código inteiro tem algo em torno de 1200 linhas, então é de pequena escala. O que me surpreende é que, mesmo usando IA, ainda tenha levado mais de dois dias

• Nos últimos meses, usando o Claude no Cursor para tocar meu próprio projeto greenfield, cheguei a três conclusões: primeiro, minha produtividade aumentou enormemente. Segundo, estou mentalmente muito mais cansado do que antes. Terceiro, as ferramentas começaram a evoluir bem rápido mesmo em períodos curtos, o que está amplificando os dois efeitos anteriores

  • Minha experiência, e a de outros desenvolvedores com quem conversei, é exatamente essa. LLM-assisted coding realmente ajuda bastante na produtividade, mas também consome muito mais energia. Chega a ser estranho

  • Pergunta sobre esse ponto de “ficar mais cansado”. Eu uso meu agente (Devstral) em um formato de “pair programming”, em vez do jeito tradicional, e revisar é muito mais fácil do que digitar todo o código manualmente. Em termos de tempo, isso é uma grande vantagem. No vibe coding, o contexto da codebase se perde e depois a revisão e a entrada no projeto ficam muito mais difíceis. Já no pair programming, o contexto vai sendo acumulado, então a revisão parece bem mais rápida

  • Comigo é justamente o contrário. Como a IA cuida sozinha de todos os detalhes menores, isso me dá uma sensação enorme de alívio. Fico livre para focar em objetivos mais altos, como arquitetura

• Acho bem engraçado uma empresa como a Cloudflare exibir erro de "Too Many Requests"

  • Eu também