Cloudflare construye OAuth junto con Claude y hace públicos todos los prompts

• Cloudflare anunció un framework proveedor de OAuth 2.1 como librería TypeScript para Cloudflare Workers
• La mayor parte de la implementación fue escrita con el LLM Claude de Anthropic y revisada minuciosamente por ingenieros de seguridad de Cloudflare
• Esta librería ofrece automatización de autenticación para endpoints de API y manejo automático de tokens
• Soporta funciones clave como los estándares más recientes de OAuth y PKCE, registro dinámico de clientes y configuración de alcances de acceso
• Destaca un diseño de seguridad con cifrado de extremo a extremo en secciones críticas y refresh tokens de un solo uso, entre otros

---

Introducción e importancia del framework proveedor de OAuth 2.1 para Cloudflare Workers

Este proyecto de código abierto es una librería TypeScript diseñada para implementar fácilmente un servidor de autenticación OAuth 2.1 en el entorno de Cloudflare Workers.
En comparación con otros proyectos similares, sobresale por su escalabilidad y su integración fluida enfocadas en la plataforma Cloudflare, además de su diseño centrado en la seguridad.
Pone énfasis en los algoritmos, el cumplimiento de estándares de protocolo (RFC-8414, RFC-7591, etc.) y la claridad de la estructura de la librería.
En particular, fue diseñada con detalle para reforzar la seguridad, por ejemplo mediante el almacenamiento con hash de tokens y secretos clave, y el cifrado de extremo a extremo de props.
Como dato interesante, gran parte del código central y de la documentación de la librería se escribió con la colaboración del LLM Claude, mostrando un caso de desarrollo llamativo.

Funciones principales y ventajas

• Envuelve el código del Worker con OAuthProvider para añadir automáticamente autenticación a endpoints de API
• El manejo de tokens (creación, almacenamiento, validación, revocación, etc.) se procesa automáticamente, sin necesidad de implementarlo manualmente
• Dentro del handler de fetch, el usuario puede recibir y usar directamente como parámetro la información del usuario ya autenticado
• No impone restricciones sobre la gestión de usuarios, la autenticación ni la implementación de la UI (el desarrollador puede elegir libremente la estructura y el framework que prefiera)
• El repositorio de la librería almacena solo información hasheada, y no guarda los secretos en sí, como claves secretas

Puntos clave de uso

• Se puede exportar una instancia de OAuthProvider como entrypoint del Worker para que cumpla la función de handler de fetch
• Con las opciones apiRoute y apiHandler se definen, respectivamente, la sección de endpoints de API que requiere autenticación y el handler real
• Se pueden definir rutas para cada endpoint estándar de OAuth, como authorizeEndpoint, tokenEndpoint y clientRegistrationEndpoint
• Si hace falta, se pueden detallar políticas como scope o el registro de clientes públicos
• Mediante defaultHandler, también es posible manejar con flexibilidad las solicitudes fuera de la API y las solicitudes con autenticación fallida

Objetos helper y API

• Se puede usar env.OAUTH_PROVIDER en el handler de fetch para parsear solicitudes relacionadas con OAuth, consultar información de clientes, completar autorizaciones y más
• Al procesar solicitudes de API, si el access token es válido, se puede acceder directamente a la información de props por usuario ya autorizada mediante ctx.props
• La API oficial también ofrece registro de clientes, lista de permisos (authorization grant), consulta y revocación de grants de un usuario específico, entre otros

Token Exchange Callback

• Al emitir o renovar tokens, se soporta un callback (tokenExchangeCallback) que permite actualizar dinámicamente los valores de props
• También puede soportar escenarios complejos, como intercambio adicional de tokens vinculado con el cliente OAuth (upstream token exchange)
• En el callback se pueden devolver accessTokenProps, newProps, accessTokenTTL, etc., para implementar comportamientos personalizados
• Mediante la personalización de accessTokenTTL, es posible alinear el momento de expiración del token con el sistema OAuth superior
• Como props puede contener información sensible, ese valor completo se almacena cifrado de extremo a extremo

Respuestas de error personalizadas

