सभी ग्राहकों के लिए Cloudflare OAuth

 (blog.cloudflare.com)
5 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare अब ग्राहकों को खुद self-managed OAuth ऐप बनाने की सुविधा दे रहा है, ताकि Cloudflare API access को standard delegated authorization flow के ज़रिए उपलब्ध कराया जा सके
  • पहले केवल कुछ manually onboarded partners ही third-party OAuth का उपयोग कर सकते थे, और अपने integrations बनाने वाले developers को delegated app flow के लिए उपयुक्त न होने वाले API tokens पर निर्भर रहना पड़ता था
  • public release के लिए consent screen, revocation, और app ownership visibility को बेहतर बनाया गया, और OAuth engine Hydra को 1.X से 2.X तक चरणबद्ध तरीके से upgrade किया गया
  • upgrade के दौरान schema migration, token refresh errors, revocation events खोने का जोखिम, और 403 में वृद्धि जैसी समस्याएँ आईं, जिनका समाधान concurrent index creation, revocation replay queue, और data restoration से किया गया
  • upgrade के बाद API P95 185ms से 101ms तक 45% कम हो गया, और CPU उपयोग भी 1.07 core से 0.67 core तक घट गया, जिससे public OAuth संचालन की नींव स्थिर हुई

Cloudflare OAuth की सार्वजनिक उपलब्धता का विस्तार

  • Cloudflare लंबे समय से platform API के ज़रिए automation, CI/CD, और infrastructure integrations बनाने की सुविधा देता रहा है, और अब उसने self-managed OAuth को सभी ग्राहकों के लिए उपलब्ध कर दिया है
  • Cloudflare OAuth स्वयं कोई नई सुविधा नहीं है; यह पहले से Wrangler और PlanetScale जैसे partner integrations में इस्तेमाल होता रहा है
  • लेकिन पहले third-party OAuth केवल कुछ manually onboarded integrations तक सीमित था, इसलिए यह व्यापक developer ecosystem के लिए खुला नहीं था
  • अपने integrations बनाने वाले developers को API tokens पर निर्भर रहना पड़ता था, और यह तरीका manage करना कठिन था तथा कई delegated application flows के साथ अच्छी तरह मेल नहीं खाता था
  • self-managed OAuth का उपयोग करके developers standard OAuth flow दे सकते हैं, जिसमें ग्राहक खुद scoped access को approve करते हैं
    • मुख्य use cases हैं SaaS integrations, internal developer platforms, और agent tools
    • users को अधिक स्पष्ट consent, आसान revocation, और application permissions पर अधिक control मिलता है

सार्वजनिक रिलीज़ के लिए security foundation को मज़बूत करना

  • शुरुआती OAuth solution कुछ managed partners के लिए पर्याप्त था, लेकिन सभी ग्राहकों के लिए इसे खोलने के लिए permission model, consent experience, और abuse mitigation पर्याप्त परिपक्व नहीं थे
  • Cloudflare ने इस साल की शुरुआत में consent experience को बेहतर बनाया, ताकि यह अधिक स्पष्ट दिखे कि कौन-सा application access मांग रहा है और उसे कौन-कौन सी permissions मिलेंगी
  • dashboard में revocation feature जोड़ा गया, ताकि developers आसानी से control कर सकें कि कौन-से applications उनके data तक पहुंच सकते हैं
  • OAuth phishing attacks को कम करने के लिए app ownership को भी अधिक स्पष्ट बनाया गया
  • self-managed OAuth को सभी ग्राहकों के लिए खोलने के लिए ऐसा OAuth engine upgrade आवश्यक था जो user disruption को न्यूनतम रखते हुए data stability और security बनाए रखे

