Google, Google Sync और सिर्फ पासवर्ड वाले ऐप्स का सपोर्ट बंद करेगा

 (workspaceupdates.googleblog.com)
1 पॉइंट द्वारा GN⁺ 2024-01-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google Workspace, केवल यूज़रनेम और पासवर्ड साझा करके लॉगिन करने वाले Less Secure Apps(LSA) तरीके को बंद कर रहा है, और ईमेल, कैलेंडर व कॉन्टैक्ट्स सिंक के लिए OAuth-आधारित लॉगिन अनिवार्य कर रहा है
  • बंद करने का शेड्यूल 15 जून 2024 और 30 सितंबर 2024 के दो चरणों में शुरू हुआ था, लेकिन रोलआउट रोके जाने और फिर शुरू होने के बाद 1 मई 2025 से LSA अब समर्थित नहीं रहेगा
  • केवल पासवर्ड का इस्तेमाल करने वाले CalDAV, CardDAV, IMAP, SMTP, POP कनेक्शन और Google Sync प्रभावित होंगे, और नए व मौजूदा Google Sync यूज़र—दोनों को माइग्रेशन करना होगा
  • एडमिन को प्रभावित यूज़र्स के साथ OAuth पर स्विच करने के निर्देश साझा करने होंगे, और MDM से डिप्लॉय किए जा रहे पासवर्ड-आधारित प्रोफाइल को भी Google Account को OAuth के साथ फिर से जोड़ने के तरीके में बदलना होगा
  • बंद होने की तारीख तक कार्रवाई न करने वाले यूज़र यूज़रनेम-पासवर्ड कॉम्बिनेशन त्रुटि के कारण लॉगिन नहीं कर पाएंगे, और डेवलपर्स को Workspace संगतता के लिए ऐप कनेक्शन तरीके को OAuth 2.0 में अपडेट करना होगा

सिर्फ पासवर्ड वाले लॉगिन तरीके का अंत

  • Google Workspace अब उन लॉगिन तरीकों का समर्थन नहीं करेगा जिनमें थर्ड-पार्टी ऐप या डिवाइस सीधे Google यूज़रनेम और पासवर्ड मांगते हैं
  • इस तरीके को Less Secure Apps(LSA) कहा जाता है, और इसमें Google खाते के क्रेडेंशियल थर्ड-पार्टी ऐप्स और डिवाइसों के साथ साझा करने पड़ते हैं, जिससे खाते में अनधिकृत एक्सेस का जोखिम बढ़ता है
  • इसका विकल्प Sign in with Google है, जो OAuth का उपयोग करता है—यह अधिकांश थर्ड-पार्टी ऐप्स और डिवाइसों में पहले से इस्तेमाल होने वाला इंडस्ट्री-स्टैंडर्ड ऑथेंटिकेशन तरीका है
  • Google ने इस बदलाव की घोषणा 2019 में की थी, और बाद में लागू करने का शेड्यूल फिर से प्रकाशित किया

बंद करने का शेड्यूल और स्थगन का इतिहास

  • LSA एक्सेस खत्म करने की योजना मूल रूप से दो चरणों में थी
    • 15 जून 2024 से Admin Console की LSA सेटिंग हटा दी गई, इसलिए इसे अब बदला नहीं जा सकता
    • जिन यूज़र्स के लिए यह पहले से सक्रिय था वे कनेक्ट रह सकते थे, लेकिन निष्क्रिय यूज़र्स LSA एक्सेस नहीं कर सकते थे
    • इसमें Gmail, Google Calendar, Contacts को केवल पासवर्ड से एक्सेस करने वाले CalDAV, CardDAV, IMAP, SMTP, POP-आधारित थर्ड-पार्टी ऐप्स शामिल थे
    • यूज़र की Gmail सेटिंग्स से IMAP को सक्षम/अक्षम करने की सेटिंग भी हटा दी गई
    • इस तारीख से पहले से LSA इस्तेमाल कर रहे यूज़र्स मूल योजना के अनुसार 30 सितंबर 2024 तक इसका उपयोग जारी रख सकते थे
  • 30 सितंबर 2024 से सभी Google Workspace खातों में LSA एक्सेस बंद करने का शेड्यूल था
    • CalDAV, CardDAV, IMAP, POP, Google Sync केवल पासवर्ड से लॉगिन करने पर अब काम नहीं करते
    • उपयोग जारी रखने के लिए अधिक सुरक्षित एक्सेस तरीके, यानी OAuth से लॉगिन करना होगा
  • इसके बाद शेड्यूल कई बार बदला गया
    • 15 अक्टूबर 2024 के अपडेट में रोलआउट साल के अंत तक रोक दिया गया, और इसे जनवरी 2025 में फिर शुरू करने की योजना बनी
    • 27 जनवरी 2025 के अपडेट में रोलआउट फिर शुरू हुआ, और अंतिम निष्क्रियता मार्च 2025 के लिए तय की गई
    • 12 फरवरी 2025 के अपडेट में LSA सपोर्ट समाप्ति की तारीख 14 मार्च 2025 कर दी गई
    • 29 अप्रैल 2025 के अपडेट में बताया गया कि LSA 1 मई 2025 से अब समर्थित नहीं रहेगा