• Con la opción onError, cuando ocurre un error se pueden ejecutar acciones externas como enviar notificaciones o hacer logging personalizado
• Si se define directamente un Response de retorno, se puede sobrescribir en el formato deseado la respuesta de error que OAuthProvider entrega al usuario

Diseño detallado de seguridad

Cifrado de extremo a extremo

• Los datos relacionados con tokens y secretos se almacenan solo como hash, y la información de grant props se guarda cifrada con el propio token, lo que mejora la capacidad de respuesta ante filtraciones
• userId, metadata y otros campos no se cifran para fines de auditoría y revocación; si es necesario, el desarrollador puede aplicar cifrado adicional

Diseño de refresh tokens de un solo uso

• Según el requisito de OAuth 2.1 de "client binding o single-use", esta librería usa un diseño de compromiso que permite hasta 2 refresh tokens en paralelo
• Con esto se ofrece una salvaguarda para que, si falla el almacenamiento del nuevo token por problemas de red u otras causas, el token anterior pueda usarse una vez más

Proceso de desarrollo basado en Claude

• Esta librería y gran parte de su documentación tuvieron un borrador inicial creado con el LLM Claude de Anthropic, y luego ingenieros de Cloudflare lo revisaron cuidadosamente según RFC y criterios de seguridad
• Al principio había escepticismo respecto a la generación de código con IA, pero esa visión cambió tras experimentar mejoras reales en calidad y productividad
• El flujo de desarrollo, los prompts de Claude y el proceso de mejora del código se publicaron de forma totalmente transparente en el historial de commits de Git

Otros puntos

• Es obligatorio aplicar el binding del namespace de Workers KV (OAUTH_KV); consultar storage-schema.md
• Para la API completa y los helpers, consultar la definición de la interfaz OAuthHelpers
• La librería está actualmente en etapa beta/prerelease y su API podría cambiar en el futuro

---

[GN⁺]

Opiniones de Hacker News

• Extracto del README. Esta librería (y el documento del esquema) fue escrita en gran parte con ayuda del modelo de IA Claude de Anthropic. Los ingenieros de Cloudflare la revisaron a fondo y pusieron atención en la seguridad y el cumplimiento de estándares. Incluso en los resultados iniciales hubo muchas mejoras, principalmente dándole prompts adicionales a Claude y revisando iterativamente el resultado. En el historial de commits se puede ver directamente cómo se le dio prompt a Claude y qué código produjo. Al principio, la postura tradicional escéptica era que “no se debe dejar que un LLM escriba una librería de autenticación”. Incluso hasta enero de 2025 yo también era muy escéptico con la IA, y pensaba que los LLM no eran más que “generadores sofisticados de cadenas de Markov”, incapaces de producir novedad o código real. Empecé el proyecto por diversión, pero me sorprendió que saliera código mejor de lo esperado. No era perfecto, pero si le pedías a la IA que lo corrigiera, lo arreglaba correctamente. Todo se comparó línea por línea con varios RFC y se revisó junto con expertos en seguridad. Intenté poner a prueba mi escepticismo, pero al final el resultado demostró que yo estaba equivocado. Vale mucho la pena revisar el historial de commits, sobre todo los iniciales, para ver este proceso

  • Esperaría que un LLM pudiera producir este nivel de código cuando un ingeniero experimentado le da prompts adecuados. OAuth no es una tecnología nueva, y seguramente ya había muchísimos ejemplos open source e implementaciones en varios lenguajes dentro de sus datos. Pero sigo siendo escéptico ante las afirmaciones de que un LLM vaya a contribuir de forma revolucionaria a investigación totalmente nueva, ciencia de materiales, economía, invención, etc. Ahí realmente hace falta la capacidad de “aprender en tiempo real”, y los LLM actuales solo han demostrado capacidades basadas en información vieja que ya conocían. Los resultados significativos suelen ser casos cherry-pick en entornos muy limitados. Si hay un ingeniero experimentado, me parece natural que se pueda generar código nuevo a partir de datos previos, pero todavía me pregunto si la carga ambiental y social de adoptar LLM está sobredimensionada frente a la eficiencia real que aporta

  • Me confundió la expresión “hasta enero de 2025 yo pensaba igual que (@kentonv)”, porque kentonv es otro usuario. Me pregunto si es una cuenta alterna suya, o si es un error o malentendido. Edición: confirmé que la mayor parte del texto era una cita del README. Creo que habría sido menos confuso si hubiera usado los símbolos > y * para dejar clara la cita. Adjunto enlace al perfil de kentonv

  • “Pensaba que los LLM eran generadores sofisticados de cadenas de Markov” y “me sorprendió que la IA produjera código bastante decente” no son opiniones contradictorias. Siento que los LLM son muy útiles, pero su esencia sigue estando cerca de un generador de patrones. Lo importante es que ese nivel ya sea suficiente, y que los humanos quizá tampoco seamos estructuralmente tan distintos

  • Hoy en día tengo una postura más escéptica que pro-IA, pero de todos modos sigo intentando incorporar IA a mi flujo de trabajo. En la práctica, me cuesta más explicarle las cosas y siento que a veces es más fácil hacerlo yo mismo. Tampoco es especialmente divertido, pero como esta es la herramienta del “futuro”, creo que conviene aprenderla. Aún veo el tooling de IA real en una etapa muy temprana. Me sigue interesando ver ejemplos de UX sorprendentes más adelante

  • Recomienda revisar directamente el historial de commits para ver cómo se le dio prompt a Claude al principio y cómo generó realmente el código. Deja un enlace directo a la página del primer commit. Había muchas instrucciones claras y concretas, y también valen la pena commit de ejemplo 1, commit de ejemplo 2