Hydra 1.X upgrade की तैयारी

  • Cloudflare लंबे समय से open source OAuth engine Hydra को Cloudflare OAuth के internal engine के रूप में उपयोग करता आया है
  • developer platform के बढ़ने और agent workflows के बढ़ने के साथ, नए features और performance improvements के लिए बड़े upgrade की आवश्यकता हुई
  • एक ही बार में बड़ा upgrade करने के बजाय, पहले latest 1.X release पर जाने, फिर behavior और performance changes का आकलन करने, और उसके बाद 2.X upgrade पर जाने वाली क्रमिक रणनीति चुनी गई
  • केवल 1.X upgrade से भी ग्राहकों पर असर पड़ने की संभावना थी
    • Hydra database महत्वपूर्ण tables पर exclusive lock लगाकर indexes बनाता था
    • महत्वपूर्ण tables में columns जोड़े गए, और कुछ अन्य columns को नई tables में स्थानांतरित किया गया
    • उपयोग में मौजूद Hydra version का SDK SELECT * चलाता था, जिससे schema change के समय deserialization समस्याएँ हो सकती थीं
  • user impact रोकने के लिए SQL migrations को CREATE INDEX CONCURRENTLY जैसे तरीकों से फिर लिखा गया, और SELECT * के बजाय explicit columns चुनने वाला custom Hydra version बनाया गया

Hydra 2.X upgrade strategy

  • 2.X upgrade में schema changes का दायरा बड़ा था, इसलिए in-place upgrade उपयुक्त नहीं था, और Cloudflare ने blue-green strategy चुनी
  • केवल नए version पर switch कर देना पर्याप्त नहीं था
    • upgrade और migration में कई घंटे लगने थे
    • उस दौरान system को लगातार सही ढंग से काम करते रहना था
  • पहला blue-green विकल्प database writes को रोककर नए authorizations को block करने का था
    • transition के दौरान नई writes खोती नहीं थीं
    • जिन users के पास पहले से valid credentials नहीं थे, वे मौजूदा OAuth apps का उपयोग नहीं कर सकते थे
    • upgrade के दौरान users application access को revoke नहीं कर सकते थे
  • अंतिम strategy में database writes जारी रखी गईं, लेकिन कुछ write loss स्वीकार किया गया और जोखिम को कम करने की कोशिश की गई
    • नए token writes कम करने के लिए token expiry time को कई घंटों तक बढ़ाया गया
    • upgrade से पहले token पाने वाले apps बिना नए refresh के चलते रह सकते थे
  • revocation events खोने से बचने के लिए Cloudflare Queues पर आधारित queue system का उपयोग किया गया
    • जब भी revocation event होता, उसकी जानकारी queue में लिखी जाती
    • green version database पर switch करने के बाद queue को drain करके upgrade window के दौरान हुए revocations को replay किया गया
    • यदि यह process fail हो जाती, तो users द्वारा revoke किए गए applications का access अनजाने में फिर बहाल हो सकता था

1.X upgrade और token refresh समस्या

  • latest 1.X release पर पहला upgrade operational दृष्टि से बड़े मुद्दों के बिना पूरा हुआ
  • custom database migration अपेक्षा से तेज़ चली और users पर कोई प्रभाव नहीं पड़ा
  • पुराना version नए version द्वारा बनाए गए tokens को introspect नहीं कर सकता था, इसलिए hard cutover आवश्यक था
  • cutover के बाद पहले से न दिखने वाली refresh token errors बढ़ गईं
    • इसका कारण नए version का अधिक सख्त refresh invalidation behavior था
    • refresh token reuse होने पर Hydra पूरी access token और refresh token chain को invalidate कर देता था
    • Wrangler और MCP clients में request volume अधिक होने के कारण, एक बार refresh token reuse होने पर पूरा session invalidate हो सकता था
  • Cloudflare ने OAuth traffic को सही destination तक route करने वाले Worker में refresh token coalescing behavior जोड़ा
    • Hydra तक पहुँचने से पहले refresh token requests को थोड़ी देर cache किया गया
    • retries का पता चलने पर token को invalidate किए बिना request को short-circuit करके response दिया गया
    • Hydra 2.X में configurable refresh token grace period है, जो पूरी chain invalidation के बिना कुछ समय तक refresh token retries की अनुमति देता है