Google Sync इस्तेमाल करने वाले संगठनों के लिए जाँच बिंदु

  • इस बदलाव में Google Sync का बंद होना भी शामिल है
  • Google Sync बंद करने का मूल शेड्यूल इस प्रकार था
    • 15 जून 2024 से नए यूज़र Google Sync के जरिए Google Workspace से कनेक्ट नहीं कर सकते
    • 30 सितंबर 2024 से मौजूदा Google Sync यूज़र भी Google Workspace से कनेक्ट नहीं कर सकते
  • संगठन में Google Sync उपयोग की स्थिति Admin Console में जाँची जा सकती है
    • पाथ: Devices > Mobile & Endpoints > Devices
    • फिल्टर: Type: Google Sync

एडमिन और MDM कॉन्फ़िगरेशन पर असर

  • एडमिन को अंतिम यूज़र्स को यह निर्देश देना होगा कि अगर वे Google Workspace खाते के साथ ऐप्स का उपयोग जारी रखना चाहते हैं, तो OAuth-आधारित एक्सेस तरीके पर स्विच करें
  • प्रभावित यूज़र्स की जानकारी आने वाले कुछ महीनों में संगठनों को ईमेल से दी जाएगी
  • MDM प्रोवाइडर के जरिए IMAP, CalDAV, CardDAV, POP, Exchange ActiveSync(Google Sync) प्रोफाइल कॉन्फ़िगर करने वाले संगठन भी प्रभावित होंगे
    • 15 जून 2024 से पासवर्ड-आधारित IMAP, CalDAV, CardDAV, SMTP, POP, Exchange ActiveSync(Google Sync) के MDM push उन ग्राहकों के लिए काम नहीं करेंगे जो पहली बार LSA से कनेक्ट करने की कोशिश कर रहे हैं
    • Google Endpoint Management का उपयोग करने पर CalDAV और CardDAV के लिए Custom Push Configuration सेटिंग चालू नहीं की जा सकती
    • 30 सितंबर 2024 से मौजूदा यूज़र्स के लिए पासवर्ड-आधारित IMAP, CalDAV, CardDAV, SMTP, POP push काम नहीं करेंगे
    • एडमिन को MDM प्रोवाइडर का उपयोग करके Google Account push करना होगा, और यह तरीका iOS डिवाइसों में Google खाते को OAuth के साथ फिर से जोड़ता है
    • पासवर्ड-आधारित Exchange ActiveSync(Google Sync) push भी मौजूदा यूज़र्स के लिए काम नहीं करेगा
    • Google Endpoint Management की “Custom push configuration-CalDAV” और “Customer push configuration-CardDAV” सेटिंग्स प्रभावी नहीं रहेंगी