• Extracto de un commit con issue de Cloudflare workers-oauth-provider. Claude introdujo un bug en un commit anterior y se intentó corregir varias veces mediante prompts, pero siguió fallando. Al final un humano lo arregló directamente y hasta documentó en el README un issue de la especificación OAuth 2.1. Personalmente conecto mucho con este tipo de experiencia al usar IA. A menudo la veo avanzar bien hasta la mitad, pero luego le cuesta cerrar el resto

  • Me llama la atención que la IA puede hacerlo bien hasta cierto punto, pero una vez que comete un error, después todo se descompone. Cuando detectas un error, hay que reescribir el prompt desde cero y empezar otra vez desde el inicio de la conversación. Después de un error, por más que intentes corregirla, el resultado sigue saliendo mal. Por eso hay que meter todo claramente en el mensaje inicial correcto y regenerar desde cero para que no repita el fallo

  • Para mitigar este problema ayuda preparar pruebas o una spec clara y hacer que la IA resuelva con base en eso. Hace unos meses a la IA todavía le costaba mucho resolver este tipo de rompecabezas de especificación, y la calidad del resultado era inferior a la de una respuesta rápida. Pero últimamente el rendimiento de los modelos ha mejorado bastante, así que este tipo de trabajo se ha vuelto bastante interesante, y cuando algo puede especificarse, su utilidad sube. En lo personal, sonnet 3.7 me pareció un gran avance frente a 3.5, y Gemini 2.5 Pro me impresionó aún más. sonnet 4 comete menos errores, pero incluso así, desde la perspectiva de ingeniería de software (organizar requisitos, explorar soluciones técnicas, diseñar arquitectura, redactar user stories y especificaciones, escribir código), sigue siendo necesario guiar bien a la IA para obtener resultados de calidad. Además, si se le agregan buenos ejemplos, el efecto se maximiza. Hace poco, al crear una app con OpenAI Realtime API, al principio fue un fracaso total, pero en cuanto agregué al workspace dos páginas de documentación y un proyecto demo, enseguida salió el resultado que quería (aunque en mi caso tenía que usar la API de otra manera, aun así encajó bien)

  • En las líneas 163~172 del commit encontré afirmaciones claramente incorrectas o que cambian según la implementación del A/S (servidor de autenticación). El servidor de autenticación de Auth0 tiene configuración de “leeway” considerando condiciones de red, pero algunos servidores son mucho más estrictos. Cada implementación difiere en detalles de diseño, así que creo que la probabilidad de que un LLM implemente esto de forma segura basándose solo en el estándar (RFC) y open source público sigue requiriendo un nivel de supervisión humana comparable al de hacerlo uno mismo

  • Me gustaría ver resultados de investigación a largo plazo sobre si las herramientas basadas en LLM realmente ahorran mano de obra, o si solo generan una ilusión de productividad

  • A partir de estas experiencias, veo que las herramientas de IA no están entendiendo de verdad, sino produciendo salidas emergentes y accidentales a partir de una enorme colección de datos de patrones