2.X transition और recovery process

  • Cloudflare कई घंटों के user-impacting downtime की अनुमति नहीं दे सकता था, इसलिए blue-green upgrade चलाया गया
  • वास्तविक transition में केवल database copy और नए Hydra deployment से अधिक काम शामिल था
    • revocation replay capture queue को सक्रिय करना
    • database copy करना और नए target पर restore करना
    • नए version constraints का उल्लंघन करने वाले पुराने data को साफ करना
    • Hydra service और दो महत्वपूर्ण internal systems का एक साथ cutover
    • cutover के बाद monitoring और validation
  • upgrade window Hydra के requests per second सबसे कम होने वाले समय पर चुनी गई, ताकि token write loss को न्यूनतम रखा जा सके
  • production migration कुछ timeout tuning के अलावा नए database पर अच्छी तरह चली, और इसका शुद्ध execution time लगभग 3 घंटे था
  • traffic switch के तुरंत बाद authorization service के data cleanup task ने OAuth policy data को जरूरत से ज़्यादा delete करना शुरू कर दिया
    • वह service Hydra consent session API पर निर्भर थी
    • Hydra migrations में से एक ने कुछ valid OAuth session states को खराब कर दिया, जिससे valid sessions को invalid के रूप में चिह्नित किया गया
    • Hydra और authorization service के बीच यह mismatch 403 में वृद्धि के रूप में सामने आया
  • Cloudflare ने data restoration से इसे कम किया और static policy data पर निर्भरता घटाने के लिए OAuth authorization behavior में सुधार का काम शुरू किया
  • इसके अलावा, कुछ client-specific behaviors से जुड़े छोटे fixes भी जल्दी लागू किए गए

upgrade के बाद performance improvements

  • Hydra version upgrade पूरा होने के बाद OAuth traffic स्थिर रहा, और ग्राहकों के लिए system performance तथा reliability में सुधार हुआ
  • नया foundation वही है जिस पर staging में पहले से सत्यापित नया OAuth API आधारित है, और इसी ने 3 जून की self-managed OAuth release को संभव बनाया
  • database migration के दौरान देखे गए प्रमुख metrics:
    • updated rows: 132.5M
    • inserted rows: 114.7M
    • temporary bytes: 136.97GB
    • transaction commits: 22.2k
  • upgrade के बाद Hydra के औसत performance metrics में समग्र सुधार हुआ
    • API P95: 185ms → 101ms, 45% कमी
    • RSS memory: 888MB → 763MB, 14% कमी
    • Go heap alloc: 449MB → 271MB, 40% कमी
    • Goroutines: 4015 → 3076, 23% कमी
    • CPU: 1.07 core → 0.67 core, 37% कमी

