Google OAuth टूटा हुआ है (कुछ हद तक)

मूल लेख ↗ Hacker News चर्चा ↗

हाल ही में उजागर हुआ Google OAuth व्यवहार कर्मचारियों को email aliases (जैसे [email protected]) का उपयोग करके अलग Google accounts बनाने देता है, जो कंपनी के नियंत्रण से बाहर बने रह सकते हैं, और इससे Slack या Zoom जैसे तीसरे-पक्ष ऐप्स तक पहुँच off-boarding के बाद भी बनी रह सकती है। टिप्पणीकारों का तर्क है कि यह Google की implementation की खामी से कम और OAuth/OIDC के व्यापक दुरुपयोग से अधिक जुड़ा है, खासकर email को स्थिर, भरोसेमंद identifier मानने और proper subject IDs तथा verification flows का उपयोग न करने से। यह चर्चा आधुनिक web authentication standards की जटिलता और क्या Google के $1,337 payout जैसे bug bounty rewards जिम्मेदार disclosure को वास्तव में प्रोत्साहित करते हैं, इस पर भी चिंता उठाती है.

बग बाउंटी का मूल्य और Google की प्रतिक्रिया

  • कई लोगों को $1337 का भुगतान संभावित प्रभाव को देखते हुए प्रतीकात्मक लगता है और वे इसे कहीं और इसी तरह की समस्याओं के लिए बताए गए अधिक भुगतानों की तुलना में कमतर मानते हैं।
  • अन्य लोग तर्क देते हैं कि जो वे दस्तावेज़ित व्यवहार या एक “footgun” मानते हैं, किसी क्लासिक भेद्यता नहीं, उसके लिए यह उदार है, और उन्हें आश्चर्य है कि इसके लिए कोई इनाम भी दिया गया।
  • कुछ लोग भुगतान में देरी (triage और reward के बीच महीनों का अंतर) को बड़ी कंपनियों के लिए सामान्य मानते हैं, लेकिन उनका मानना है कि असली समस्या राशि कम होना है, समय नहीं।

असल में दोषी कौन है? Google बनाम integrators

  • एक पक्ष कहता है कि खामी मुख्यतः तीसरे-पक्ष के ऐप्स (Slack, Zoom, आदि) में है जो:
    • email claim को प्राथमिक पहचानकर्ता के रूप में उपयोग करते हैं।
    • email domains से संगठन की सदस्यता का अनुमान लगाते हैं।
  • दूसरा पक्ष तर्क देता है कि जिम्मेदारी Google पर भी आती है क्योंकि:
    • Plus-address aliases और non-org Google accounts एक ही email routing साझा करते हैं, लेकिन Workspace admins के लिए अदृश्य रहते हैं।
    • Google सैद्धांतिक रूप से उन domains पर नए personal accounts ब्लॉक कर सकता था जो पहले से Workspace customers द्वारा दावा किए जा चुके हैं, या मजबूत controls प्रदान कर सकता था।

समस्या का तकनीकी मूल

  • Google user+suffix@domain (और dot variants) को user@domain के समान mailbox मानता है, लेकिन इन addresses के साथ अलग Google accounts बनाने देता है।
  • कोई कर्मचारी ऐसे alias का उपयोग करके पहले से non-org Google account pre-register कर सकता है, फिर बाद में official account deprovision होने के बाद भी corporate SaaS तक पहुँचने के लिए “Sign in with Google” का उपयोग कर सकता है।
  • प्रभाव इस बात पर निर्भर करता है कि SaaS authorization के लिए केवल email claim पर निर्भर है या नहीं; कुछ टिप्पणीकार इस बात पर ज़ोर देते हैं कि OIDC docs में इसे स्पष्ट रूप से हतोत्साहित किया गया है।

Mitigations और best practices

  • चर्चा में सुझाए गए पैटर्न:
    • स्थिर identity key के रूप में email नहीं, बल्कि iss + sub का उपयोग करें।
    • केवल email domain के आधार पर privileges कभी न दें।
    • corporate SaaS accounts के लिए explicit provisioning या allowlists की आवश्यकता रखें।
    • independent email verification भेजें या “magic link” + 2FA का उपयोग करें; आलोचक UX downsides और phishing risk की ओर इशारा करते हैं।
    • B2B control के लिए SAML/SCIM या dedicated enterprise IdPs को प्राथमिकता दें।

विस्तृत OAuth/OIDC और identity बहसें

  • कई प्रतिभागी delegated auth और OIDC को अत्यधिक जटिल, खराब तरीके से समझाया गया, और misconfiguration के प्रति संवेदनशील बताते हैं।
  • इस पर असहमति है कि email को प्राथमिक identity माना जाना चाहिए या नहीं:
    • पक्ष में: वैश्विक रूप से समझने योग्य, व्यापक रूप से उपयोग किया जाता है।
    • विपक्ष में: अस्थिर, reassigned, साझा, और विभिन्न IdPs में अद्वितीय नहीं।
  • कुछ लोग इस घटना को एक अकेले “Google OAuth टूटा हुआ है” पल के बजाय गड़बड़ web auth ecosystem का लक्षण मानते हैं।