डिवाइस, ऐप और डेवलपर के हिसाब से माइग्रेशन तरीका

  • अगर स्कैनर या कोई अन्य डिवाइस SMTP या LSA के जरिए ईमेल भेजता है, तो निम्न में से एक आवश्यक होगा
    • OAuth उपयोग के लिए कॉन्फ़िगर करना
    • वैकल्पिक तरीका इस्तेमाल करना
    • उस डिवाइस के लिए ऐप पासवर्ड कॉन्फ़िगर करना
  • जो ऐप्स केवल यूज़रनेम और पासवर्ड से Google खाते तक पहुंचते हैं, उन्हें माइग्रेशन कार्रवाई करनी होगी
    • बंद होने की तारीख तक कार्रवाई न करने पर यूज़रनेम-पासवर्ड कॉम्बिनेशन गलत होने की त्रुटि दिखेगी और लॉगिन नहीं हो पाएगा
  • ईमेल ऐप के हिसाब से कदम
    • Outlook 2016 या उससे पुराने वर्ज़न को Microsoft 365, Outlook for Windows, Outlook for Mac पर जाना होगा, क्योंकि ये OAuth एक्सेस का समर्थन करते हैं
    • विकल्प के तौर पर Google Workspace Sync for Microsoft Outlook का उपयोग किया जा सकता है
    • Thunderbird या अन्य ईमेल क्लाइंट में Google खाते को फिर से जोड़कर IMAP को OAuth के साथ कॉन्फ़िगर करना होगा
    • iOS या macOS Mail ऐप, Outlook for Mac में अगर आप केवल पासवर्ड से लॉगिन कर रहे हैं, तो खाते को हटाकर फिर से जोड़ना होगा और “Sign in with Google” चुनना होगा
  • कैलेंडर और कॉन्टैक्ट्स ऐप्स को भी OAuth समर्थित तरीके पर स्विच करना होगा
    • पासवर्ड-आधारित CalDAV कैलेंडर ऐप्स को OAuth समर्थित तरीके में बदलना होगा, और Google, Google Calendar ऐप की सिफारिश करता है
    • iOS या macOS कैलेंडर ऐप में अगर आप केवल पासवर्ड से लॉगिन कर रहे हैं, तो खाते को हटाकर फिर से जोड़ना होगा और “Sign in with Google” चुनना होगा
    • iOS या macOS पर CardDAV से कॉन्टैक्ट्स सिंक कर रहे हैं और केवल पासवर्ड से लॉगिन कर रहे हैं, तो खाते को हटाकर फिर से जोड़ना होगा और “Sign in with Google” चुनना होगा
    • दूसरे प्लेटफॉर्म या ऐप में CardDAV और केवल पासवर्ड का उपयोग करने पर OAuth समर्थित तरीके पर स्विच करना होगा
  • OAuth का समर्थन नहीं करने वाले ऐप्स को OAuth उपलब्ध कराने वाले ऐप्स से बदलना होगा या ऐप पासवर्ड बनाकर एक्सेस करना होगा
  • डेवलपर्स को Google Workspace खातों के साथ संगतता बनाए रखने के लिए ऐप कनेक्शन तरीके को OAuth 2.0 में अपडेट करना होगा

व्यक्तिगत Google खाते और लागू दायरा

  • व्यक्तिगत Google खाते के यूज़र्स के लिए Gmail सेटिंग्स में IMAP सक्षम/अक्षम टॉगल हटाया जाएगा
  • व्यक्तिगत खातों में IMAP एक्सेस OAuth के जरिए हमेशा सक्षम रहता है, और मौजूदा कनेक्शन प्रभावित नहीं होंगे
  • व्यक्तिगत Google खाते के यूज़र्स को अलग से कोई कार्रवाई करने की जरूरत नहीं है
  • यह बदलाव सभी Google Workspace ग्राहकों पर लागू होगा

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

