▲

Cloudflare가 Claude와 함께 OAuth를 빌드하고 모든 프롬프트를 공개함

 (github.com/cloudflare)
14P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • Cloudflare가 OAuth 2.1 프로바이더 프레임워크를 Cloudflare Workers용 TypeScript 라이브러리로 발표함
  • 대부분의 구현은 Anthropic의 Claude LLM을 이용해 작성되고, Cloudflare 보안 엔지니어가 꼼꼼하게 검토함
  • 이 라이브러리는 API 엔드포인트를 위한 인증 자동화와 토큰 관리 자동 처리를 제공
  • 최신 OAuth 표준과 PKCE, 동적 클라이언트 등록, 접근 범위 설정 등 주요 기능을 지원
  • 중요한 구간마다 엔드 투 엔드 암호화와 싱글-유스 리프레시 토큰 등 보안 설계를 강조

Cloudflare Workers를 위한 OAuth 2.1 프로바이더 프레임워크의 소개 및 중요성

이 오픈소스 프로젝트는 Cloudflare Workers 환경에서 쉽게 OAuth 2.1 인증 서버를 구현할 수 있도록 설계된 TypeScript 라이브러리임.
동종 타 프로젝트와 비교시, Cloudflare 플랫폼에 특화된 확장성과 원활한 통합, 그리고 보안 중심의 설계에서 강점이 큼
알고리듬, 프로토콜 표준 준수(RFC-8414, RFC-7591 등), 라이브러리 구조의 명확성 등에 중점이 맞춰져 있음
특히, 토큰 및 주요 시크릿 값의 해시화 저장, props의 엔드 투 엔드 암호화 등 안전성을 위해 세부적으로 설계됨
참고로, 라이브러리 코어 코드와 문서 대부분이 Claude LLM의 협력으로 작성되어 흥미로운 개발사례를 보여줌

주요 기능 및 장점

  • OAuthProvider로 Worker 코드를 래핑하여 API 엔드포인트에 대한 인증 기능 자동 부여
  • 토큰 관리(생성, 저장, 검증, 폐기 등)가 자동 처리되어 직접 구현이 필요하지 않음
  • 사용자는 fetch 핸들러 안에서 이미 인증된 사용자 정보를 바로 파라미터로 받아 활용 가능함
  • 사용자 관리 및 인증, UI 구현 방식에 대한 제한 없음 (개발자가 원하는 구조와 프레임워크 자유롭게 선택 가능)
  • 라이브러리의 저장소에는 오직 해시 정보만 저장되고, 비밀키 등 시크릿 자체는 저장되지 않음

사용 방법 핵심

  • OAuthProvider 인스턴스를 Worker 엔트리포인트로 내보내서 fetch 핸들러 역할을 수행할 수 있음
  • apiRoute, apiHandler 옵션으로 인증이 필요한 API 엔드포인트 구간과 실제 핸들러를 각각 지정함
  • authorizeEndpoint, tokenEndpoint, clientRegistrationEndpoint 등 각 표준 OAuth 엔드포인트 경로를 정의 가능함
  • 필요한 경우 scope나 public client registration 등 정책 세분화 가능함
  • defaultHandler를 통해 API 외 요청 및 인증 실패 요청도 유연하게 처리 가능함

헬퍼 객체 및 API

  • env.OAUTH_PROVIDER를 fetch 핸들러에서 사용하여, OAuth 관련 요청 파싱, 클라이언트 정보 조회, 승인 완료 등에 활용 가능함
  • API 요청처리에서, access token이 유효한 경우 권한이 부여된 상태의 사용자별 props 정보를 ctx.props로 바로 접근 가능함
  • 클라이언트 등록, 권한(authorization grant) 리스트, 특정 사용자에 대한 grant 열람 및 폐기 등도 공식 API로 제공함

Token Exchange Callback

  • 토큰 발급·갱신 시, props 값을 동적으로 업데이트할 수 있는 콜백(tokenExchangeCallback) 지원
  • OAuth 클라이언트와 연동된 추가 토큰 교환(upstream token exchange) 등 복합 시나리오 지원 가능함
  • 콜백에서 accessTokenProps, newProps, accessTokenTTL 등을 반환하여 맞춤형 동작 구현 가능함
  • accessTokenTTL 커스터마이징을 통해, 상위 OAuth 시스템과 토큰 만료 타이밍을 맞출 수 있음
  • props에는 민감 정보가 담길 수 있어 이 값 전체가 엔드 투 엔드로 암호화되어 저장됨

