Google OAuth में कुछ कार्यक्षमता बाधित

 (trufflesecurity.com)
1 पॉइंट द्वारा GN⁺ 2023-12-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जो सेवाएं लॉगिन अधिकार तय करने के लिए Google OAuth के email claim पर भरोसा करती हैं, उनमें कंपनी के Google organization से हटाए जाने के बाद भी पूर्व कर्मचारी Slack·Zoom जैसे ऐप्स तक access बनाए रख सकते हैं
  • Gmail के अलावा दूसरे email से भी Google account बनाया जा सकता है, और कंपनी email के alias·plus-address forwarding का उपयोग करने पर organization से बाहर का Google account कंपनी domain वाला email claim भेज सकता है
  • यह गैर-Gmail account कंपनी Google organization के admin screen या user list में दिखाई नहीं देता, लेकिन कई सेवाएं email के अंत में मौजूद domain देखकर ही login की अनुमति दे देती हैं
  • Organizations Google login बंद करके SAML को सख्ती से लागू कर mitigation कर सकती हैं, लेकिन कुछ services या internal apps यह option नहीं देते या SAML support नहीं कर सकते
  • Google को 4 अगस्त को report किया गया, 5 अक्टूबर को $1337 reward दिया गया, और 16 दिसंबर को 134 दिनों बाद public किया गया, लेकिन disclosure के समय तक Google की mitigation changes deploy नहीं हुई थीं

Vulnerability disclosure और timeline

  • Google OAuth vulnerability के कारण कंपनी से offboarding होकर Google organization से हटाए गए कर्मचारी Slack·Zoom जैसे applications तक अनिश्चित समय तक access बनाए रख सकते हैं
  • Disclosure के समय तक Google ने इस जोखिम को mitigate करने वाला change deploy नहीं किया था
  • Timeline इस प्रकार है
    • 4 अगस्त: Google को report किया और बताया कि सैकड़ों applications प्रभावित हो सकते हैं
    • 7 अगस्त: issue triage हुआ
    • 5 अक्टूबर: Google ने issue के लिए $1337 भुगतान किया
    • 25 नवंबर: Zoom·Slack सहित प्रभावित दर्जनों applications को private bulk report भेजी गई
    • 16 दिसंबर: Google को notify करने के 134 दिन बाद public disclosure

Identifier के रूप में email claim इस्तेमाल करने का जोखिम

  • Truffle Security का Forager login पहले Descope की Microsoft OAuth vulnerability से प्रभावित हुआ था
  • उस समय यह पुष्टि हुई कि Microsoft द्वारा सीधे create या verify न किया गया Email claim भेजा जा सकता है, और email claim आम तौर पर भरोसेमंद identifier नहीं होता
  • Google की OIDC documentation भी Email को primary identifier के रूप में इस्तेमाल न करने की चेतावनी देती है
  • email_verified claim को भी एक असामान्य बिंदु के रूप में देखा गया, लेकिन unverified email से email claim create करने का तरीका confirm नहीं हुआ
  • हालांकि email claim का दुरुपयोग करने के पर्याप्त मामले confirm हुए

गैर-Gmail Google accounts और duplicate email claim

  • Google account Gmail address के बिना भी किसी existing email address से बनाया जा सकता है
    • उदाहरण के लिए Yahoo email address से Google account बनाया जा सकता है
    • यह account गैर-Gmail email set होने की स्थिति में उस email का email claim भेज सकता है
  • Google documentation email को primary identifier के रूप में इस्तेमाल न करने को इसलिए भी कहती है क्योंकि दो अलग-अलग Google accounts एक ही email claim भेज सकते हैं
    • settings में गैर-Gmail email बदलने के बाद
    • बदलाव से पहले वाले email से नया account बनाने पर वही email claim संभव हो जाता है

