Cloudflare ने Claude के साथ OAuth बनाया और सभी prompts सार्वजनिक किए

 (github.com/cloudflare)
16 पॉइंट द्वारा GN⁺ 2025-06-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare ने Cloudflare Workers के लिए TypeScript लाइब्रेरी के रूप में OAuth 2.1 provider framework की घोषणा की
  • अधिकांश implementation Anthropic के Claude LLM की मदद से लिखा गया, और Cloudflare के security engineers ने इसे बारीकी से review किया
  • यह लाइब्रेरी API endpoints के लिए authentication automation और token management का automatic handling प्रदान करती है
  • यह नवीनतम OAuth standards और PKCE, dynamic client registration, access scope configuration जैसी प्रमुख सुविधाओं को support करती है
  • महत्वपूर्ण हिस्सों में end-to-end encryption और single-use refresh tokens जैसी security design पर जोर दिया गया है

Cloudflare Workers के लिए OAuth 2.1 provider framework का परिचय और महत्व

यह open source project एक TypeScript लाइब्रेरी है, जिसे Cloudflare Workers environment में आसानी से OAuth 2.1 authorization server implement करने के लिए design किया गया है।
इसी तरह के अन्य projects की तुलना में, इसकी ताकत Cloudflare platform के लिए खास तौर पर optimized scalability और seamless integration, तथा security-first design में है।
इसमें algorithms, protocol standards compliance (RFC-8414, RFC-7591 आदि), और library structure की स्पष्टता पर विशेष ध्यान दिया गया है।
खास तौर पर, tokens और प्रमुख secret values की hashed storage, तथा props की end-to-end encryption जैसी बारीक security design अपनाई गई है।
दिलचस्प बात यह है कि लाइब्रेरी का अधिकांश core code और documentation Claude LLM के सहयोग से लिखा गया, जो एक रोचक development case study दिखाता है।

प्रमुख features और फायदे

  • Worker code को OAuthProvider से wrap करके API endpoints पर authentication capability अपने-आप जोड़ना
  • Token management (generation, storage, validation, revocation आदि) अपने-आप handle होता है, इसलिए इसे manually implement करने की जरूरत नहीं
  • User, fetch handler के भीतर पहले से authenticated user information को सीधे parameter के रूप में प्राप्त कर सकता है
  • User management, authentication, और UI implementation पर कोई पाबंदी नहीं (developer अपनी पसंद की structure और framework चुन सकता है)
  • लाइब्रेरी के storage में सिर्फ hash information store होती है, secret key जैसी असली secret values store नहीं की जातीं

उपयोग का मुख्य तरीका

  • OAuthProvider instance को Worker entrypoint के रूप में export करके fetch handler की तरह इस्तेमाल किया जा सकता है
  • apiRoute, apiHandler options से authentication-required API endpoint section और actual handler को अलग-अलग define किया जाता है
  • authorizeEndpoint, tokenEndpoint, clientRegistrationEndpoint आदि standard OAuth endpoint paths define किए जा सकते हैं
  • जरूरत पड़ने पर scope या public client registration जैसी policies को बारीकी से customize किया जा सकता है
  • defaultHandler के जरिए API के बाहर की requests और authentication failure requests को भी लचीले तरीके से handle किया जा सकता है

Helper objects और API

  • Fetch handler में env.OAUTH_PROVIDER का उपयोग करके OAuth-related request parsing, client information lookup, authorization completion आदि किए जा सकते हैं
  • API request processing में, access token valid होने पर authorized state वाले user-specific props को ctx.props से सीधे access किया जा सकता है
  • Client registration, authorization grant list, और किसी खास user के grants को देखना या revoke करना भी official API से उपलब्ध है

Token Exchange Callback

  • Token issue या refresh करते समय, props values को dynamically update करने वाला callback (tokenExchangeCallback) support किया गया है
  • OAuth client से जुड़े अतिरिक्त token exchange (upstream token exchange) जैसे complex scenarios भी support किए जा सकते हैं
  • Callback में accessTokenProps, newProps, accessTokenTTL आदि return करके customized behavior implement किया जा सकता है
  • accessTokenTTL customization के जरिए upstream OAuth system के token expiry timing के साथ sync किया जा सकता है
  • Props में sensitive information हो सकती है, इसलिए इस पूरी value को end-to-end encrypted रूप में store किया जाता है

