Cloudflare की AI द्वारा लिखी गई OAuth लाइब्रेरी पर एक नज़र
(neilmadden.blog)- Cloudflare ने Anthropic के Claude LLM का उपयोग करके एक नई OAuth लाइब्रेरी विकसित की, और उसके prompts भी साथ में सार्वजनिक किए
- लाइब्रेरी का code structure साफ़-सुथरा है, लेकिन testing और security verification के मामले में कई कमियाँ दिखती हैं
- CORS और कुछ authentication standards के implementation में non-standard या risky choices पाई गईं
- cryptography implementation में कुछ मज़बूत पहलू हैं, लेकिन गंभीर security bugs और protocol की गलत समझ भी सामने आई
- LLM-आधारित auto-coding मददगार हो सकता है, लेकिन production-grade security के लिए expert की बारीक समीक्षा अनिवार्य है
Cloudflare OAuth लाइब्रेरी का अवलोकन
- Cloudflare ने OAuth provider लाइब्रेरी का अधिकांश हिस्सा Anthropic के Claude LLM की मदद से स्वचालित रूप से लिखा
- Claude के output की skilled Cloudflare engineers द्वारा security और standards compliance review की गई, और commit history में AI के साथ interaction process को transparently सार्वजनिक किया गया
- शुरुआती implementation के बाद Claude को दिए गए अतिरिक्त prompts और उसके outputs की समीक्षा के जरिए quality को बेहतर किया गया
- यह भी स्पष्ट किया गया कि केवल AI पर निर्भर नहीं रहा गया, बल्कि RFC documents के साथ cross-check और core expert review पर ज़ोर दिया गया
विशेषज्ञ की पहली छाप और code analysis
- LLM coding style की विशेषता के अनुसार code एक single file में केंद्रित है, लेकिन structure consistent है और बेकार comments अपेक्षाकृत कम हैं
- functional tests मौजूद हैं, लेकिन OAuth जैसे critical authentication service के लिए अपेक्षित स्तर तक नहीं पहुँचते
- कुछ जगह अनिवार्य (MUST/MUST NOT) specification checks गायब हैं और parameter validation कमज़ोर दिखती है
security से जुड़ी चिंताएँ और अनुवादक की व्याख्या
1. CORS policy समस्या ("YOLO CORS")
- लगभग सभी origins को अनुमति देने वाली CORS header setting पाई गई, जिससे same-origin policy व्यावहारिक रूप से निष्क्रिय हो जाती है
- यह हिस्सा Cloudflare engineer द्वारा LLM नहीं बल्कि सीधे मानव निर्णय से तय किया गया था
- credentials feature enabled नहीं है, इसलिए browser security पर तुरंत गंभीर खतरा कम है, लेकिन कारण और उद्देश्य की स्पष्टता अपर्याप्त है
2. standard security headers लागू न होना
- HTTP responses में X-Content-Type-Options: nosniff और HTTP Strict Transport Security जैसे प्रमुख security headers लागू नहीं किए गए
- JSON API की प्रकृति के कारण कुछ headers की आवश्यकता कम लग सकती है, लेकिन client/browser vulnerabilities की रोकथाम के लिए इन्हें लागू करना महत्वपूर्ण है
3. OAuth standard की अपर्याप्त समझ के संकेत
- Public client support के लिए OAuth 2.1 में deprecated implicit grant method लागू किया गया
- वास्तव में इस functionality को PKCE या CORS relaxation से पर्याप्त रूप से बदला जा सकता था
- ऐसा लगता है कि Claude ने implicit grant सुझाया, और वास्तविक token issuance चरण में इसकी सही validation नहीं की गई
- Basic Auth handling कमजोर है: OAuth में एक विशेष URL encoding method चाहिए, लेकिन उसे छोड़ा गया
- यदि client secret में colon शामिल हो तो security bug के रूप में secondary issue पैदा हो सकता है
- हालांकि, यह लाइब्रेरी खुद client ID/secret generate करती है, इसलिए format control संभव है
4. token ID generation code की security समस्या
- token ID के random string generation method में statistical bias मौजूद है
- entropy कम होने से attack आसान हो सकता है, हालांकि वास्तविक खतरा सीमित है
- "हर code line को expert ने review किया" इस दावे के बावजूद, शुरुआती commit में bug जस का तस मौजूद था
- पहले दिन एक developer द्वारा main branch में 21 direct commits जैसी history व्यवस्थित review की कमी का संकेत देती है
cryptography features और LLM interaction के उदाहरण
- token storage encryption design मानव-नेतृत्व में किया गया, और implementation में Claude ने सहायता दी
- प्रत्येक token के लिए props को encrypt किया गया, और हर token के लिए symmetric key wrapping approach लागू की गई
- जब Claude ने बीच में गलत design सुझाया, तो engineer ने intent और security rationale स्पष्ट रूप से बताकर उसे सुधारा
- उदाहरण: SHA-256 hash को wrapping key की तरह उपयोग करने पर सामने आने वाली vulnerability बताने के बाद इसे HMAC-based approach में बदला गया
- PBKDF2 सुझाव पर performance inefficiency की ओर इशारा किया गया, और 32-byte HMAC key के उपयोग की ओर समायोजन किया गया
- यह प्रक्रिया AI के साथ काम करते समय उच्च स्तर के domain knowledge की आवश्यकता को अच्छी तरह दिखाती है
- गैर-विशेषज्ञ के लिए critical flaws को पहचानना भी कठिन हो सकता है
समग्र मूल्यांकन और संकेत
- पहले version के हिसाब से कुल गुणवत्ता ठीक-ठाक है, लेकिन इसे सीधे production service में लागू करना जोखिमभरा है
- OAuth provider development स्वभाव से ही बहुत कठिन security और functionality verification की माँग करता है
- बड़े संगठनों में सैकड़ों हज़ार automated tests और multi-layered security checks सामान्य बात हैं
- यह ऐसा क्षेत्र नहीं है जहाँ LLM-based auto-coding को “आसानी से” लागू किया जा सके
- project की commit history दिलचस्प तरीके से दिखाती है कि LLM किस स्तर तक सहायक रूप में काम कर सकता है
- फिर भी कुछ defects ऐसी गलतियाँ हैं जो LLM और इंसान दोनों अक्सर करते हैं, और Stack Overflow जैसे समुदायों में भी इसी तरह दिखती हैं
- जिन code areas में बारीकी और सावधानी महत्वपूर्ण है, वहाँ AI और इंसान दोनों को गहरी सतर्कता की ज़रूरत होती है
- यदि LLM का उपयोग code review या output पर भरोसा करने के लिए किया जाए, तो सीधा implementation experience और System 2 thinking आवश्यक है
- सरल या non-core काम LLM को सौंपे जा सकते हैं, लेकिन authentication या security से जुड़े मुख्य systems में expert-led design और implementation अधिक उपयुक्त है
2 टिप्पणियां
Cloudflare ने Claude के साथ OAuth बनाया और सभी prompts सार्वजनिक किए
Hacker News राय
यह मामला सीधे दिखाता है कि LLM के साथ काम करते समय बहुत सारा domain knowledge चाहिए होता है। उदाहरण के लिए, Claude ने बीच में जो “घातक खामी” गढ़ दी, उसे शायद कोई सामान्य developer पहचान ही न पाए। PBKDF2 में बदलाव को अजीब मानना भी domain expertise की वजह से संभव हुआ। मेरा निष्कर्ष यह है कि LLM का असरदार उपयोग करने के लिए एक सक्षम reviewer और ‘लीडर’ की ज़रूरत होती है। अगर आप उस विषय को LLM जितना भी नहीं जानते, तो या तो काम का महत्व कम होना चाहिए, या आपके पास इतना समय होना चाहिए कि आप उसके हर output को verify कर सकें
आगे इस नए माहौल में domain experts पैदा कहाँ से होंगे, यह सवाल दिलचस्प है। आखिर इतनी गहरी समझ वाला व्यक्ति बनेगा कौन, यही चिंता है
जब भी लोग कहते हैं, 'LLM का इस्तेमाल सिर्फ उन क्षेत्रों में करो जिनके बारे में ज़्यादा नहीं जानते; अगर expert हो तो खुद coding करो', तो मुझे यह अजीब लगता है। उल्टा, expert लोग LLM के output की ज़्यादा सटीक समीक्षा कर सकते हैं, और मैं जो चाहता हूँ उसे जितना domain expert की तरह समझा पाता हूँ, उतना ही बेहतर नतीजा मिलता है। एक तरह से यह स्वाभाविक ही है, क्योंकि LLM सांख्यिकीय रूप से बना text engine है
LLM में defaults जोड़ने, exception handling डालने, और तरह-तरह के workarounds बहुत आसानी से ठूंस देने की प्रवृत्ति होती है। इसलिए ऐसा code जल्दी बन जाता है जो ऊपर से चलता हुआ लगे, लेकिन असल में उसमें समस्या हो या वह जल्द fail होने वाला हो। मैंने अपने CLAUDE.md में इस बात पर कई बार ज़ोर देने की कोशिश की, फिर भी अक्सर वही नतीजे आते रहे
मैंने LLM से ज़्यादातर k8s deployment का काम कराया है। यह जल्दी काम करने वाला result देता है, लेकिन मुझे बार-बार याद दिलाना पड़ता था कि secrets का उपयोग करे और credentials को plain text में commit न करे। ऐसी गलतियाँ सच में खतरनाक हैं। शैक्षणिक tutorials में अक्सर basics पर ध्यान देने के लिए security छोड़ दी जाती है, और लगता है LLM training data में ऐसे उदाहरण बहुत ज़्यादा हैं, इसलिए यह वैसा output देता है
समय के साथ उम्मीद है कि AI coding tools खुद domain knowledge पर research कर सकेंगे। कुछ मौजूदा ‘AI research’ tools पहले से इस मामले में बहुत अच्छे हैं, लेकिन अभी उनका coding tools के साथ सही integration नहीं हुआ है। यह research सिर्फ public internet ही नहीं, बल्कि company के internal docs में मौजूद domain knowledge को भी refer कर सकती है। हालांकि कुछ knowledge सिर्फ लोगों के दिमाग में होती है, इसलिए उसे user को खुद देना पड़ेगा
मैंने हाल ही में AI की मदद से Kafka consumer लिखकर data migration किया। इस तरह के short-term, scratch से शुरू होने वाले project में, जहाँ मैं language (go) को काफ़ी जानता हूँ लेकिन लंबे समय बाद इस्तेमाल कर रहा था, वहाँ AI का फायदा सबसे ज़्यादा मिला। सारा data एक ही topic में आ रहा था, इसलिए performance बनाए रखने के लिए काफ़ी complex parallel processing लागू करनी पड़ी। कुल मिलाकर लगा कि AI की वजह से काम लगभग 2 गुना तेज़ हुआ। खासकर जब go syntax कभी-कभी भूल जाता था, तब search करने के बजाय AI से तुरंत पूछ लेना मददगार था। लेकिन उसमें कम से कम 4 subtle bugs छिपे हुए थे, और बाकी साफ़ bugs तो उससे भी ज़्यादा थे। अगर Kafka या multithreading की समझ न होती, तो शायद मैं उसे सीधे production में भेज देता। बड़े/long-term projects में सुधार लगभग 10~20% के स्तर का दिखता है। मौजूदा models के हिसाब से अभी यही रुझान है। कुल मिलाकर यह productivity gain वैसा ही लगता है जैसा memory-managed languages पर जाने से मिला था। यह उस कल्पना से बहुत दूर है जिसमें PM developers की जगह ले लेगा, कम से कम पिछले 3 साल की रफ़्तार को देखते हुए। बल्कि मेरी असली चिंता यह है कि अगर mid-level ‘10x engineer’ तरह के लोग AI से 10 गुना efficient हो गए, तो subtle bugs ढूँढने या उनसे निपटने में वे और ख़तरनाक साबित हो सकते हैं। senior/staff engineers के लिए review का सैलाब संभालना मुश्किल हो सकता है। और junior से senior बनने की प्रक्रिया भी शायद और कमज़ोर हो जाएगी। copy-paste programmer पहले से समस्या हैं, और AI इस पैटर्न को और मज़बूत करेगा। आख़िरकार market इसका हल निकाल लेगा, लेकिन इसमें दशकों लग सकते हैं, यही चिंता है
AI से पैदा होने वाले bugs वाकई बहुत चालाक होते हैं। मैंने भी AI से multithreaded coding करवाई थी और एक subtle bug सचमुच production में पहुँचा दिया। review और testing करने पर भी उतनी एकाग्रता नहीं आती जितनी तब आती है जब code खुद हाथ से लिखा हो। फिलहाल लगता है कि AI द्वारा लिखे code का इस्तेमाल करते समय पहले सामान्य bugs की जाँच कर लेनी चाहिए, और उसे उन क्षेत्रों तक सीमित रखना चाहिए जहाँ उसका असर घातक न हो
मैं भी ‘महत्वपूर्ण काम’ में 10~20% सुधार ही महसूस करता हूँ। यह वास्तविक बदलाव तो है, लेकिन software development की मूल प्रकृति नहीं बदलता। आखिरकार Brooks की "No Silver Bullet" बात की ही फिर से पुष्टि होती है
मैं भी “mid-level 10x engineer” वाली बात से सहमत हूँ। खासकर consulting industry में veterans को अक्सर cost-benefit के हिसाब से कम महत्व दिया जाता है। पहले मैं भी जल्दी-जल्दी काम निपटाने वालों में था, और बाद में non-expert PM को short-term solutions की कमज़ोरियाँ समझाने में बहुत दिक्कत हुई थी। बड़ी IT companies ऐसे मुद्दों को जल्दी पकड़ लेंगी, लेकिन हकीकत में financial और medical data संभालने वाला code भी सस्ते short-term contractors से लिखवाया जाता है। यह समस्या LLM आने से पहले भी थी। अब security-sensitive developers के लिए समय और भी कठिन होगा
आपने generated code में subtle bugs मिलने की बात की, तो यह ख़याल आता है कि क्या ऐसे bugs को AI-generated test code से अपने-आप detect कराया जा सकता है। बेशक test code में भी bugs हो सकते हैं, लेकिन भविष्य में शायद ऐसा दौर आए जहाँ generated code की बजाय लोग सिर्फ test results की गहराई से समीक्षा करें
आपने complex parallel processing कहा, लेकिन क्या यह partition और consumer-group के इस्तेमाल से हल होने वाला मामला नहीं था, यह सवाल उठता है
जो लोग LLM पर पूरी तरह भरोसा करके ‘चट्टान से कूदने’ जैसी अंधी निर्भरता के साथ काम करते हैं, उन्हें देखकर घुटन होती है। पूरी तरह black box पर निर्भर होकर काम करना और validation भी उसी पर छोड़ देना खतरनाक है। ऊपर से यह बहुत ज़्यादा energy खपत करने वाली व्यवस्था है, और इसका इस्तेमाल लोगों की जगह लेने के बहाने के रूप में भी किया जाता है। ईमानदारी से कहूँ तो यह विश्वास नहीं होता कि ऐसा माहौल ज़िंदगी को 10 गुना बेहतर बना देता है
जब हम खुद development करने और किसी दूसरे के बनाए output, खासकर LLM-जनित code, को verify करने की प्रक्रिया की तुलना करते हैं, तो इंसान अक्सर उसकी विश्वसनीय दिखने वाली बाहरी शक्ल से धोखा खा जाते हैं और समस्याओं को कम आलोचनात्मक नज़र से देखते हैं। code का ‘दिखना’ भी bugs खोजने पर बड़ा असर डालता है। इसे परखने के लिए जानबूझकर code में bugs डालकर यह प्रयोग किया जा सकता है कि code reviewers उन्हें पकड़ते हैं या नहीं। जब आप कुछ खुद हाथ से implement करते हैं, तो आप बहुत अधिक धीरे, सावधानी से और बारीकी में सोचते हैं, और details पर ध्यान देते हैं, इसलिए कई अनपेक्षित bugs भी पकड़ में आ जाते हैं। इसी वजह से सीखने के लिए लोग tool का ‘toy version’ खुद लिखने की सलाह देते हैं। यह इंसानी cognition से जुड़ी बात है
लेख में कहा गया था कि उसमें फालतू comments ज़्यादा नहीं हैं, लेकिन असल code में
// Get the Origin header from the requestजैसे अर्थहीन comments मौजूद हैंऐसे comments LLM इस्तेमाल होने की पहचान जैसे लगते हैं; उनका कोई मतलब नहीं होता, इसलिए मैं हमेशा उन्हें हटा देता हूँ
इंसानों के लिए ऐसे comments बेकार हैं, लेकिन मुझे लगता है कि LLM के नज़रिए से अगर नीचे के code का काम natural language में भी साथ लिखा हो, तो वह समझने में किसी तरह के Rosetta Stone जैसा काम कर सकता है। इसकी कीमत token usage बढ़ना हो सकती है, लेकिन यह देखना दिलचस्प होगा कि क्या वास्तव में LLM बहुत ज़्यादा commented code पर बेहतर editing करता है
अनुभव के तौर पर साझा करूँ तो Claude ऐसी बेकार, दोहराव वाली comments बहुत ही ज़्यादा बार लिखता है
मैं जो प्रयोग सुझाना चाहता हूँ, वह यह है कि code की एक branch को freeze कर दिया जाए, और फिर AI का इस्तेमाल करके एक पक्ष vulnerabilities बनाने और छिपाने की कोशिश करे, जबकि दूसरा पक्ष उन्हें ढूँढकर ठीक करे। यानी chess के evolution जैसे मॉडल को code development पर लागू किया जाए
मैं ही इस library का लेखक हूँ, या अधिक सटीक रूप से कहें तो prompt लेखक। मैं Neil जितना तो नहीं, लेकिन OAuth के बारे में कुछ हद तक expert हूँ, और उसने code review किया, यह मेरे लिए बहुत खुशी की बात है। “YOLO CORS” को लेकर एक गलतफ़हमी थी; यह कोई साधारण beginner mistake नहीं थी। ये CORS settings सोच-समझकर जानबूझकर की गई थीं। मैंने सिर्फ OAuth API endpoints, जैसे token exchange और client registration, और उन API endpoints पर CORS disabled किया जहाँ OAuth bearer token की ज़रूरत होती है। इन endpoints पर browser credentials, जैसे cookies, से authentication नहीं होता, इसलिए मेरे हिसाब से CORS यहाँ किसी चीज़ की रक्षा नहीं कर रहा था। CORS का मूल उद्देश्य यह सुरक्षा परत है कि credentials अपने-आप attach न हों, जबकि bearer token client को खुद स्पष्ट रूप से attach करना पड़ता है, इसलिए cross-origin में भी यह सुरक्षित है। दरअसल, मैं पहले भी CORS spec लिखने वालों से बहस कर चुका हूँ और हमेशा यह कहता आया हूँ कि browser credentials की बजाय bearer token इस्तेमाल करना ही वास्तव में सुरक्षित है। दूसरी ओर, token ID generation को inefficient कहने पर मैं इसे ‘घातक’ नहीं मानता। security के लिहाज़ से इसमें समस्या नहीं है, और algorithm को बाद में आराम से बदला जा सकता है। एक ही व्यक्ति द्वारा एक ही दिन main पर 21 commits दिखने की वजह सिर्फ git history rewriting है, जिससे GitHub पर तारीख़ें विकृत दिखीं। cryptography implementation की तारीफ़ के लिए सच में धन्यवाद। वह AI ने नहीं बनाया था; उसके लिए मैंने explicit design निर्देश दिए थे
आपने कहा कि "OAuth API में CORS headers disable किए गए हैं", लेकिन असल में CORS rules को निष्क्रिय करने के लिए CORS headers सेट किए जा रहे हैं। संदर्भ से बात समझ आ जाती है, लेकिन भ्रम हो सकता है, इसलिए यह स्पष्टीकरण जोड़ा गया
यह जानने की जिज्ञासा है कि क्या Cloudflare इस library को वास्तव में production में इस्तेमाल करने की योजना रखता है
लोकप्रिय Stack Overflow जवाबों में भी यही गलतियाँ भरी पड़ी हैं, और यह सोचकर चिंता होती है कि Claude ने भी शायद वहीं से सीखा होगा। security holes या mistakes से भी ज़्यादा डरावनी बात यह है कि समाज का सामूहिक ज्ञान LLM से पहले के internet के लोकप्रिय जवाबों पर ही स्थिर हो जाए
ForgeRock में OAuth implementation के दौरान सैकड़ों security bugs मिले, और यह तब जबकि लाखों automated tests, threat modeling, top-tier SAST/DAST, expert reviews वगैरह सब मौजूद थे। यह देखकर फिर एहसास होता है कि OAuth कितना मुश्किल है। कुछ लोग तो इसे ‘dumpster fire’ जैसे implementation क्षेत्र के रूप में भी देखते हैं। हालाँकि मैंने खुद कभी spec नहीं पढ़ी और न उसे implement किया है
जब-जब OAuth implementation में शामिल हुआ हूँ, हर बार यह बेहद डरावनी जटिलता वाला लगा है
OAuth सचमुच झंझट भरा है, और इसमें बहुत सारे niche cases हैं
सच तो यह है कि नया लिखा गया code लगभग हमेशा buggy होता है। जितना complex होगा, उतना अधिक। इसी वजह से companies ‘battle tested’ code और tools का इस्तेमाल करना चाहती हैं। मज़ाक अलग, लेकिन Anthropic अपने ही generated AI को अपने code में व्यावहारिक रूप से कैसे इस्तेमाल कर रहा है, यह दिलचस्प है। आगे क्या वे इसे MCP authentication API पर भी इस्तेमाल करेंगे, यह देखने लायक होगा
“लाखों tests” सुनकर लगता है कि या तो वह सिर्फ संख्यात्मक विस्तार है, या फिर शायद सीधे LLM-जनित हों। यह भी जिज्ञासा है कि आख़िर उन्हें maintain कौन करता है
यह जानना दिलचस्प होगा कि क्या लोग अपने prompts को git में commit करने की प्रवृत्ति को सामान्य बना देंगे, या यह सिर्फ showcase जैसी चीज़ है