커스텀 에러 응답

  • onError 옵션을 사용해 에러 발생 시 Notfication 전송, 커스텀 로깅 등 대외 조치 가능함
  • 반환 Response를 직접 정의하면, OAuthProvider가 유저에게 제공하는 에러 응답을 원하는 형태로 오버라이드 가능함

보안 관련 상세 설계

엔드 투 엔드 암호화

  • 토큰 관련 데이터 및 시크릿은 해시로만 저장되고, grant props 정보는 토큰 자체로 암호화 저장하여 유출 사고 대응력을 높임
  • userId, metadata 등은 감사(audit) 및 폐기 용도 기록을 위해 암호화하지 않으며, 필요시 개발자가 추가 암호화 적용 가능함

싱글-유스 리프레시 토큰 설계

  • OAuth 2.1 요구대로 "클라이언트 바인딩 or 싱글 유스" 조건 중, 이 라이브러리는 최대 2개 병렬 리프레시 토큰 허용이라는 절충 설계 사용
  • 이를 통해 네트워크 장애 등으로 새 토큰 저장이 실패해도 이전 토큰을 한 번 더 사용할 수 있는 안전장치 제공함

Claude 기반 개발 과정

  • 본 라이브러리와 문서 다수는 Anthropic Claude LLM을 활용해 초안이 만들어졌으며, Cloudflare 엔지니어가 RFC 및 보안 기준에 맞춰 꼼꼼하게 리뷰함
  • 초기에는 AI 코드 생성에 회의적이었으나, 실제 품질과 생산성 향상 경험을 통해 시각이 변화하였음
  • 개발 흐름과 Claude의 프롬프트, 코드 개선 과정을 깃 커밋 히스토리에서 모두 투명하게 공개함