• El futuro del coding con IA, más que la fantasía tipo LinkedIn/X de que desaparezcan los ingenieros de software y un empresario lo resuelva todo presionando un botón, probablemente irá por el lado de ingenieros experimentados usando IA para producir parte del código y luego revisándolo y probándolo minuciosamente. La pregunta realmente importante es: “¿kentonv habría podido construir esta librería más rápido por su cuenta, sin IA?”

  • Tomó varios días construir la librería junto con IA. Si la hubiera hecho completamente a mano, calcula que le habría tomado semanas, quizá meses. Aun así, este es un caso muy ideal. Fue posible porque había estándares claros, una especificación de API clara y una plataforma ya conocida. Cuando intentó usar IA para modificar el propio Workers Runtime, casi no hubo ahorro de tiempo. Sin embargo, en codebases ajenos con los que no estaba familiarizado, la IA sí le ayuda muchísimo. Ahora es más fácil entrar a explorar código complejo y desconocido, y cosas que antes habría evitado, hoy puede modificarlas por sí mismo con facilidad

  • Sobre si habría sido más rápido construirlo solo sin IA, cree claramente que no. Viendo las herramientas actuales y el know-how de uso que sigue mejorando, piensa que dentro de 3 a 6 meses será más rápido programar nuevas soluciones directamente con IA. Aun así, cree que es importante tener codebases bien documentados, con estructura clara y loops de feedback rápidos (buen lint y unit tests). Vamos camino a eso

  • En mi experiencia, si la IA genera parte del código, hay que revisarlo y probarlo con mucho cuidado, y ese proceso incluso es más <i>lento</i> que escribir yo mismo el código. Por eso, en esta etapa, la IA no me ayuda mucho. Como dice el refrán de que un mal ayudante es peor que no tener ayudante, por ahora la IA sigue siendo un “mal ayudante”

  • Si la estructura termina siendo “ingenieros con experiencia hacen que la IA produzca parte del código y luego lo revisan y testean minuciosamente”, entonces surge la duda de si bastaría con 2 personas en lugar de 20 kentonv. ¿Seguirá habiendo trabajo para las otras 18? El caso del autor es un proyecto técnicamente difícil, pero me pregunto qué pasará con el desarrollo de apps LoB (de negocio) más rutinarias

  • Si los ingenieros con experiencia solo revisan y testean minuciosamente, y todos los puestos junior fueran reemplazados por IA, ¿de dónde saldrán los desarrolladores senior del futuro? Yo sí le veo valor incluso al trabajo repetitivo y simple

• Me parece fascinante ver esta variedad de puntos y opiniones por sí misma. Agradezco que Cloudflare, como líder en seguridad de Internet, muestre un intento de conectar al mundo con esta nueva forma de “vibe coding”. Sentí que estos prompts de IA, el código y demás también pueden aumentar en otros desarrolladores las ganas de explorar la programación. El vibe programming ha sido para mí una herramienta muy significativa que me ayudó a salir de mi depresión y a volver a programar de una manera que me resulta familiar. Espero que este tipo de experiencia también le sirva a otras personas. Espero que las generaciones actuales y futuras utilicen este enfoque. Aun así, creo que también hay que discutir cómo este enfoque podría relacionarse con la salud mental y los problemas psicológicos de las personas. Al final, hay que recordar que estas herramientas son ayudas para los humanos y pensar cómo usarlas para crecer con entusiasmo. Ojalá en el mundo open source aparezcan más casos que muestren no solo capacidad técnica, sino también lógica y un enfoque reflexivo hacia los proyectos. Otro aplauso para Cloudflare