1 टिप्पणियां

 
GN⁺ 2024-01-20
Hacker News की राय

  • यह पढ़कर एक पल के लिए दिल बैठ गया — क्योंकि Gmail से जुड़े कई scripts और tools हैं
    फिर भी सब ठीक लगता है। App Passwords अभी भी काम करते दिख रहे हैं, और यह बदलाव खाते के सामान्य username/password का उपयोग करने वाले Less Secure Apps सपोर्ट को हटाने के ज़्यादा करीब है
    बस यह सोचकर ही घबराहट होती है कि अगर Google, OAuth के अलावा बाकी सब सचमुच हटा दे, तो कितनी automation टूट जाएगी
    OAuth की जटिलता पसंद नहीं है, और इस Perl module documentation ने उसकी संरचना को जिस तरह समझाया है, वह अच्छा लगा। साफ़ दिखता है कि यह किसी ऐसे व्यक्ति ने लिखा है जो मेरी तरह इससे परेशान था: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP-Aut...

    • scripts को migrate करना बहुत मुश्किल नहीं होना चाहिए
      मुझे भी ऐसा ही मसला आया था, और एक Workspace में app passwords बंद थे। एक छोटा Python script लेकर OAuth token हासिल करें और उसे password की तरह इस्तेमाल करें: https://github.com/google/gmail-oauth2-tools/blob/master/pyt...
      उदाहरण के लिए https://github.com/lefcha/imapfilter/issues/186 देखें
    • अच्छा होगा अगर Gmail खुद client के रूप में Less Secure App न माना जाए
      अभी मुझे LSA switch चालू रखना पड़ता है ताकि मेरा मुख्य Gmail account दूसरे कई Gmail accounts की credentials के साथ SMTP भेज सके। समझ नहीं आता कि दूसरे Gmail accounts की नज़र में Gmail खुद LSA क्यों है
    • समस्या यह है कि app passwords को सीधे सेट नहीं किया जा सकता, और उनकी security भी लगभग मज़ाक जैसी कमज़ोर लगती है
      वे 16 lowercase characters के होते हैं, 4-4 के समूह में space से अलग, और उनमें न numbers होते हैं न special characters
      Keepass, spaces हटाने पर, इसे 65-bit entropy वाले कमजोर password के रूप में आँकता है
      समझ नहीं आता कि यह सुधार कैसे है
    • https://github.com/smallstep/cli command line पर कुछ OAuth flows लागू करता है, इसलिए यह मददगार हो सकता है

  • अगर OAuth पर migrate नहीं कर सकते, तो मेरा proxy इस्तेमाल करें; इससे ऐसे IMAP/POP/SMTP clients भी “modern” email providers के साथ चल सकते हैं जो OAuth 2.0 को सीधे support नहीं करते: https://github.com/simonrob/email-oauth2-proxy
    client को OAuth के बारे में कुछ भी जानने की ज़रूरत नहीं है

    • जमा किया गया शीर्षक भ्रामक है। असल में यह “केवल OAuth की अनुमति” नहीं, बल्कि OAuth और app passwords दोनों की अनुमति है
      अगर OAuth पर migrate नहीं कर सकते, तो app password बनाइए और उसे हमेशा की तरह IMAP password के रूप में इस्तेमाल करते रहिए
    • शानदार। इस तरीके से mu/mu4e जैसे clients को Gmail और outlook365 पर भी चलाए रखा जा सकता है
    • अफ़सोस कि इस तरीके में user को खुद OAuth client सेट करना पड़ता है, जो काफी manual और झंझट वाला process है

  • वजह यह है कि IMAP, SMTP, POP, Google account और पूरी digital life तक काफ़ी पहुँच दे देते हैं, लेकिन इनमें 2-factor authentication का कोई तरीका नहीं है, और न ही bot-prevention verification मिलता है
    इससे credential stuffing attacks बहुत आसान हो जाते हैं, और Google के scale पर ऐसे हमलों से बहुत लोगों की ज़िंदगी बिगड़ सकती है
    यह अच्छा बदलाव है और इसे कुछ साल पहले ही हो जाना चाहिए था। दरअसल, IMAP/POP/SMTP access को default रूप से disabled रखने जैसी दिशा में Google कुछ हद तक पहले ही जा चुका था, और ज़्यादातर users उसी से सुरक्षित हैं। यह कदम बाकी users के लिए है

    • SMTP/POP/IMAP में 2-factor authentication जोड़ना मामूली काम है
      Dovecot में पसंदीदा authentication module चुनकर incoming password को pwd+otp code के रूप में पढ़ने के लिए बदल दें। अगर user ने 2-factor authentication चालू किया है, तो आख़िरी 6 characters पढ़कर TOTP से मिलाएँ
      मेल होने पर उस IP को x minutes तक allow करें या अपनी पसंद की policy लागू करें
      हैरानी की बात है कि यह अच्छी तरह काम करता है
    • अगर कोई सचमुच पुराने तरीके से सारे mail खींचना चाहता है, तो शायद Gmail में सभी emails को किसी दूसरे address पर forward करने के लिए सेट किया जा सकता है
      वह address Gmail का न हो और IMAP/POP की अनुमति देता रहे। यह कोई रामबाण नहीं, लेकिन कुछ use cases में स्वीकार्य workaround हो सकता है
    • पुराने ढंग के passwords उचित security तो देते हैं, लेकिन client device पर user-specific cookies नहीं डाली जा सकतीं
    • “bot-prevention verification की अनुमति नहीं देता” — यही तो इसकी ख़ासियत है

  • यह बेहतरीन native mail apps से users को हटाकर Google के अपने apps की तरफ धकेलने की कोशिश है।
    gmail.app या जल्द बंद होने वाले Google sync के बिना real-time mail notifications नहीं मिलेंगी। यह पसंद नहीं है। Workspace के पैसे दे रहा हूँ, फिर भी पसंद नहीं है। डेस्कटॉप पर Mimestream अभी काम करता है, लेकिन लगता है अगला निशाना वही होगा

    • Google को अब JMAP अपनाना चाहिए।
      JMAP एक अच्छा standard protocol है, लेकिन mail providers और mail apps के बीच chicken-and-egg समस्या की वजह से इसका adoption बेहद कम है। अगर Gmail JMAP support करे, तो implementers को हर जगह support जोड़ने के लिए प्रेरित किया जा सकता है। JMAP notifications और दूसरी सुविधाएँ भी support करता है
    • OAuth implement करना इतना मुश्किल नहीं है। सेटअप के दौरान WebView चाहिए, लेकिन उसके बाद mail app token को password की तरह store करके चलते रह सकता है।
      ईमेल के लिए OAuth कई email authentication RFCs में शामिल है और कई सालों से मौजूद है।
      Thunderbird और कई mobile apps OAuth का इस्तेमाल करके Gmail को अच्छी तरह support करते हैं। बड़ी समस्या यह लगती है कि बहुत-से desktop apps ने लगभग 10 साल पहले IMAP और SMTP बदलावों को implement करना ही बंद कर दिया।
      अगर email app अब maintain नहीं हो रहा, तो Google के linked post में बताए अनुसार app-specific password इस्तेमाल किया जा सकता है। वे आगे भी काम करेंगे। जो हट रहा है, वह default account के लिए hardcoded username/password तरीका है।
      Office 2016 users के लिए यह बड़ी परेशानी होगी। 30 सितंबर Outlook support खत्म होने से अभी लगभग 9 महीने पहले है। लेकिन ज्यादातर users के लिए यह शायद काफी आसान fix होगा
    • App passwords आगे भी काम करेंगे, और native apps सामान्य OAuth flow support न करें तब भी इन्हें बिना दिक्कत इस्तेमाल किया जा सकता है
    • मैं समझता हूँ कि हर किसी की चिंता अलग होती है, लेकिन real-time mail notifications के लिए मैं Thunderbird नहीं छोड़ूँगा।
      ईमेल asynchronous होता है, इसलिए message आने के 10 मिनट बाद पता चले तो भी कोई समस्या नहीं होनी चाहिए। अगर किसी email का इंतज़ार है, तो वैसे भी उसके आने तक refresh बार-बार करते रहेंगे।
      अगर उससे भी ज़्यादा urgent हो, तो text message कर देना चाहिए। बस फोन न करें। फोन पसंद नहीं है
    • पूरी तरह सहमत। मैं Gmail account के लिए पैसे देता हूँ और हर पल उससे चिढ़ता हूँ, लेकिन spam handling में Gmail के करीब लगभग कोई नहीं दिखता

  • इसमें लिखा है: “App passwords Google Account तक पहुँच देने वाला 16-अंकों का passcode है, जिसे कम सुरक्षित app या device इस्तेमाल कर सकता है, और यह केवल उन accounts पर उपलब्ध है जिनमें 2-Step Verification चालू है”: https://support.google.com/mail/answer/185833
    मज़ेदार बात यह है कि अगर “कम सुरक्षित app या device” सिर्फ वही server-side mechanisms इस्तेमाल करे जिन्हें Google पहले से बढ़ावा दे सकता था, तो वह security के लिहाज़ से OAuth-supporting app के लगभग बराबर हो जाता है। तकनीकी तौर पर यह app की क्षमता जैसा भी नहीं लगता।
    बेशक, यह कहा जा सकता है कि “कम सुविधाजनक apps के लिए सुरक्षित workflow” जैसा नाम संदेश को कमजोर कर देता, इसलिए simplification जायज़ है। बड़ी समस्या यह है कि Google की आदत रही है कि वह security concerns की व्याख्या हमेशा अपने एजेंडा के अनुकूल तरीके से करता है, और यह हिस्सा भी उसका अपवाद नहीं है

    • Google बहुत पहले से 2-Step Verification और app-specific passwords को बढ़ावा देता आया है।
      अब वह बस उन apps के लिए इसे अनिवार्य बना रहा है जिन्हें OAuth support करने के लिए update नहीं किया जा सकता
    • OAuth और app passwords बराबर नहीं हैं। OAuth phishing के प्रति काफी कम संवेदनशील है, और granular permissions पर इसका नियंत्रण भी कहीं ज्यादा है।
      App passwords कार्यात्मक रूप से लगभग सब-कुछ-या-कुछ-नहीं जैसा मॉडल है, जबकि OAuth में read, modify, settings change जैसी permissions configure की जा सकती हैं

  • Android पर Google OAuth2 की सबसे परेशान करने वाली बात यह है कि email client या calendar में Google account से login करने के लिए पूरा phone उसी Google account से जुड़ना पड़ता है।
    साथ ही वह Google account device policy permissions भी हासिल कर लेता है। मेरी नज़र में यह पूरी तरह बेतुका है।
    App के अंदर WebView में OAuth2 इस्तेमाल करना भी Android पर Google आसानी से सीमित कर सकता है, इसलिए इससे बच निकलना भी मुश्किल है

    • क्या k9 जैसा कोई alternative client खुद OAuth implement नहीं कर सकता? डेस्कटॉप Thunderbird में मैंने शायद OAuth के साथ इसे काम करते हुए सेट किया था, Office365 के लिए।
      अफ़सोस की बात है कि भरोसेमंद email clients बहुत कम हैं। उनमें से कई credentials को remote servers पर भेज देते हैं।
      संपादन: k9 पहले से IMAP के लिए OAuth support करता है।
      https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
    • जो आम लोग Google, Android और Chrome का फर्क नहीं जानते, उनके लिए यह सब अलग-अलग चीज़ें होना झुंझलाने वाला है

  • शब्दावली थोड़ी अस्पष्ट है, लेकिन लगता है कि app-specific passwords आगे भी काम करेंगे।
    उद्धरण में कहा गया है कि SMTP या LSA के ज़रिए email भेजने वाले scanners और devices को OAuth इस्तेमाल करने के लिए configure करना होगा, कोई alternative method इस्तेमाल करना होगा, या device के लिए app password सेट करना होगा।
    यह भी कहा गया है कि जो apps OAuth support नहीं करते, उन्हें या तो OAuth देने वाले app से बदलें या access के लिए app password बनाएँ

    • उद्धृत हिस्सा मुझे बिल्कुल भी अस्पष्ट नहीं लगता। साफ़ है कि app passwords का support जारी रहेगा
    • मेरे लिए भी यह 100% स्पष्ट नहीं था। शब्दों से यह तो साफ़ था कि SMTP app passwords support करता है, लेकिन IMAP भी support करता रहेगा या नहीं, यह स्पष्ट नहीं था।
      इसलिए मैंने कल सीधे Google Workspace Support से पूछा, और जवाब था: “application passwords IMAP, POP, और सभी SMTP configurations को support करते हैं।”
      दूसरा वाक्य लगातार OAuth adoption को आगे बढ़ाने वाला था। मैं भी ऐसा करना चाहता हूँ, लेकिन बार-बार होने वाले security review की लागत हमारे जैसे छोटे SaaS apps के लिए उठाना मुश्किल है, इसलिए शुक्र है कि हम app passwords का इस्तेमाल जारी रख पाएँगे।

  • यह Workspace खाते से संबंधित बात है, और सामान्य Gmail खातों पर यह बदलाव कुछ साल पहले ही लागू हो चुका था

    • यह पूरी तरह सही नहीं है
      मैं अभी भी अपने निजी Gmail खाते को iPhone के Mail.app में Microsoft Exchange विकल्प के जरिए एक्सेस करता हूँ, और यह Fetch से बंधा नहीं है, इसलिए मुझे इस तरीके से push notifications मिलती हैं
      यह इसलिए काम करता है क्योंकि लगभग 10 साल पहले बंद करने की तारीख से पहले निजी खाते के लिए Google Sync में बनाया गया कनेक्शन अभी भी बना हुआ है और उसे मानो “grandfathered” की तरह मान्यता मिली हुई है
      इसलिए इसे चलाने के लिए iPhone के Exchange GUID को उस फ़ोन के GUID में बदलना होगा, जिसने नए लॉगिन बंद होने से पहले Google Sync में लॉगिन किया था
      सौभाग्य से, iPhone backup बनाकर, backup के अंदर की plist फ़ाइल को संशोधित करके और फिर restore करके यह GUID बदलना संभव है
      मैं अभी भी iPhone 14 Pro पर अपने निजी Gmail खाते के लिए Mail.app और push notifications इस्तेमाल कर रहा हूँ

  • घोषणा के अनुसार मेरी समझ यह है कि app passwords अभी कुछ समय तक बने रहेंगे। लेकिन अगर Google कभी app passwords भी बंद कर देता है, तो OAuth clients को अपने खर्चे पर security assessment करानी पड़ेगी, जिससे GMail पर third-party clients का इस्तेमाल काफ़ी सीमित हो जाएगा
    ईमेल अभी भी व्यापक रूप से इस्तेमाल होने वाले आख़िरी “open messaging protocols” में से एक है, और इसमें client चुनने की आज़ादी है; उस दिशा में जाना दुखद होगा

    • हर किसी के पास GMail के बजाय कुछ और इस्तेमाल करने की आज़ादी है। कोई किसी को मजबूर नहीं कर रहा

  • मैं कंपनी में Microsoft के OAuth migration को संभाल रहा हूँ, और यह काफ़ी सिरदर्द रहा है
    समस्या का एक हिस्सा यह है कि सब कुछ बहुत अपारदर्शी है। आप token भेजते हैं और server बिना किसी अतिरिक्त व्याख्या के बस “नहीं” कह देता है
    मैंने यह पता लगाने में कई दिन लगा दिए कि Client Credentials flow क्यों काम नहीं कर रहा, और आखिरकार help forum के किसी गहरे हिस्से में जवाब मिला: “ओह, client credentials flow अभी supported नहीं है।” अब IMAP/POP पर इसका support है, लेकिन याद पड़ता है कि SMTP पर अभी भी नहीं है। हालांकि SMTP के लिए अभी OAuth अनिवार्य नहीं है
    उसके बाद सही scope पता लगाना अगला काम था, और उस समय इसकी documentation भी बहुत अच्छी नहीं थी। server के error messages भी बिल्कुल मददगार नहीं थे
    क्या Google के mail servers कुछ बेहतर हैं?

    • व्यापक HTTP 401 और 403 का उपयोग https://en.wikipedia.org/wiki/Oracle_attack को रोकने के लिए किया जाता है
      दुर्भाग्य से, server के पास unauthenticated clients को “मददगार” जानकारी देने की गुंजाइश नहीं होती
    • Microsoft ऐसे अपारदर्शी error messages बनाने में हैरान करने जितना अच्छा है। user experience पूरी तरह बुरा है