Custom error response

  • onError option का उपयोग करके error होने पर notification भेजना, custom logging जैसी बाहरी कार्रवाई की जा सकती है
  • यदि return Response को सीधे define किया जाए, तो OAuthProvider द्वारा user को दिए जाने वाले error response को मनचाहे रूप में override किया जा सकता है

Security से जुड़ी विस्तृत design

End-to-end encryption

  • Token-related data और secrets केवल hash के रूप में store होते हैं, और grant props information को token itself से encrypt करके store किया जाता है, जिससे data leak की स्थिति में resilience बढ़ती है
  • userId, metadata आदि को audit और revocation records के लिए encrypt नहीं किया जाता; जरूरत पड़ने पर developer अतिरिक्त encryption लागू कर सकता है

Single-use refresh token design

  • OAuth 2.1 की requirement "client binding या single use" में से, यह लाइब्रेरी अधिकतम 2 parallel refresh tokens की अनुमति देने वाला एक balanced design अपनाती है
  • इससे network failure जैसी स्थिति में, नया token save न हो पाने पर भी पुराने token को एक बार और इस्तेमाल करने की safety मिलती है

Claude-आधारित development process

  • इस लाइब्रेरी और इसके बड़े हिस्से के documentation का प्रारूप Anthropic Claude LLM की मदद से तैयार किया गया, और Cloudflare engineers ने RFCs तथा security standards के अनुसार इसका विस्तार से review किया
  • शुरुआत में AI code generation को लेकर संदेह था, लेकिन वास्तविक quality और productivity gains के अनुभव से यह नजरिया बदला
  • Development flow, Claude prompts, और code improvement process को git commit history में पूरी transparency के साथ सार्वजनिक किया गया है

अन्य बातें

  • Workers KV namespace (OAUTH_KV) binding अनिवार्य है; storage-schema.md देखें
  • पूरी API और helpers के लिए OAuthHelpers interface definition देखें
  • लाइब्रेरी फिलहाल beta/prerelease stage में है, इसलिए भविष्य में API बदल सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-03