शुरू कैसे करें

  • अब सभी Cloudflare ग्राहक अपने स्वयं के OAuth applications बना सकते हैं और Cloudflare पर integrations तैयार कर सकते हैं
  • शुरू करने के लिए documentation देखें या dashboard के OAuth apps page पर अपना पहला OAuth app बनाएं

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • Ory Hydra बनाने वाला मैं ही हूं। इस ब्लॉग पोस्ट और तकनीकी व्याख्या को देखकर सच में अच्छा लगा, और मैंने कभी कल्पना नहीं की थी कि यह software दुनिया की internet कंपनियों की सुरक्षा करेगा
    अच्छा है कि 2.x version उस scale पर ठीक से काम कर रहा है, और CPU usage भी अविश्वसनीय रूप से कम दिखता है
    अगर समस्या आए तो एक तेज़ commercial version भी है। अगर आपको अपना OAuth, IAM, ReBAC permissions, API keys, agent security में रुचि है, तो open source और commercial products https://github.com/ory और https://www.ory.com/ पर देख सकते हैं

  • पहले dotnet के लिए identity server framework को self-host करके चलाया था और हर महीने अरबों requests handle की थीं; उस scale पर OAuth और OpenID Connect असल में लगभग solved problem जैसा था और maintenance burden भी कम था
    यह संगठन की core service थी और compliance भी कड़ा था, लेकिन जिम्मेदार team शायद करीब 3 लोगों की थी और आज भी अच्छी तरह चल रही है
    मुझे समझ नहीं आया कि इस protocol को लेकर इतनी उलझन क्यों है, और जिन लगभग सभी junior engineers के साथ मैंने काम किया, उन्हें इसे समझने में मुश्किल हुई। Scott Brady का ब्लॉग https://www.scottbrady.io/ इस विषय में बहुत मददगार है
    authentication/authorization आते ही engineers में कोई मूलभूत “डर” पैदा होता दिखता है। वे problem-solving के आदी होते हैं, लेकिन authentication/authorization उस problem-solving की prerequisite की तरह आ जाता है और cognitive cost बनाता है, ऐसा मुझे लगता है

    • क्या dotnet के लिए identity server वही product है जो commercial product बन गया और जिसका इस्तेमाल करने की cost बहुत महंगी हो गई? Lite भी सालाना लगभग 6000 डॉलर से शुरू होता है: https://duendesoftware.com/pricing

  • यह typical Cloudflare है। सबके लिए अच्छी तरह काम करता है और बहुत महंगा भी नहीं है, लेकिन इन सभी फायदों के नतीजे में हर चीज़ के केंद्र में आ बैठता है

    • अगर basic scope से बाहर जाएं तो Cloudflare सबसे महंगे providers में से एक है। video streaming की pricing देख लीजिए
    • मुझे लगता है उस स्तर पर यह fair trade है

  • Grant हूं। Aeneas के साथ मिलकर 2.0 migration code का ज्यादातर हिस्सा लिखा था। Cloudflare team की post के लिए धन्यवाद
    “जांच में पाया गया कि Hydra migrations में से एक में समस्या थी, जिससे कुछ valid OAuth sessions की state corrupt हो गई, और नतीजे में migration ने उन sessions को invalid mark कर दिया” वाला हिस्सा क्या open source migration files में से किसी एक के बारे में था, यह जानना चाहूंगा
    अब मैं project से जुड़ा नहीं हूं, लेकिन जानना चाहता हूं कि upstream में fix हुआ है या नहीं

  • पूरे context में कम-से-कम Cloudflare ecosystem के अंदर authorization और authentication flows की planning भी शामिल होनी चाहिए, इसलिए भावनाएं मिली-जुली हैं। GitHub example भी नहीं है
    फिर भी यह सही है कि Cloudflare ने सही दिशा में शुरुआत की है, लेकिन underlying Ory के पूरे product family से तुलना करें तो अभी लंबा रास्ता बाकी है। Ory Kratos identity, login, registration, recovery, multi-factor authentication आदि handle करता है: https://github.com/ory
    मुझे लगता है full scope में user storage, SAML, और multi-tenant organization model की planning भी शामिल होनी चाहिए। अच्छे example के तौर पर Zitadel https://github.com/zitadel organization multi-tenancy के लिए admin UI, OIDC/PKCE support आदि देता है और RBAC भी कुछ हद तक जोड़ा जा सकता है
    Supabase भी managed और open source authentication देता है: https://github.com/supabase/auth
    “MCP मर चुका है और Skills अमर हैं” वाली बात अलग रखते हुए, मुझे चिंता है कि इन सबमें MCP जोड़ने और keys rotate करने की planning जल्द ही बहुत बड़ा मुद्दा बनकर फूटेगी
    OAuth 2.0 Dynamic Client Registration (RFC 7591): https://datatracker.ietf.org/doc/html/rfc7591
    https://modelcontextprotocol.io/specification/2025-03-26/bas...
    खासकर multi-tenant SaaS और embedded AI assistant के context में राय सुनना चाहूंगा

    • हाल ही में मैंने एक IAM vendor के साथ MCP services को protect करने का काम किया, और उस context में OAuth dynamic client registration डरावना लगा
      MCP को agents से connect करते समय आम तौर पर इस्तेमाल होने वाले redirect flow में, specification इस बारे में लगभग कुछ नहीं कहता कि इसे सुरक्षित कैसे बनाया जाए
      मैं नहीं चाहूंगा कि कोई भी मनमाने callback के साथ client register कर सके। वह phishing के लिए खुला रास्ता है
      malicious callback URL के साथ client register करने के बाद अगर user को वह flow शुरू करने वाले link पर click कराने में धोखा दिया जाए, तो legitimate identity provider user को authenticate करने के बाद access token attacker को दे देगा
      specification client के registration से पहले मिलने वाले initial access token की बात करके इसे मोटे तौर पर टाल देता है, लेकिन details कम हैं और ऐसी स्थिति में जहां सभी end users client बन जाते हैं, यह शायद काम करना मुश्किल होगा
      ideally, redirect pattern allowlist specify करके उसे ChatGPT जैसे targets तक सीमित करना चाहूंगा। लेकिन यह non-standard behavior है, इसलिए IAM vendors जल्दी नहीं कर रहे

  • यहां मंशा क्या है, समझ नहीं आ रहा। ऐसा कोई world नहीं है जहां यह अच्छे से खत्म हो। Cloudflare लगभग infrastructure provider है, और ऐसा infrastructure model जिसमें कोई user अपने account permissions किसी third-party client को delegate करे, उसमें abuse की संभावना बहुत ज्यादा है
    अगर AWS जैसी company यह नहीं करती, तो उसके पीछे कोई वजह होगी, ऐसा मुझे लगता है

    • AWS ठीक यही करता है
      उदाहरण के लिए IAM किसी specific repository में चलने वाले GitHub Actions को Lambda update करने की permission दे सकता है
    • क्या आप समझते हैं OAuth क्या है? यह API key जैसा है, लेकिन abuse की संभावना कम होती है। यह अच्छी चीज़ है, कई तरीकों से security में मदद करता है और token लेकर घूमने की तुलना में security flows को ज्यादा सुरक्षित बनाता है
    • मुझे नहीं पता यह Google users के लिए नया OAuth client बनाने वाले Google Developer Program से कितना अलग है

  • OAuth और एंटरप्राइज authentication शायद अब तक बनाई गई सबसे खराब चीज़ों में से हैं। cloud से निपटते समय यह सबसे confusing और annoying हिस्सा हो सकता है
    AI tools को भी headless systems में basic OAuth handle करने में ही 1 साल लग गया, वह भी यह मानकर नहीं कि वे browser खोल सकते हैं
    अगर हम बड़े cloud providers की RBAC/IAM/workload identity/service accounts जैसी तमाम authentication rabbit holes में उतरने वाले हैं, तो personal use के लिए कोई simple तरीका प्लीज़ बचा रहने दें
    बस एक API key काफी है। उसे secret रखें और ज़रूरत पड़ने पर revoke कर दें; हर platform की हर layer में authentication के 10,000 layers के clutter की ज़रूरत नहीं है

    • समझ नहीं आता कि OAuth पर privacy के context में लगभग बात क्यों नहीं होती। OAuth provider को पता चल जाता है कि user किस site में कब login कर रहा है
      यह privacy nightmare है
    • OAuth2 complex है और अक्सर सही tool नहीं होता। मैंने Ory Hydra बनाया था, और यह भी लिखा था कि OAuth2 कब अच्छा choice है और कब नहीं: https://www.ory.com/blog/oauth2-openid-connect-do-you-need-u...
      API keys के लिए हमने अभी Ory Talos(https://github.com/ory/talos) release किया है। जब OAuth2 आपके use case के हिसाब से overkill हो, तो यह अच्छा alternative है
      OAuth2 का use justify करने वाले use cases और security concerns भी हैं। DPoP जैसी specifications इन flows को अधिक secure बना सकती हैं
      यहां दिया गया use case OAuth2 के लिए उपयुक्त लगता है, लेकिन यह हर जगह fit नहीं होता। complexity system security को और कठिन बना देती है
    • लगता है common login flow भी पूरी तरह खराब कर दिया गया है। आम तौर पर password manager username और password fields auto-fill कर देता था, लेकिन OAuth की वजह से अक्सर सिर्फ username field दिखती है या पहले “password से login करें” जैसा button दबाने वाला बेवकूफाना step आ जाता है
    • data के हिसाब से उस API key को secret बनाए रखने में failure की संभावना ज्यादा है, और ज़रूरत पड़ने पर उसे revoke करने में भी failure की संभावना बड़ी है। जाहिर है, जितनी बार rotation चाहिए उतनी बार तो होगा ही नहीं
      OAuth2/OIDC का फायदा यह है कि trust API key holder पर नहीं, बल्कि उस वास्तविक identity पर रखा जाता है जिसे access चाहिए
    • तो इसे application में सीधे implement कर दें। random key generate करें और hash व salt store कर दें, बस
      authentication कठिन है, यह बात बहुत सारे users के लिए authentication पर लागू होती है। अपने लिए authentication बहुत simple है, और अच्छा framework इस्तेमाल करें तो और आसान हो जाता है
      implementation को लेकर भरोसा न हो तो इसे latest models में से किसी एक को दे दें। इतने simple authentication system में problems ढूंढने में वे काफी अच्छे हैं

  • “Ory Enterprise License: CVE security SLA, SAML, B2B organizations, multi-tenancy, बेहतर scalability जैसी enterprise-grade features unlock करता है” [0]
    या फिर पूरी तरह self-hosted product देने वाला Keycloak ही इस्तेमाल करते रह सकते हैं [1]
    [0]https://github.com/ory
    [1]https://www.keycloak.org/

    • Keycloak शानदार है, उदाहरण के लिए अगर आप internal employees के लिए पूरा Java server stack चलाना चाहते हैं, लेकिन मुझे लगता है कि Ory बड़े पैमाने के operations, जैसे OpenAI https://www.ory.com/case-studies/openai जैसे cases और composable approach में कहीं बेहतर है
      commercial version होने की वजह यह सवाल है कि world-class open source को financially sustainable कैसे बनाया जाए। दुनिया की सबसे बड़ी software companies को सहारा देने वाले open source के लिए workable business model होना बुरी नहीं, अच्छी बात है
      वैसे, IBM ने भी Keycloak से पैसे कमाने का तरीका खोज लिया है
    • Production में Keycloak handle किया है और वह इतना शानदार नहीं है। शायद अगर internally Infinispan और JGroups का इस्तेमाल न करता तो बेहतर होता। दोनों बिना वजह बेहद complex हैं
    • Keycloak ही है

  • यह मूल रूप से Cloudflare account access के लिए OAuth की बात है, custom apps के लिए Cloudflare-hosted general-purpose “login” type feature नहीं

    • मैंने भी पहले बाद वाला सोचा था, और सोच रहा था कि यह क्या offer करता है

  • मुझे लगा था कि मैंने OAuth क्या है समझ लिया है, लेकिन यह article confused कर रहा है। मैंने इसे per-client access keys देने वाला standardized protocol माना था
    यहां self-managed OAuth क्या है? किस चीज़ का access grant किया जा रहा है, client कौन है, और partner कौन है—यह explain करने की जरूरत है

    • इसका मतलब है, “इस महीने की शुरुआत में, हमने self-managed OAuth announce किया, जिससे customers Cloudflare API के delegated access के लिए OAuth clients खुद आसानी से बना और manage कर सकते हैं”
      यह आपको अपनी resources के access को approve/deny करने वाला OAuth system खुद host करने देता है। Cloudflare से यह इंतजार करने के बजाय कि वह X condition पर Y allow करे, आप अपनी मनचाही logic बना सकते हैं
      असल में flow ऐसा है: “Cloudflare में login” → Cloudflare self-managed OAuth use की पुष्टि करता है → user के OAuth पर redirect → Cloudflare response पर trust करता है → user approve करे तो account access allow हो जाता है
    • मूल रूप से इसका मतलब है कि आप अपना authorization server host कर सकते हैं