• Se reunieron ejemplos representativos del intercambio de prompts. En este ejemplo de transcripción de prompts incluso se publica el costo real total ($6.45). También se indican materiales como commit relacionado 1, commit 2. Sorprende que haya tan pocos relatos realmente útiles sobre flujos de trabajo con IA (sobre todo de gente experimentada) porque quedan enterrados bajo el hype. Más allá de listas de tareas, da curiosidad ver casos reales de live coding. También podría valer la pena revisar los textos de antirez y tptacek (caso de antirez, post de tptacek)

  • No lo seguí con exactitud, pero calculo que el costo de usar Claude fue de unos $50. Comparado con el tiempo ahorrado, es un costo insignificante

• Yo creo que “vibecoding” al final no va a sobrevivir. Sigue haciendo falta la validación y corrección de bugs por parte de grandes programadores, y hubo bugs que la IA no pudo arreglar. Al final, este tipo de herramienta es un apoyo para que alguien que ya domina bien ese trabajo pueda ir más rápido. Quizá para una homepage muy básica sí, pero herramientas que generan eso automáticamente existen desde hace años

  • Por ahora vibecoding es ideal para trabajos de bajo riesgo. GUI, apps CRUD, experimentos de una sola vez, etc.; es muy útil en el sentido de darle más poder a gente que antes no lo tenía. En este caso, yo no lo llamaría vibecoding, sino coding asistido por LLM

  • En la práctica, siento que el término vibecoding a veces se usa como un espantapájaros para atacar. Si de todos modos uno usa código que el LLM escribió y luego lo corrige un poco, ¿eso no cuenta también como vibe coding?

• Se agradece mucho que el OP haya publicado no solo el código generado por IA, sino también los prompts. Personalmente, cada vez que intento desarrollar con LLM cosas no web (últimamente, por ejemplo, una implementación .NET para hacer ingeniería inversa de SAP ABAP y ajustar datos para Snowflake), termino sufriendo por temas de “alucinaciones”. Como escuchaba que a otras personas sí les iba bien, pensé que el problema eran mis prompts, pero al ver este caso publicado entendí que yo tampoco estaba tan lejos. Concluyo que a mí el LLM no me funciona tan bien porque el problema que intento resolver es algo relativamente raro y nuevo. Si no es un objetivo muy entrenado, como el caso de OAuth publicado en GitHub, el LLM no lo sigue bien

• Este tipo de código repetitivo, ya implementado cientos de veces, es perfecto para la IA. Todo el código tiene unas 1200 líneas, así que es de escala pequeña. De hecho, me sorprende que incluso usando IA haya tomado más de 2 días

• En los últimos meses he estado llevando mi propio proyecto greenfield con Claude en Cursor, y lo que sentí fue, primero, que mi productividad aumentó muchísimo. Segundo, que mentalmente estoy mucho más cansado que antes. Tercero, que las herramientas están empezando a mejorar muy rápido incluso en el corto plazo, y eso amplifica los dos efectos anteriores

  • Mi experiencia y la de otros desarrolladores ha sido exactamente la misma. El coding asistido por LLM sí ayuda mucho a mejorar la productividad real, pero consume mucha más energía. Hasta se siente raro

  • Pregunta sobre eso de “estar más cansado”. Yo lo uso más como una forma de “pair programming” con mi agente (Devstral) que como reemplazo del método anterior, y revisar me parece mucho más fácil que teclear yo mismo cada línea de código. En términos de tiempo, es una gran ventaja. En vibe coding se pierde el contexto del codebase y luego la revisión y la entrada se vuelven mucho más difíciles. En cambio, en pair programming uno va acumulando contexto mientras avanza, así que la revisión se siente mucho más rápida

  • Yo soy justo lo contrario. Como la IA se encarga sola de todos los detalles menores, siento un gran alivio mental. Me deja libre para concentrarme en objetivos de más alto nivel, como la arquitectura

• Se siente bastante gracioso que una empresa como Cloudflare muestre un error de "Too Many Requests"

  • A mí también