Hacker News राय

  • README से उद्धृत अंश का परिचय। यह लाइब्रेरी (और schema दस्तावेज़) ज़्यादातर Anthropic के AI मॉडल Claude की मदद से लिखी गई। Cloudflare इंजीनियरों ने इसे बहुत ध्यान से review किया और security व standards compliance पर फ़ोकस रखा। शुरुआती output में भी काफ़ी सुधार किए गए, और यह काम मुख्यतः Claude को अतिरिक्त prompts देकर तथा परिणामों की बार-बार समीक्षा करके आगे बढ़ाया गया। commit history में सीधे देखा जा सकता है कि Claude को कैसे prompt किया गया और किस तरह का code निकला। शुरुआत में पारंपरिक संशय यही था कि “LLM को authentication library नहीं लिखने देनी चाहिए।” जनवरी 2025 तक मैं भी AI को लेकर बहुत संशय में था, और मुझे लगता था कि LLM बस एक ‘चमकदार Markov chain generator’ है, जो न तो कोई नई बात ला सकता है और न ही असली code बना सकता है। यह project मज़े के लिए शुरू किया था, लेकिन उम्मीद से बेहतर code देखकर झटका लगा। यह perfect नहीं था, लेकिन AI से fixes माँगने पर वह सही तरह से सुधार देता था। हर लाइन को अलग-अलग RFCs से मिलाकर देखा गया और security experts के साथ review किया गया। मैं अपने संशय को परखना चाहता था, लेकिन नतीजा उल्टा निकला—यह साबित हुआ कि मैं खुद ग़लत था। इस प्रक्रिया को देखने के लिए commit history, ख़ासकर शुरुआती commits, ज़रूर देखें

    • अगर कोई skilled engineer सही तरह से prompt करे, तो उम्मीद की जा सकती है कि LLM इस स्तर का code बना ले। OAuth कोई नई technology नहीं है, और संभव है कि countless open source examples व अलग-अलग भाषाओं की implementations इसके training data का हिस्सा रही हों। लेकिन यह दावा कि LLM पूरी तरह नए research, materials science, economics या invention में क्रांतिकारी योगदान देगा, उस पर अभी भी संशय है। ये ऐसे क्षेत्र हैं जहाँ ‘real-time learning ability’ सच में ज़रूरी है, जबकि मौजूदा LLM अब तक वही क्षमता दिखाते आए हैं जो पुराने ज्ञात डेटा पर आधारित है। अर्थपूर्ण उपलब्धियाँ अक्सर बहुत सीमित environments में cherry-pick किए गए cases जैसी लगती हैं। skilled engineer की मौजूदगी में पुराने डेटा के आधार पर नया code generate होना स्वाभाविक है, लेकिन LLM अपनाने से आने वाला environmental और social burden उसकी वास्तविक efficiency gains की तुलना में ज़्यादा तो नहीं, इस पर अब भी सवाल है

    • “मैं जनवरी 2025 तक (@kentonv) जैसा ही सोचता था” इस वाक्य से भ्रम हुआ, क्योंकि kentonv कोई दूसरा user है। सोचा यह उनका alt account है, या फिर typo / misunderstanding। संपादन: बाद में पता चला कि ज़्यादातर पोस्ट README से quotation थी। अगर > और * symbols का इस्तेमाल करके quote को साफ़ दिखाया जाता, तो शायद कम भ्रम होता। kentonv profile लिंक भी जोड़ा गया

    • "मैं LLM को चमकदार Markov chain generator मानता था" और "AI काफ़ी अच्छा code बना सकती है, यह देखकर हैरानी हुई" — ये दोनों बातें एक-दूसरे के विरोध में नहीं हैं। LLM बहुत उपयोगी लग सकता है, लेकिन उसकी मूल प्रकृति अब भी pattern generator जैसी है। अहम बात यह है कि शायद यह स्तर ही काफ़ी है, और इंसान भी शायद संरचनात्मक रूप से इससे बहुत अलग न हों

    • इन दिनों मैं pro-AI से ज़्यादा skeptical हूँ, लेकिन फिर भी workflow में AI लाने की कोशिश जारी है। असल में समझाना ज़्यादा मुश्किल लगता है, इसलिए कई बार सीधे खुद कर लेना आसान पड़ता है। इसमें बहुत मज़ा भी नहीं आता, लेकिन चूँकि यह “future” का tool है, इसलिए इसे सीखना समझदारी लगती है। अभी की स्थिति में असली AI tooling शुरुआती दौर में ही है। आगे आने वाले दिलचस्प UX examples पर नज़र बनी हुई है

    • शुरुआती दौर में Claude को कैसे prompt किया गया और उसने असल code कैसे generate किया, यह देखने के लिए commit history देखने की सलाह। पहला commit पेज का direct link दिया गया। इसमें काफ़ी स्पष्ट और specific instructions थीं, और example commit1, example commit2 भी देखने लायक बताए गए

  • Cloudflare workers-oauth-provider के commits में से issue commit का उद्धरण। Claude ने पिछले commit में bug पैदा किया, और कई prompts से उसे ठीक करवाने की कोशिश की गई, लेकिन वह बार-बार fail हुआ। अंत में इंसान ने खुद fix किया और README में OAuth 2.1 spec issue तक document किया। AI उपयोग के अपने अनुभव में भी यह बात बहुत relatable लगी। अक्सर यह आधे रास्ते तक ठीक चलता है, फिर बाक़ी हिस्से में संघर्ष करता है

    • इस बात पर ध्यान गया कि AI बीच तक तो अच्छा काम करता है, लेकिन एक बार गलती हो जाए तो उसके बाद सब बिगड़ सकता है। गलती मिलते ही conversation की शुरुआत से prompt फिर से लिखकर नए सिरे से शुरू करना पड़ता है। एक बार गलती के बाद चाहे कितना भी सुधारने की कोशिश करें, output ग़लत ही आता रहता है। इसलिए सही शुरुआती message में सब कुछ साफ़-साफ़ भरकर शुरुआत से फिर बनवाना ज़रूरी होता है, तभी वही गलती दोहराई नहीं जाती

    • ऐसी समस्या को कम करने के लिए tests या साफ़ spec तैयार करके AI को solve करने देना मददगार हो सकता है। कुछ महीने पहले तक AI को इस तरह की specification puzzle हल करने में बहुत समय लगता था, और output भी तेज़ जवाबों की तुलना में कम quality का होता था। लेकिन हाल में models की performance काफ़ी सुधरी है, इसलिए अब ऐसे काम काफ़ी रोचक लगते हैं, और जहाँ spec बनाना संभव हो वहाँ इनका उपयोग बढ़ जाता है। निजी अनुभव में sonnet 3.7, 3.5 की तुलना में बड़ा jump लगा, और Gemini 2.5 Pro उससे भी ज़्यादा प्रभावशाली लगा। sonnet 4 में mistakes कम हैं, लेकिन फिर भी software engineering के नज़रिए से—requirements साफ़ करना, technical solution explore करना, architecture design, user stories और specs लिखना, code लिखना—AI को सही दिशा देनी ही पड़ती है, तभी अच्छी quality का output मिलता है। इसके अलावा अच्छे examples AI में जोड़ दिए जाएँ तो असर और बढ़ जाता है। हाल ही में OpenAI Realtime API से app बनाते समय शुरुआत पूरी तरह fail रही, लेकिन documentation के दो pages और एक demo project workspace में जोड़ने के बाद तुरंत मनचाहा result मिलने लगा (मेरे case में API को अलग तरह से इस्तेमाल करना था, फिर भी यह अच्छे से fit हुआ)

    • commit की lines 163~172 में कुछ दावे साफ़ तौर पर तथ्यात्मक रूप से ग़लत या फिर अलग-अलग A/S (authentication server) implementations के हिसाब से अलग तरह से interpret होने वाले लगे। Auth0 के authentication server में network conditions को ध्यान में रखकर “leeway” setting है, लेकिन कुछ authentication servers इससे कहीं ज़्यादा strict होते हैं। हर implementation की detailed design अलग होती है, इसलिए standards (RFCs) और public open source के आधार पर ही LLM के सुरक्षित implementation देने की संभावना अंततः उतनी ही human scrutiny माँगती है, जितनी खुद से बनाने में लगती है

    • यह जानने की जिज्ञासा है कि LLM-based tools सच में manpower बचाते हैं या सिर्फ productivity का illusion देते हैं; इस पर long-term research results देखना रोचक होगा

    • ऐसे अनुभवों से लगता है कि AI tools वास्तव में चीज़ों को “समझ” नहीं रहे, बल्कि विशाल pattern data collection के आधार पर emergent output दे रहे हैं

  • AI coding का भविष्य शायद उस LinkedIn / X तरह की fantasy जैसा नहीं होगा जिसमें software engineer ग़ायब हो जाएँ और कोई businessman बस button दबाकर सब कर ले। ज़्यादा संभव दिशा यह है कि skilled engineers AI से code का कुछ हिस्सा बनवाएँ और फिर उसे बहुत ध्यान से review व test करें। असली सवाल यह है: “क्या kentonv यह library AI के बिना अकेले ज़्यादा तेज़ बना सकते थे?”

    • AI के साथ यह library बनाने में कुछ दिन लगे। अगर सब कुछ खुद हाथ से बनाया जाता, तो शायद कुछ हफ़्ते, संभव है कुछ महीने लगते। लेकिन यह बहुत ideal case भी है। यहाँ clear standards, साफ़ API spec, और पहले से known platform जैसी conditions थीं, इसलिए यह संभव हुआ। AI से Workers Runtime को खुद बदलने की कोशिश में समय की बचत ख़ास नहीं मिली। लेकिन जिस codebase से मैं परिचित नहीं होता, वहाँ AI सच में बहुत मदद करता है। अब unfamiliar complex code के “exploration room” में घुसना आसान हो गया है; पहले जिन चीज़ों से बचता था, अब उनमें ज़रूरी changes खुद आसानी से कर सकता हूँ

    • अगर सवाल यह है कि AI के बिना अकेले बनाना तेज़ होता क्या, तो जवाब निश्चित रूप से नहीं है। अभी हमारे पास जो tools हैं, और जो उपयोग करने की समझ लगातार बेहतर हो रही है, उसे देखते हुए अगले 3-6 महीनों में AI के साथ सीधे नए solutions code करना और तेज़ हो जाएगा। लेकिन अच्छी documentation, clear structure, और fast feedback loop (अच्छा lint / unit tests) वाला codebase environment बहुत महत्वपूर्ण है। हम उसी दिशा में बढ़ रहे हैं

    • मेरे अनुभव में AI कुछ code बना दे तो उसे बहुत ध्यान से review और test करना पड़ता है, और यह process उल्टा खुद code लिखने से भी <i>धीमा</i> पड़ता है। इसलिए अभी के चरण में AI बहुत काम का नहीं लगता। जैसे कहावत है कि ग़लत helper, helper न होने से भी बुरा होता है—AI अभी “bad helper” जैसा है

    • अगर “अनुभवी engineer AI से code का कुछ हिस्सा बनवाए और उसे carefully test करे” यही model है, तो क्या अंततः 20 kentonv की जगह 2 लोग ही काफ़ी नहीं होंगे? बाक़ी 18 लोगों के लिए क्या काम बना रहेगा? लेखक का case तकनीकी रूप से कठिन project है, लेकिन साधारण LoB (business) app development में इसका असर कैसा होगा, यह जानना है

    • अगर experienced engineers सिर्फ review और testing करें, और junior developer roles पूरी तरह AI से replace हो जाएँ, तो future senior engineers आएँगे कहाँ से? साधारण और दोहराए जाने वाले कामों की भी उतनी ही value है, ऐसा मानने वाला दृष्टिकोण सामने आया

  • इन तमाम अलग-अलग points और opinions को देखना अपने-आप में रोचक है। Cloudflare, जो internet security की दुनिया में leader है, उसने एक नए तरह की ‘vibe coding’ approach के साथ दुनिया को जोड़ने की कोशिश दिखाई, इसके लिए आभार। लगा कि ऐसे AI prompts और code दूसरे developers में भी programming को explore करने की इच्छा जगा सकते हैं। vibe programming मेरे लिए depression से बाहर निकलने और अपने परिचित अंदाज़ में coding करने का एक बहुत meaningful माध्यम रहा है। उम्मीद है यह अनुभव दूसरों की भी मदद करे। लगता है वर्तमान और आने वाली पीढ़ियाँ दोनों इस तरीके का उपयोग करेंगी। लेकिन यह भी चर्चा होनी चाहिए कि इस approach का इंसानों की mental health या psychological issues से क्या संबंध हो सकता है। आख़िरकार ये tools इंसानों की मदद के साधन हैं; ज़रूरी यह है कि हम इन्हें किस तरह इस्तेमाल करें ताकि जुनून के साथ आगे बढ़ सकें। open source दुनिया में सिर्फ technical capability ही नहीं, बल्कि logic और thoughtful project approach दिखाने वाले और उदाहरण सामने आएँ, ऐसी उम्मीद है। Cloudflare की एक बार फिर प्रशंसा की गई

  • प्रमुख prompt आदान-प्रदान उदाहरणों को संकलित किया गया है। प्रॉम्प्ट ट्रांसक्रिप्ट उदाहरण में वास्तविक cost (कुल $6.45) तक सार्वजनिक की गई है। संबंधित commit1, commit2 जैसी सामग्री भी बताई गई। यह देखकर हैरानी हुई कि AI workflow पर ठोस first-hand अनुभव, ख़ासकर experienced लोगों के, hype के बीच बहुत कम मिलते हैं। todo list से आगे बढ़कर वास्तविक live coding examples की जानकारी जानने की उत्सुकता है। antirez और tptacek की लिखी चीज़ें भी देखें (antirez case, tptacek post)

    • ठीक-ठीक track नहीं किया, लेकिन Claude usage cost लगभग $50 रही होगी। बचाए गए समय की तुलना में यह नगण्य लागत है

  • मेरा मानना है कि “vibecoding” अंततः टिकेगा नहीं। अब भी बेहतरीन programmers की verification और bug fixing की ज़रूरत पड़ती है, और कुछ bugs तो AI ठीक भी नहीं कर पाई। अंततः ये tools वही लोग speed-up करने के लिए इस्तेमाल कर सकते हैं जो उस काम को पहले से अच्छी तरह समझते हों। बहुत basic homepage जैसी चीज़ों को छोड़ दें, तो उन्हें auto-generate करने वाले tools कई सालों से मौजूद हैं

    • vibecoding अभी low-stakes कामों के लिए सबसे उपयुक्त है। GUI, CRUD apps, one-off experiments जैसी चीज़ों में, ख़ासकर उन लोगों को नई शक्ति देने में जो परंपरागत रूप से ज़्यादा ताक़तवर नहीं थे, यह उपयोगी है। यह मामला vibecoding नहीं बल्कि LLM-assisted coding ज़्यादा लगता है

    • व्यवहार में लगता है कि vibecoding शब्द को कई बार attack करने वाले strawman की तरह इस्तेमाल किया जाता है। ज़्यादातर लोग अगर LLM से लिखवाए code में थोड़ा-बहुत fix करके उसे इस्तेमाल कर रहे हैं, तो क्या उसे भी vibe coding नहीं माना जा सकता?

  • OP ने सिर्फ AI-generated code ही नहीं, बल्कि prompts भी सार्वजनिक किए, इसके लिए बहुत आभार। निजी तौर पर LLM से non-web code बनाते हुए—ख़ासकर इन दिनों SAP ABAP का reverse engineering करके data को Snowflake के हिसाब से ढालने वाली .NET implementation—मुझे हर बार hallucination issues से जूझना पड़ा है। दूसरे लोगों की success stories देखकर लगता था शायद मेरे prompts ही ख़राब हैं, लेकिन इस public example को देखकर समझ आया कि मैं इतना भी पीछे नहीं हूँ। मुझे लगता है LLM मेरे case में इसलिए अच्छा fit नहीं बैठता क्योंकि समस्या थोड़ी rare और नई है। GitHub पर खुले पड़े OAuth जैसे heavily learned targets की तरह न हो, तो LLM साथ नहीं दे पाता

  • इस तरह का repetitive code, जो पहले ही सैकड़ों बार implement हो चुका है, AI के लिए बिल्कुल उपयुक्त है। कुल code लगभग 1200 lines का है, यानी आकार में छोटा। AI इस्तेमाल करने के बाद भी 2 दिन से ज़्यादा लगे, यह उल्टा थोड़ा surprising लगा

  • पिछले कुछ महीनों में Cursor के साथ Claude का उपयोग करके अपना greenfield project बनाते हुए तीन बातें महसूस हुईं। पहली, productivity बहुत बढ़ गई। दूसरी, mental fatigue पहले से काफ़ी ज़्यादा हो गई। तीसरी, बहुत कम समय में भी tools तेज़ी से evolve होने लगे हैं, और ऊपर की दोनों effects भी बढ़ रहे हैं

    • मेरा अनुभव भी यही है, और दूसरे developers से भी यही सुना है। LLM-assisted coding productivity को सच में बहुत बढ़ाता है, लेकिन energy consumption भी उतनी ही बढ़ जाती है। यह थोड़ा अजीब तक लगता है

    • “इतनी ज़्यादा थकान” वाली बात पर सवाल किया गया। मैं अपने agent (Devstral) को पुराने तरीके के बजाय “pair programming” की तरह इस्तेमाल कर रहा हूँ, और पूरे code को खुद type करने से review करना कहीं आसान लगता है। time-wise यह बड़ा advantage है। vibe coding में codebase context खो जाता है, इसलिए बाद में review और onboarding barrier बहुत बढ़ जाता है। वहीं pair programming में context build होता रहता है, इसलिए review तेज़ लगता है

    • मेरा अनुभव बिल्कुल उल्टा है। AI सारी छोटी-छोटी details खुद संभाल लेता है, जिससे बहुत राहत मिलती है। इससे architecture जैसे higher-level goals पर focus करने की आज़ादी मिलती है

  • Cloudflare जैसी company से "Too Many Requests" error आना काफ़ी मज़ेदार लगता है

    • मेरे लिए भी वही बात है