कंपनी Google organization के बाहर बचा रहने वाला account

  • मुख्य loophole यह है कि कंपनी Google organization email के लिए email alias और plus-address forwarding का उपयोग कर organization के बाहर Google account बनाया जा सकता है
  • कंपनी email का plus address मूल user के inbox में forward हो सकता है
  • इस flow से कंपनी Google organization email इस्तेमाल करने वाला plus-address based गैर-Gmail Google account बनाया जा सकता है, और इस account को organization से delete या offboard नहीं किया जा सकता
  • कई services इस email को parse करने के बाद अंत के domain के आधार पर login eligibility तय करती हैं
    • इस account से Zoom पर sign up किया जा सकता है
    • इस account से Slack पर sign up किया जा सकता है
  • ऐसे गैर-Gmail Google accounts असल Google organization members नहीं होते, इसलिए admin settings या user Google list में दिखाई नहीं देते

Organizations, service providers और Google के mitigation measures

  • Organizations Google login disable करके SAML को सख्ती से enforce करें तो mitigation संभव है
    • अधिकांश service providers में यह तरीका काम करता है
    • कुछ services यह option नहीं देतीं
    • Internal development applications प्रभावित हो सकते हैं लेकिन SAML support नहीं करते हों
  • Service providers Google OAuth के HD claim का उपयोग कर सकते हैं
    • HD claim उस Google organization का domain भेजता है जिससे account जुड़ा है
    • जो accounts Google organization members नहीं हैं, उनमें HD claim शामिल नहीं होता
    • test किए गए अधिकांश service providers ने HD के बजाय email claim का उपयोग किया
  • HD claim में महत्वपूर्ण limitations बची रहती हैं
    • HD unique identifier नहीं, सिर्फ domain है
    • अगर Google organization delete हो जाए और domain छोड़ दिया जाए, तो कोई दूसरा व्यक्ति उस domain को हासिल कर नया Google organization बना सकता है
    • उदाहरण के लिए company A को company B acquire करे, B A की services बंद करे और पुराने domain को renew न करे
    • internet पर कोई व्यक्ति company A का domain खरीद ले तो company A के existing service accounts में login कर सकता है
  • Service providers JIT account creation को general feature के रूप में allow न करके invite-only या LDAP group based account provisioning में switch कर सकते हैं
  • Google मौजूदा Google organization domains से बने Google accounts को ban करके व्यापक mitigation कर सकता है
    • Google खुद google.com accounts को ban करता है
    • वही protection अन्य organizations तक भी expand की जा सकती है
  • Google-side के अन्य mitigation उपायों में plus-address Google account sign-up ban करना, Google email alias sign-up ban करना, और organizations को related settings configure करने के लिए बेहतर admin settings देना शामिल है

अतिरिक्त प्रभाव: support email और magic link flows

  • Initial access अधिकार न होने पर भी किसी organization के Zoom·Slack तक पहुंचना technically संभव हो सकता है
  • यह flow दूसरे researchers द्वारा magic link sign-in flows में मिली vulnerability research का उपयोग करता है
  • Zendesk जैसे कुछ support·ticket systems email से support ticket बना सकते हैं
    • support ticket email address से Google account बनाया जा सकता है
    • ticket contents देखकर account creation पूरा करने की संभावना हो सकती है
    • इसके बाद उस support email address से OAuth login attempt किया जा सकता है
  • Main domain पर email to support feature बनाए रखना सुरक्षित नहीं है, और Zendesk support email को alternate email address के रूप में configure करने का विकल्प है

Disclosure का उद्देश्य और बची हुई समस्याएं

  • Slack·Zoom जैसे platforms पर पूर्व कर्मचारियों द्वारा access बनाए रखने की समस्या Google OAuth system के loophole से उत्पन्न होती है
  • Google के पास इस समस्या को mitigate करने के लिए व्यापक fixes करने की क्षमता है
  • Disclosure का उद्देश्य मामूली documentation change से आगे बढ़कर वास्तविक changes करवाना है
  • Google ने issue triage जल्दी किया, लेकिन अपनी 90-day improvement practice के विपरीत 134वें दिन समस्या public हुई

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