기타 사항

  • Workers KV 네임스페이스(OAUTH_KV) 바인딩 필수 적용, storage-schema.md 참고
  • 전체 API 및 헬퍼는 OAuthHelpers 인터페이스 정의 참고
  • 라이브러리는 현재 베타/프리릴리스 단계이며, 향후 API 변경 가능함
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • Readme에서 발췌 내용 소개. 이 라이브러리(그리고 스키마 문서)는 대부분 Anthropic의 AI 모델 Claude의 도움을 받아 작성함. Cloudflare 엔지니어들이 철저하게 검토하고 보안 및 표준 준수에 신경 씀. 초기 산출물에서도 많은 개선이 이루어졌고, 주로 Claude에게 추가 프롬프트를 주고 결과를 반복적으로 검토하면서 진행함. 커밋 히스토리에서 Claude를 어떻게 프롬프트했고, 어떤 코드가 나왔는지 실제로 직접 확인 가능함. 처음에는 “LLM이 인증 라이브러리를 작성하게 두면 안 된다”는 전통적인 회의적 입장이었음. 2025년 1월만 해도 나 역시 AI에 매우 회의적이었고, LLM은 그저 ‘화려한 Markov 체인 생성기’ 정도에 불과하며, 참신함이나 실제 코드를 만들어내지 못한다고 생각함. 프로젝트를 재미 삼아 시작했지만, 생각보다 괜찮은 코드가 나와서 충격을 받음. 완벽하지는 않았지만 AI에게 수정 요청만 하면 제대로 고쳐줬음. 한 줄 한 줄 다 각종 RFC와 비교해보며, 보안 전문가들과 함께 검토함. 내 회의론을 검증하려고 했으나, 오히려 스스로 틀렸음을 증명한 결과임. 커밋 이력, 특히 초기 커밋을 꼭 참고해 보면 이 과정을 확인할 수 있음

    • 숙련된 엔지니어가 적절하게 프롬프트를 했을 때 LLM이 이런 코드 정도는 충분히 만들어낼 수 있으리라 기대함. OAuth는 새로운 기술이 아니고 이미 수많은 오픈소스 예제와 다양한 언어의 구현 케이스가 데이터로 쓰였을 것임. 하지만 LLM이 전혀 새로운 연구, 소재 과학, 경제, 발명 등에 혁신적으로 기여할 거라는 주장에는 여전히 회의적임. ‘실시간으로 배우는 능력’이 정말 필요한 영역인데, 현존 LLM은 이미 아는 오래된 정보를 바탕으로만 능력을 보여왔음. 유의미한 성과는 대개 아주 제한된 환경 내 cherry-pick 사례에 불과함. 숙련된 엔지니어가 있다면 과거 데이터를 바탕으로 새로운 코드 생성이 당연히 가능하다고 생각하지만, LLM 도입이 가져오는 환경적, 사회적 부담이 실제 효율성에 비해 과도하다고 여전히 의문임

    • “나는 2025년 1월까지 (@kentonv)와 같은 생각을 가지고 있었다”라는 표현에 혼란을 느낌. kentonv가 다른 사용자이기 때문임. 이게 본인 부계정인가, 아니면 오타나 오해인지 궁금함. 편집: 대부분의 글이 README 인용인 걸 확인함. >와 * 기호를 사용해서 인용을 명확히 했으면 혼란이 덜했으리라 생각함. kentonv 프로필 링크 첨부

    • "LLM을 화려한 Markov 체인 생성기라 생각했다"와 "AI가 꽤 괜찮은 코드를 만들어내 놀랐다" 이 두 의견은 서로 모순이 아님. LLM이 굉장히 유용하다고 느끼지만, 여전히 본질은 패턴 생성기에 가까움. 중요한 점은 그 정도가 이미 충분하고, 인간 역시 크게 다르지 않은 구조일 수도 있다는 사실임

    • 요즘은 pro-AI 보다는 더 회의적인 입장이지만, 어쨌든 워크플로우에서 AI 도입하려 계속 시도 중임. 실제로는 설명이 더 어려워서 그냥 직접 하는 게 더 쉽다고 느낌. 큰 재미도 없지만, 이게 “미래”의 도구이니 익히는 게 현명하다고 생각함. 아직은 진짜 AI 툴링은 초창기 수준이라 봄. 앞으로 신기한 UX 사례 등장에 계속 관심이 생김

    • 초기에 Claude가 어떻게 프롬프트 받았고, 실제 코드를 어떻게 생성했는지 커밋 히스토리 직접 참고 안내. 최초 커밋 페이지로 바로가기 링크 제공. 명확하고 구체적인 지시가 많았고, 예시 커밋1, 예시 커밋2 등도 볼만함

  • Cloudflare workers-oauth-provider 커밋 중 이슈 커밋 발췌. Claude가 이전 커밋에서 버그를 내서 여러 번 프롬프트로 수정하려 했으나 계속 실패함. 결국 인간이 직접 수정하고, README에 OAuth 2.1 스펙 이슈까지 문서화함. 이런 경험이 나 개인적으로도 AI 활용에서 매우 공감됨. 절반까지 잘 가다가 나머지는 힘들어하는 모습을 종종 봄

    • AI가 중간까지는 잘 해내지만, 한 번 실수하면 이후 전부 망가진다는 점에 주목함. 실수 발견 시 즉시 대화 처음부터 프롬프트를 재작성해서 시작해야 함. 한 번 실수한 이후엔 아무리 바로잡으려 해도 결과가 계속 잘못됨. 그래서 올바른 시작 메시지에 모든 걸 명확하게 담아 다시 처음부터 만들어야 실수를 반복하지 않음

    • 이런 문제를 완화하려면 테스트나 명확한 명세(spec)를 마련해 AI에게 해결하도록 하면 도움됨. 몇 달 전만 해도 AI가 이런 명세 퍼즐을 푸는 데 시간이 많이 걸렸고, 결과물도 빠른 답변보다 품질이 낮았음. 하지만 최근엔 모델 성능이 많이 좋아져서 이러한 작업이 꽤 재미있고, 스펙화 할 수 있는 경우 활용도가 올라감. 나 개인적으로는 sonnet 3.7이 3.5보다 큰 발전을 보였고, Gemini 2.5 Pro가 더 인상 깊었음. sonnet 4는 실수가 더 적지만, 여전히 소프트웨어 엔지니어링 관점(요구사항 정리, 기술 솔루션 탐색, 아키텍처 설계, 유저 스토리 및 명세 작성, 코드 작성)에서 AI를 제대로 유도해 줘야 양질의 결과물을 얻을 수 있음. 추가로, 좋은 예제를 AI에 추가해 넣으면 효과가 극대화됨. 최근 OpenAI Realtime API로 앱을 만들 때도 초반엔 완전 실패했지만, 문서 두 페이지와 데모 프로젝트 하나를 워크스페이스에 추가하고 나니 바로 원하는 결과가 나옴(내 경우엔 API를 다르게 써야 했음에도 잘 맞음)

    • 커밋 163~172줄 언급 내용 중 명백히 사실과 다르거나 A/S(인증 서버) 구현별로 해석이 다른 주장들 발견. Auth0의 인증 서버는 네트워크 조건을 감안한 “leeway” 설정이 있지만, 일부 인증 서버는 훨씬 엄격함. 각 구현체마다 세부 설계가 달라서, 표준(RFC)와 공개된 오픈소스만으로 LLM이 안전하게 구현할 확률은, 결국 직접 만드는 것과 맞먹는 수준의 인간의 감수가 필요하다고 생각함

    • LLM 기반 도구가 실제로 투입 인력을 절약해줄 수 있는지, 아니면 생산 착시만 주는지에 대한 장기적 연구 결과가 궁금함

    • 이런 경험에서 AI 도구들이 실제로 이해하고 있는 것이 아니라, 거대한 패턴 데이터 모음을 바탕으로 우연적(emergent) 출력을 만들어내는 것이라 봄

  • AI 코딩의 미래는 소프트웨어 엔지니어가 사라지고, 비즈니스맨이 버튼 누르면 모든 게 끝나는 LinkedIn/ X류 판타지와 달리, 숙련 엔지니어들이 AI로 코드 일부를 만들고 이를 꼼꼼히 검토, 테스트하는 방향일 것임. 진짜 중요한 질문은, “kentonv가 AI 없이 혼자 이 라이브러리를 더 빠르게 만들 수 있었을까?”라는 점임

    • AI와 함께 라이브러리를 만드는 데 며칠 걸림. 직접 손수 만들면 몇 주, 어쩌면 몇 달 걸렸을 거라 추정함. 다만, 여기서는 매우 이상적인 사례임. 명확한 표준, 명확한 API 스펙 기반에, 이미 잘 알려진 플랫폼이라는 조건이 있어 가능했던 것임. AI로 Workers Runtime 자체를 바꾸려 했을 땐 시간 절감 효과가 별로였음. 그러나 내가 익숙하지 않은 다른 사람 코드베이스엔 AI가 정말 큰 도움이 됨. 이제는 낯선 복잡한 코드 탐험실에도 진입이 편리해졌고, 과거엔 그런 걸 피했다면 지금은 스스로 필요한 변경을 쉽게 할 수 있음

    • AI 없이 혼자 직접 만들었으면 더 빨랐을까란 질문엔 확실히 아니라고 생각함. 지금 우리가 가진 도구와, 계속 나아지고 있는 활용 노하우로 볼 때, 앞으로 3-6개월 내에는 AI로 직접 새 솔루션을 코딩하는 게 더 빨라질 전망임. 다만 잘 문서화되고, 구조가 명확하며, 빠른 피드백 루프(좋은 린트/유닛 테스트)가 갖춰진 코드베이스 장비가 중요하다고 생각함. 우리는 그쪽으로 가는 중임

    • 경험상 AI가 일부 코드를 만들어주면 꼼꼼히 리뷰, 테스트해야 하는데 이 과정이 오히려 내가 직접 코딩하는 것보다 <i>느림</i>. 그래서 지금 단계에선 AI가 큰 도움이 안 됨. 잘못된 도우미가 없느니만 못하다는 속담처럼, 아직 AI는 “나쁜 도우미”인 셈임

    • “경험 많은 엔지니어가 AI로 코드 일부를 만들고 꼼꼼히 테스팅하는 구조”라면, 결국 20명의 kentonv 대신 2명만 있으면 충분한 것 아닌가란 고민 생김. 나머지 일할 사람 18명을 위한 일거리가 계속 생길까? 저자 사례는 기술적으로 어려운 프로젝트지만, 밋밋한 LoB(업무용) 앱 개발에는 어떤 변화가 있을지 궁금함

    • 경험 많은 엔지니어가 꼼꼼히 리뷰 및 테스트만 한다면, 주니어 개발자 자리를 전부 AI로 대체했을 경우 경력 개발자가 어디서 생길지 물음. 단순 반복 작업에도 그만한 가치를 두는 입장임

  • 이런 다양한 논점과 의견들을 보는 것이 그 자체로 신기함. Cloudflare가 인터넷 보안 분야 리더답게 새로운 ‘vibe 코딩’ 방식으로 세상을 연결하는 시도를 보여줌에 감사함. 이러한 AI 프롬프트, 코드 등이 다른 개발자들에게도 프로그래밍 탐구 의지를 높여줌을 느꼈음. vibe programming이 내 우울감을 돌파하고, 내가 익숙한 방식으로 코딩하게 해준 매우 의미 있는 수단임. 이런 경험이 다른 사람에게도 도움이 되기를 바람. 현재와 미래 세대 모두 이런 방식을 활용할 것으로 기대함. 다만, 이 방식이 사람의 정신 건강이나 심리 문제와도 연결될 수 있다는 점을 논의해야 한다고 생각함. 결국 이러한 도구는 인간의 조력수단임을 유념하면서, 우리가 열정을 갖고 성장할 수 있도록 어떻게 활용할지 고민함. 오픈소스 분야에서 기술 역량뿐 아니라, 논리와 사려 깊은 프로젝트 접근법을 보여줄 사례들이 많이 나오길 기대함. Cloudflare에 다시 한 번 칭찬을 보냄

  • 대표적인 프롬프트 주고받기 예시를 모아둠. 프롬프트 트랜스크립트 예시에서는 실제 비용(총 $6.45)까지 공개함. 관련 커밋1, 커밋2 등 자료도 안내함. AI 워크플로우에 대한 제대로 된 경험기(특히 숙련자들)의 정보가 하이프에 묻혀 별로 없다는 게 놀라움. todo list 외에 실제 라이브 코딩 사례 정보가 궁금한 상황임. antirez, tptacek의 글(antirez 사례, tptacek 글)도 참고하면 좋을 듯함

    • 정확히는 추적하지 않았지만 Claude 사용 비용은 대략 $50 정도라 추정함. 절약된 시간에 비하면 의미 없는 비용 수준임

  • 나는 “vibecoding”이 결국 생존하지 못할 거라 봄. 여전히 뛰어난 프로그래머의 검증, 버그 수정이 필요하며, AI가 못 고치는 버그도 있었음. 결국 이런 도구는 자신이 이미 해당 작업을 잘 알고 있는 사람이 속도를 높일 수 있는 보조도구임. 정말 기초적인 홈페이지 정도는 몰라도, 그런 걸 자동 생성해 주는 툴은 수년 전부터 존재함

    • vibecoding은 지금은 stakes가 낮은 작업에 최적임. GUI, CRUD 앱, 일회성 실험 등 파워 없는 이들에게 새로운 힘을 주는 부분에서 쓸모가 높음. 이번 건은 vibecoding이 아니라 LLM-assisted coding이라 생각함

    • 실제로는 vibecoding이라는 말을 공격용 허수아비처럼 사용하는 경향이 느껴짐. 대부분 LLM에게 맡긴 코드를 약간만 고쳐서 쓰는 것 역시 vibe coding이라 보면 되는 거 아닌지?

  • OP가 AI로 생성된 코드 뿐 아니라 프롬프트까지 공개해준 점이 크게 고마움. 개인적으로 LLM으로 비웹 코드(특히 요즘엔 SAP ABAP 역공학해서 데이터를 Snowflake에 맞추는 .NET 구현)를 개발하려다 매번 ‘환각’ 이슈에 고생함. 다른 사람들은 성공 사례가 많다 하길래 내 프롬프트만 문제라 생각했는데, 이번 공개된 사례를 보니 나도 그리 멀지 않다는 걸 알게 됨. LLM이 내게 잘 안 맞는 이유는 만든 문제가 조금 희귀하고 새롭기 때문이라 판단함. GitHub에 공개된 OAuth 케이스처럼 많이 학습된 대상이 아니면 LLM이 잘 못 따라옴

  • 이런 종류의 반복적이고 이미 수백 번 구현된 코드는 AI에 완벽히 적합함. 전체 코드 1200줄 정도라 작은 규모임. AI 쓰고도 2일 이상 걸렸다는 게 오히려 의외임

  • 최근 몇 달간 Cursor로 Claude를 이용해 나만의 greenfield 프로젝트를 진행하며 느낀 점은 첫째, 엄청나게 생산성이 높아졌음. 둘째, 이전보다 정신적으로 훨씬 더 피로함. 셋째, 단기간 내에도 도구들이 상당히 빨리 발전하기 시작하며, 위 두 가지 효과도 증폭되고 있음

    • 내 경험 및 다른 개발자들과도 똑같음. LLM assisted coding은 실제로 생산성 향상에 큰 도움이 되지만, 에너지 소모가 그만큼 더 큼. 오히려 이상하게 느껴질 정도임

    • “이렇게 더 피곤하다”는 점에 질문함. 난 기존 방식보다 내 에이전트(Devstral)와 “페어 프로그래밍” 형태로 활용하고 있고, 코드 전체를 일일이 타이핑하는 것보다 리뷰가 훨씬 쉬움. time wise 관점에서 큰 장점임. vibe coding에선 코드베이스 맥락이 사라져 나중에 리뷰와 진입 장벽이 훨씬 커짐. 반면 페어 프로그래밍에선 맥락을 쌓으면서 진행되니 리뷰가 훨씬 빠르다고 느낌

    • 나는 오히려 정반대임. AI가 사소한 디테일을 전부 알아서 챙겨주니까 오히려 큰 안도감 생김. 아키텍처 등 상위 목표에 집중할 수 있게 자유로워짐

  • Cloudflare 같은 회사에서 "Too Many Requests" 에러가 나는 게 꽤 유쾌하게 느껴짐

    • 나도 마찬가지임
답변달기