1 टिप्पणियां

 
GN⁺ 2023-12-22
Hacker News की रायें

  • मैं इसी क्षेत्र में काम करता हूँ, और पिछले 3–4 सालों में कई login providers और SaaS कंपनियों में इस vulnerability के variants से 20 से ज़्यादा बार निपटा हूँ। ब्लॉग पोस्ट सही है, लेकिन मुझे लगता है कि मूल समस्या अब ठीक करने के लिए बहुत आगे निकल चुकी है। पूरे इंटरनेट पर delegated authentication पूरी तरह अव्यवस्थित है, और मैंने Google व Microsoft engineers से भी इस बारे में काफी बात की है, इसलिए मुझे भरोसा है कि वे इस समस्या-समूह को पहले से जानते हैं। बस, अगर वे अभी व्यवहार बदलते हैं तो बहुत सारी मौजूदा services और दशकों पुराने enterprise login implementations टूट जाएँगे
    इस समय “fix” सरल है। अगर आपकी साइट “Sign in with XYZ” इस्तेमाल करती है, तो provider द्वारा भेजे गए email address पर भरोसा नहीं करना चाहिए। सिर्फ email domain देखकर special permissions न दें, और database में verified के रूप में mark करने से पहले हमेशा अपना verification email भेजें। बड़े OAuth providers ने भी अपने docs में इसे साफ़ तौर पर लिखने के लिए updates किए हैं, और यह लेख भी उसी बात को इंगित करता है। इसलिए reward मिला, यह अपने-आप में बल्कि हैरानी की बात है

    • यह ऐसा लगता है जैसे organizations ने ठीक से समझा ही नहीं कि यह क्षेत्र असल में कितना जटिल है। कई कंपनियों में OAuth2 + OIDC को अपनाते हुए देखें तो इसे security-first दृष्टिकोण से नहीं, बल्कि हमेशा “x से login” जैसी feature के रूप में बेचा गया। PKCE जैसे उपायों से flow को ज्यादा सुरक्षित बनाने की कोशिश करें तो भी cookie sharing या redirect handling जैसी चीज़ों में अलग-अलग platforms गड़बड़ करते रहते हैं, और यह whack-a-mole बन जाता है। 3-legged OAuth2 की बुनियाद मजबूत है और CAS जैसे कई precedents भी हैं, लेकिन OIDC को जिस तरह market और sell किया गया, उसके लिए OpenID Foundation की कड़ी आलोचना होनी चाहिए
    • “सिर्फ email domain देखकर special permissions न दें, और database में verified के रूप में mark करने से पहले हमेशा अपना verification email भेजें” वाला तरीका fail नहीं होगा क्या, अगर user ने Google में plus address से account register किया और निकाले जाने से पहले उसी Google account से service में login कर लिया? जब तक हर login पर verification email नहीं भेजते
    • इस खास मामले में attacker सच में verification email प्राप्त कर सकता है, तो समझ नहीं आता कि उस verification process का मतलब क्या है
    • “database में verified के रूप में mark करने से पहले हमेशा अपना verification email भेजें” user के नज़रिए से x से login feature को बेकार बना देता है
    • क्या Google Apps customer के domain का उपयोग करके signup को Google रोक नहीं सकता था? उससे कुछ टूटेगा, ऐसा खास नहीं लगता

  • इससे जुड़ी बात: और ज्यादा service providers को Google docs की recommendation की तरह email को primary identifier के रूप में इस्तेमाल करना बंद करना चाहिए। Google Apps में username बदलने पर Slack, Datadog, GoLinks आदि में issues संभालने में काफी समय लगा

    • Providers को क्या इस्तेमाल करना चाहिए? मैं हमेशा सोचता था कि email user के लिए सबसे स्थिर global identifier है, लेकिन लगता है यह assumption गलत है
    • सहमत होना मुश्किल है। ऐसी guidelines बस जिम्मेदारी application developers पर डाल देती हैं, और ज्यादातर या तो कुछ नहीं करेंगे या अपनी-अपनी तरह implement करेंगे
      यहाँ सही दिशा ऐसी API देना है जो इस्तेमाल करने वाली application की जरूरतों के मुताबिक हो और अतिरिक्त जिम्मेदारी को न्यूनतम रखे। इस मामले में मुझे लगता है कि Google को email_verified को false set करना चाहिए था, ताकि application या downstream IdP को पता चल सके कि additional verification की जरूरत है

  • अगर user@domain पहले से ही Google mail servers द्वारा handle हो रहा है और इसलिए plus routing rules लागू होते हैं, तो समझ नहीं आता कि user+suffix@domain जैसे email से नया Google account क्यों बनाया जा सकता है। दुरुपयोग न भी हो, तो भी यह भ्रमित करने वाली mail setup बनाने के लिए बिल्कुल उपयुक्त लगता है

    • Domains अपने mail servers को स्वतंत्र रूप से कहीं भी move कर सकते हैं। Google a+b@domain.com को एक खास तरीके से handle करता है, लेकिन कोई दूसरा server जरूरी नहीं कि ऐसा करे। अंततः दोनों अलग-अलग unique email addresses हैं, और पूरे इंटरनेट पर भी उन्हें वैसे ही treat किया जाना चाहिए
    • यह alias feature अपनी औकात से ज्यादा complex हो गया लगता है। खासकर Google के scale पर तो और भी
    • यह user+suffix@domain से भी खराब है। कम से कम +XYZ email RFC में explicitly लिखा है। Google इससे आगे जाकर नाम के अंदर के dots को भी normal email मानता है। उदाहरण के लिए hi.my.name@google.com, himyname@google.com के समान है, और सारी mail बाद वाले पर route होती है
    • ऐसा इसलिए है क्योंकि Google का authentication system बहुत पुराना legacy है। “Google account” बस एक string है

  • “मुझे यह जानकर हैरानी हुई कि Microsoft ऐसे email claims भेजता है जिन्हें Microsoft ने बनाया या verify नहीं किया, और आम तौर पर email claims को भरोसेमंद नहीं माना जाता” वाले हिस्से पर: भले ही मूल इरादा वही रहा हो, मुझे लगता है कि OIDC का अधिक flexible होना बहुत उपयोगी है। उदाहरण के लिए, मैं एक free login provider[0] चलाता हूं, जो upstream OIDC या direct email के जरिए चौथी party identity provider (IdP) से identity verify करता है, और app तथा उस IdP के बीच privacy barrier बनाता है। यानी Google यह track नहीं कर पाता कि user किन-किन apps में login कर रहा है
    Google में अपनी email लाने की क्षमता का मतलब है कि आपको email+password की privacy के साथ Google OIDC की security और user experience मिल सकता है, लेकिन बड़ी caveat यह है कि अब आपको Google की जगह LastLogin पर भरोसा करना होगा। उस dependency को कम करने वाले protocol पर भी काम चल रहा है। “Google docs ने दरअसल email को identifier के तौर पर इस्तेमाल न करने की चेतावनी दी थी” वाले हिस्से से मैं पूरी तरह असहमत हूं। Email ही एकमात्र वास्तविक federated identity है जिसे लोग सच में इस्तेमाल करते हैं। जब तक कोई बेहतर विकल्प व्यापक रूप से deploy नहीं हो जाता, मेरा मानना है कि email address को identity के तौर पर treat करना चाहिए
    [0]: https://lastlogin.io

    • “email address को identity के तौर पर treat करना चाहिए” से असहमति है। इसके दो कारण हैं
      पश्चिमी देशों के बाहर computer की तुलना में mobile phone ज्यादा आम हैं और UI भी आम तौर पर आसान होता है, इसलिए phone number के identity होने की संभावना ज्यादा है। इसके अलावा, ऐसा करने पर आप identity को पूरी तरह email provider के हवाले कर देते हैं। Google जैसी बेचेहरा संस्था बिना warning या appeal process के access block कर सकती है, और वास्तव में करती भी है, इसलिए आप सब कुछ खो सकते हैं। संदर्भ के लिए: मैंने Okta के OAuth और OIDC products launch किए, LinkedIn का संबंधित course बनाया, और अब Pangea Cyber में फिर वही कर रहा हूं
    • “email address को identity के तौर पर treat करना चाहिए”—क्या assumption यह है कि कोई भी email address share नहीं करता और email बहुत secure है?
      आप हमेशा इंतजार भी कर सकते हैं, या फिर solution बनाना शुरू कर सकते हैं
    • अपने system के अंदर email identifier और linked Google account के identifier के तौर पर email में महत्वपूर्ण फर्क है। आपके control वाले system के भीतर email identity के रूप में ठीक-ठाक काम करता है, इससे मैं सहमत हूं, लेकिन external system से link करते समय यह Google के कहे मुताबिक बहुत खराब तरीका है। यह temporary है, कई accounts से जुड़ सकता है, और जब इस्तेमाल करने लायक वास्तविक ID मौजूद है तो इसे इस्तेमाल करने की कोई वजह नहीं है
    • LastLogin और Dex की तुलना मिल जाए तो बहुत अच्छा होगा। दोनों Go में हैं, इसलिए खास तौर पर उत्सुकता है। यह भी जानना चाहूंगा कि आपने Dex evaluate किया था या नहीं
      Portier और पुराने Mozilla Persona के साथ भी थोड़ा काम किया था, लेकिन अंत में email normalization problem से निपटना हारती हुई लड़ाई या बहुत कठिन लड़ाई जैसा लगा। लगभग मान लिया था कि कोई अच्छा solution pioneer होने से पहले ही यह मर जाएगा, और ध्यान कहीं और लगा दिया

  • क्या यह सचमुच Google OAuth की समस्या है, या फिर कई service providers की यह failure है कि उन्होंने access देने से पहले OAuth token के claims को ठीक से verify नहीं किया? मुझे दूसरा वाला मामला लगता है

    • समस्या यह लगती है कि ये service providers Google के alias rules तो follow करते हैं, लेकिन इस बात को ignore करते हैं कि email को primary identifier के तौर पर नहीं इस्तेमाल करना चाहिए [1]। दिलचस्प बात यह है कि अगर उन्होंने spec को बेहतर तरीके से follow किया होता तो सब ठीक रहता, और उल्टा अगर spec को कम follow करके aliases को अलग-अलग emails माना होता, तब भी कम से कम ज्यादा safe रहता
      [1] https://developers.google.com/identity/openid-connect/openid...
    • मेरे हिसाब से OAuth expected तरीके से काम कर रहा है। user@domain और user+wildcard@domain अब भी ऐसे email addresses के रूप में verify होते हैं जिन्हें user “own” करता है, इसलिए वे उस email address के लिए valid authentication और identity देते हैं
      समस्या Google organization website की तरफ है। Admin उन accounts या emails के credentials revoke नहीं कर सकता जिन्हें वह देख नहीं सकता। “ये non-Gmail Google accounts वास्तव में Google organization के members नहीं हैं, इसलिए admin settings या Google user list में दिखाई नहीं देते” वाला हिस्सा मुख्य है

  • इस flow को follow करें तो कोई support ticket email address से Google account बना सकता है, ticket content को संभावित रूप से देखकर account creation complete कर सकता है, और फिर उसी support email address से कई services में OAuth login कर सकता है। इससे कई छोटी कंपनियां प्रभावित हो सकती हैं

  • यहां से मेरा सबसे बड़ा निष्कर्ष यह है कि web authentication अब भी भयानक mess है

    • क्योंकि लोग docs नहीं पढ़ते, और बस assume कर लेते हैं कि यह उसी तरह काम करेगा जैसा वे सोचते हैं
    • अगर आप पूछें कि समझदार और practical लोग अब भी simple password authentication क्यों इस्तेमाल और demand करते हैं, तो जवाब है: passwords ठीक से काम करते हैं

  • OIDC spec कहता है कि email को unique identifier के तौर पर इस्तेमाल नहीं करना चाहिए। Application के username के लिए iss और sub fields इस्तेमाल करने चाहिए
    वजह सबसे पहले यह स्पष्ट है कि user email address reuse हो सकते हैं। अगर कोई contractor Business A और Business B दोनों के लिए काम करता है, और दोनों ने authentication service में उस व्यक्ति का user account बनाया है, तो SaaS platform की नजर में एक email address को किसी एक B2B customer से match नहीं किया जा सकता। दूसरी बात, email addresses बदलते हैं। कंपनियां acquire होती हैं, नाम बदलती हैं, merge होती हैं, और लोगों के नाम भी शादी, divorce या personal choice से बदलते हैं। Startup में SSO implement करना शुरुआत में सचमुच कठिन था। इसे सही करना मुश्किल है, और use करने से पहले general concepts, OIDC और OAuth2 को अच्छी तरह समझना जरूरी है। Auth0 के पास इस पर अच्छी किताब है। अगर आप इसे नहीं समझते, तो जगह-जगह password grant authentication implement करके application को insecure बनाने की संभावना ज्यादा है

    • इस तरह की posts पढ़कर कभी-कभी जमा हुआ impostor syndrome थोड़ा कम हो जाता है। मन में आता है, “अगर किसी abstract actor को represent करने वाली चीज़ के लिए third-party system से integrate कर रहे हैं, तो एक stable, string-जैसा न होकर भरोसेमंद identifier होना चाहिए।” असल में spec भी इस हिस्से पर बहुत clear है, और यह थोड़ा भी robust system बनाते समय basic considerations से आगे की बात है

  • किसी छोटे thumbnail जैसा। OAuth2 नाम की चीज़ असल में मौजूद ही नहीं है। OAuth2 बस बड़ी कंपनियों के लिए अपने-अपने मनमाने और proprietary authentication systems लागू करने का तरीका है। यह authentication system नहीं, बल्कि authentication system बनाने के लिए एक toolbox है। इसलिए OAuth2 को standard बनना था, लेकिन असल में दुनिया ऐसी बन गई जहाँ हर बड़ी कंपनी की अपनी, आपस में incompatible implementation है। बेशक लोग बड़ी कंपनियों के use cases के हिसाब से develop करेंगे, लेकिन तब “standard” आखिरकार Google जिस तरह करता है, वैसा कुछ बन जाता है
    और हर किसी के पास ऐसे छोटे-छोटे bugs हैं। हमें OAuth1 पर लौटना चाहिए। वह सचमुच standard था, standard बनाने के लिए toolbox नहीं

    • यह bug से ज़्यादा उन खास components के मिलने से पैदा हुआ एक दुर्भाग्यपूर्ण side effect है। Domain names जिनकी ownership बदल सकती है, अपना email लाना, backup email और email origin, plus aliases को उदारता से allow करना, और documentation न पढ़ने वाले service implementers—इन सबका नतीजा है। Implementers ने शायद किसी video या संक्षिप्तता के लिए छोड़े गए example से solution copy किया होगा
      अगर आपको कुछ PCB components से circuit design करना हो और voltage/current requirements के हिसाब से resistors और transistors लगाने हों, तो क्या यह उम्मीद नहीं की जानी चाहिए कि आप datasheet पढ़ेंगे? किसी सरल example से अंदाज़ा लगाकर आगे बढ़ें तो कई मामलों में circuit चल भी सकता है, और थोड़ा bench testing व probing करने पर काम कर सकता है। लेकिन efficiency कम हो सकती है, या components short हो सकते हैं, जिससे mean time to failure घटेगा और customers नाखुश होंगे। सबसे खराब स्थिति में battery में आग लग सकती है और असली नुकसान हो सकता है। तब device का जल्दी fail होना PCB module manufacturer की गलती है, या उस device manufacturer की जिम्मेदारी जिसने datasheet पढ़नी चाहिए थी? हम पूरे software से इतनी सख्त अपेक्षा नहीं रखते, लेकिन अगर आप authentication और authorization संभाल रहे हैं, तो service owner को बेहद thorough होना चाहिए। मूल लेख भी कहता है कि documentation follow करने पर समस्या मौजूद नहीं रहती। Alphabet ने bug bounty देकर कमजोरी को स्वीकार किया है, इसलिए वह company admins को plus aliases या non-existent roles को allow/deny list से manage करने का control दे सकता है, या Apps से जुड़े emails के organization के बाहर claims में transfer को restrict कर सकता है। शायद वे इसका impact measure कर रहे हैं या measurement की priority तय कर रहे हैं, लेकिन क्योंकि यह client-side समस्या है जहाँ email claim को असल से ज़्यादा authoritative और permanent माना जाता है, priority शायद कम होगी। “bug” की definition काफी हद तक इस पर निर्भर करती है कि “expected behavior” को कैसे और कौन define करता है, लेकिन कम से कम यह intended behavior से हटकर नहीं है, और documentation ठीक से समझने वालों के लिए unexpected भी नहीं है
    • हम्म... मान लेते हैं। Providers के बीच compatibility का Google OAuth2 security पर इस लेख से क्या संबंध है?

  • क्या मैं कुछ miss कर रहा हूँ? लेख में बताए गए support system/Zendesk और छोड़े गए पुराने domain वाले तरीके के अलावा, whatever@mydomain.com से नया Google account बनाते समय verification माँगी जाती है। तो असल में इसका abuse कितना possible है?

    • मुख्य बात यह है कि जब आपके पास legitimate access हो, तब पहले से setup कर लें, और बाद में वह access खो दें
      उदाहरण के लिए मान लें कि egamirorrim@mydomain.com Google account legitimately मौजूद है। आप egamirorrim+woopsie@mydomain.com जैसे alias से verified email address वाला नया Google account बना सकते हैं, और फिर “Google से login” पर Google egamirorrim+woopsie@mydomain.com वाला email claim भेजेगा। बाद में अगर आपको mydomain.com से निकाल दिया जाता है, तो असली egamirorrim@mydomain.com से जुड़ा account अब login नहीं कर पाएगा क्योंकि admin ने उसे deactivate कर दिया है। लेकिन नया Google account egamirorrim+woopsie@mydomain.com organization से जुड़ा नहीं है, इसलिए वह login कर सकता है। हालांकि मेरी नज़र में यह समस्या तभी बनती है जब provider सिर्फ email claim के आधार पर authorization करता है। मैंने पहले OIDC इस्तेमाल किया है, और email address claim के text को parse करके resource access grant नहीं करना चाहिए। मैं समझता हूँ कि लेखक को यह counterintuitive क्यों लगा, लेकिन लेख में भी लिखा है कि documentation ऐसा न करने की warning देती है। मूल लेख में है कि “मेरे द्वारा test किए गए अधिकांश service providers ने HD नहीं, email claim इस्तेमाल किया”; ठीक है, लेकिन वे उसे किस चीज़ के लिए “use” करते हैं? क्या यह trick किसी वास्तविक production service में काम करती है? अगर हाँ, तो नाम सार्वजनिक किए जाने चाहिए ताकि उनकी आलोचना हो। भले ही कोई इस value को unique और immutable मानने की गलती करे, सिर्फ उससे अपने-आप कोई access right मिलना जरूरी नहीं है