साइन-इन करने के वर्कफ़्लो पर, तीसरे पक्ष की कुकी में किए गए बदलावों का असर देखना

Chrome, तीसरे पक्ष की कुकी के साथ लोगों की पसंद के लिए नया अनुभव ऑफ़र कर रहा है. आपको अपनी साइट को उन उपयोगकर्ताओं के लिए तैयार करना होगा जो तीसरे पक्ष की कुकी के बिना ब्राउज़ करना चाहते हैं.

इस पेज पर, आपको पहचान से जुड़ी उन स्थितियों के बारे में जानकारी मिलेगी जिन पर सबसे ज़्यादा असर हो सकता है. साथ ही, आपको उन समस्याओं को ठीक करने के तरीके भी मिलेंगे.

अगर आपकी वेबसाइट सिर्फ़ एक ही डोमेन और सबडोमेन, जैसे कि publisher.example और login.publisher.example में फ़्लो को हैंडल करती है, तो वह क्रॉस-साइट कुकी का इस्तेमाल नहीं करेगी. साथ ही, तीसरे पक्ष की कुकी में हुए बदलावों से आपके साइन-इन फ़्लो पर कोई असर नहीं पड़ेगा.

हालांकि, अगर आपकी साइट Google साइन-इन या Facebook Login जैसे अलग-अलग डोमेन का इस्तेमाल करके लॉगिन करती है या आपकी साइट को कई डोमेन या सबडोमेन पर उपयोगकर्ता की पुष्टि की जानकारी शेयर करनी है, तो हो सकता है कि आपको अपनी साइट में बदलाव करने पड़ें. इससे, क्रॉस-साइट कुकी से आसानी से हटने में मदद मिलेगी.

उपयोगकर्ता की सामान्य गतिविधियां

पहले, पहचान से जुड़े कई वर्कफ़्लो, तीसरे पक्ष की कुकी पर निर्भर थे. टेबल में, उपयोगकर्ता के कुछ सामान्य सफ़र और इनमें से हर एक के लिए संभावित समाधान दिए गए हैं. ये समाधान, तीसरे पक्ष की कुकी पर निर्भर नहीं करते. नीचे दिए गए सेक्शन में, इन सुझावों के पीछे की वजह बताई गई है.

इस्तेमाल के सामान्य उदाहरणों के लिए सुझाए गए अन्य एपीआई

उपयोगकर्ता अनुभव	सुझाए गए एपीआई
सोशल साइन-इन	पहचान देने वाली कंपनियों के लिए: FedCM लागू करें भरोसा करने वाले पक्षों के लिए: अपने आइडेंटिटी प्रोवाइडर से संपर्क करें
फ़्रंट चैनल से लॉग आउट करना	आइडेंटिटी प्रोवाइडर के लिए: FedCM लागू करें
सिंगल साइन-ऑन	आइडेंटिटी प्रोवाइडर या कस्टम सलूशन के लिए: मिलती-जुलती वेबसाइट के सेट
उपयोगकर्ता की प्रोफ़ाइल मैनेज करना	Storage Access API मिलती-जुलती वेबसाइट के सेट CHIPS FedCM
सदस्यताएं मैनेज करना	Storage Access API मिलती-जुलती वेबसाइट के सेट सीएचआईपीएस FedCM
पुष्टि करना	Storage Access API FedCM Web Authentication API sciencePartitioned Popins
उपयोगकर्ता की अन्य यात्राएं	इन मामलों में, आम तौर पर तीसरे पक्ष की कुकी डिपेंडेंसी नहीं होतीं और इन पर कोई असर नहीं होता.

पहचान से जुड़ी उपयोगकर्ता की गतिविधियों की जांच करना

तीसरे पक्ष की कुकी में हुए बदलावों का असर आपके साइन-इन फ़्लो पर हुआ है या नहीं, यह जानने का सबसे अच्छा तरीका है कि आप तीसरे पक्ष की कुकी टेस्टिंग फ़्लैग चालू करें के साथ रजिस्ट्रेशन, पासवर्ड वापस पाना, साइन-इन, और साइन-आउट करने की प्रोसेस देखें.

तीसरे पक्ष की कुकी पर पाबंदी लगाने के बाद, इन चीज़ों की जांच करें:

• उपयोगकर्ता का रजिस्ट्रेशन: नया खाता बनाने की सुविधा उम्मीद के मुताबिक काम करती है. अगर तीसरे पक्ष के आइडेंटिटी प्रोवाइडर का इस्तेमाल किया जा रहा है, तो देख लें कि हर इंटिग्रेशन के लिए नए खातों का रजिस्टरेशन काम करता है या नहीं.
• पासवर्ड वापस पाना: पासवर्ड वापस पाने की सुविधा, वेब यूज़र इंटरफ़ेस से लेकर CAPTCHA तक, उम्मीद के मुताबिक काम करती है. साथ ही, पासवर्ड वापस पाने का ईमेल भी मिलता है.
• साइन-इन: साइन-इन करने का वर्कफ़्लो उसी डोमेन में और दूसरे डोमेन पर नेविगेट करते समय काम करता है. हर साइन-इन इंटिग्रेशन की जांच करना न भूलें.
• साइन आउट: साइन आउट करने की प्रोसेस उम्मीद के मुताबिक काम करती है. साथ ही, साइन आउट करने के बाद भी उपयोगकर्ता साइन आउट रहता है.

आपको इस बात की भी जांच करनी चाहिए कि उपयोगकर्ता को साइन-इन करने की ज़रूरत पड़ने पर, साइट की दूसरी सुविधाएं, क्रॉस-साइट कुकी के बिना भी काम करती रहें. खास तौर पर तब, जब उनमें क्रॉस-साइट रिसॉर्स लोड करना शामिल हो. उदाहरण के लिए, अगर उपयोगकर्ता की प्रोफ़ाइल की इमेज लोड करने के लिए सीडीएन का इस्तेमाल किया जाता है, तो पक्का करें कि यह अब भी काम करता हो. अगर उपयोगकर्ता की गतिविधियां मुश्किल हैं, जैसे कि चेकआउट और साइन इन करने से जुड़ी सुविधाएं, तो पक्का करें कि ये काम करते रहें.

साइन-इन करने के तरीके

इस सेक्शन में, आपको इस बारे में ज़्यादा जानकारी मिलेगी कि उन फ़्लो पर क्या असर पड़ सकता है.

तीसरे पक्ष का सिंगल साइन-ऑन (एसएसओ)

तीसरे पक्ष के सिंगल साइन-इन (एसएसओ) की मदद से, उपयोगकर्ता एक ही प्लैटफ़ॉर्म पर क्रेडेंशियल के एक सेट से पुष्टि कर सकता है. इसके बाद, लॉगिन की जानकारी फिर से डाले बिना कई ऐप्लिकेशन और वेबसाइटों को ऐक्सेस कर सकता है. एसएसओ (SSO) सलूशन को लागू करने की प्रोसेस जटिल होने की वजह से, कई कंपनियां तीसरे पक्ष के सलूशन प्रोवाइडर का इस्तेमाल करती हैं. इससे, वे एक से ज़्यादा ऑरिजिन के बीच साइन इन स्टेटस शेयर कर पाती हैं. Okta, Ping Identity, Google Cloud IAM या Microsoft Entra आईडी जैसे प्रोवाइडर के उदाहरण.

अगर आपका समाधान किसी तीसरे पक्ष की कंपनी पर निर्भर है, तो हो सकता है कि आपको लाइब्रेरी अपग्रेड करने जैसे कुछ मामूली बदलाव करने पड़ें. सबसे अच्छा तरीका यह है कि आप सेवा देने वाली कंपनी से सलाह लें कि तीसरे पक्ष की कुकी की निर्भरता, समाधान पर कैसे असर डालती है और वे अपनी सेवा के लिए किस तरीके का सुझाव देते हैं. सेवा देने वाली कुछ कंपनियां, अपने-आप तीसरे पक्ष की कुकी का इस्तेमाल बंद कर देती हैं. इस स्थिति में, भरोसेमंद पक्षों को अपडेट करने की ज़रूरत नहीं होती.

अनेक डोमेन

कुछ वेबसाइटें, सिर्फ़ उन उपयोगकर्ताओं की पुष्टि करने के लिए किसी दूसरे डोमेन का इस्तेमाल करती हैं जो एक ही साइट की कुकी की ज़रूरी शर्तें पूरी नहीं करती हैं. जैसे, मुख्य साइट के लिए example.com और लॉगिन फ़्लो के लिए login.example का इस्तेमाल करने वाली वेबसाइट. इसके लिए, तीसरे पक्ष की कुकी को ऐक्सेस करना पड़ सकता है, ताकि यह पक्का किया जा सके कि उपयोगकर्ता की पुष्टि दोनों डोमेन पर की गई है.

कुछ कारोबारों के पास अलग-अलग डोमेन या सबडोमेन पर होस्ट किए गए कई प्रॉडक्ट हो सकते हैं. ऐसे समाधान, उपयोगकर्ता के सेशन को उन प्रॉडक्ट के साथ शेयर करना चाह सकते हैं. ऐसे में, एक से ज़्यादा डोमेन के बीच तीसरे पक्ष की कुकी को ऐक्सेस करना पड़ सकता है.

इस स्थिति के लिए, माइग्रेशन के ये पाथ हो सकते हैं:

• पहले पक्ष की ("एक ही साइट") कुकी का इस्तेमाल करने के लिए अपडेट करें: वेबसाइट के इंफ़्रास्ट्रक्चर में बदलाव करना, ताकि लॉगिन फ़्लो को मुख्य साइट के उसी डोमेन (या सबडोमेन) पर होस्ट किया जा सके जो सिर्फ़ पहले पक्ष की कुकी का इस्तेमाल करेगा. इसके लिए ज़्यादा मेहनत की ज़रूरत पड़ सकती है. यह इस बात पर निर्भर करता है कि बुनियादी ढांचा कैसे सेट अप किया गया है.
• मिलती-जुलती वेबसाइट के सेट (आरडब्ल्यूएस) और स्टोरेज ऐक्सेस एपीआई (एसएए) का इस्तेमाल करें: आरडब्ल्यूएस, मिलते-जुलते डोमेन के छोटे ग्रुप के बीच, क्रॉस-साइट कुकी के सीमित ऐक्सेस की सुविधा देता है. आरडब्ल्यूएस की मदद से, Storage Access API से स्टोरेज ऐक्सेस करने का अनुरोध करते समय, उपयोगकर्ता से अनुरोध करने की ज़रूरत नहीं होती. इससे उन आरपी पर एसएसओ (SSO) की अनुमति मिल जाती है जो आईडीपी (IdP) आरडब्ल्यूएस में हैं. हालांकि, RWS की मदद से सिर्फ़ कुछ डोमेन के लिए, दूसरी साइट की कुकी का ऐक्सेस मिलता है.
• Web Authentication API का इस्तेमाल करें: Web Authentication API, भरोसेमंद पक्षों (आरपी) को मिलते-जुलते ऑरिजिन के कुछ सेट को रजिस्टर करने की अनुमति देता है. इन ऑरिजिन के लिए, क्रेडेंशियल बनाए और इस्तेमाल किए जा सकते हैं.
• अगर आपको पांच से ज़्यादा असोसिएटेड डोमेन के लिए उपयोगकर्ताओं की पुष्टि करनी है, तो फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट (FedCM) के बारे में जानें: FedCM की मदद से, पहचान की पुष्टि करने वाली सेवाएं, तीसरे पक्ष की कुकी के बिना, Chrome पर पहचान से जुड़े फ़्लो को मैनेज कर सकती हैं. आपके मामले में, आपका "साइन-इन डोमेन", FedCM आइडेंटिटी प्रोवाइडर के तौर पर काम कर सकता है. साथ ही, इसका इस्तेमाल आपके अन्य डोमेन के उपयोगकर्ताओं की पुष्टि करने के लिए किया जा सकता है.

एम्बेड से पुष्टि करना

मान लें कि 3-party-app.example iframe, top-level.example पर एम्बेड किया गया है. उपयोगकर्ता 3-party-app.example पर, 3-party-app.example क्रेडेंशियल से या सेवा देने वाली तीसरे पक्ष की किसी अन्य कंपनी की मदद से लॉगिन कर सकता है.

3-party-app.example

उपयोगकर्ता, "लॉगिन करें" पर क्लिक करता है और 3-party-app.example पॉप-अप में पुष्टि करता है. 3-party-app.example पॉप-अप, पहले-पक्ष की कुकी सेट करता है. हालांकि, top-level.example पर एम्बेड किए गए 3-party-app.example iframe को अलग-अलग हिस्सों में बांटा गया है. इसलिए, यह 3-party-app.example पर पहले पक्ष के संदर्भ में सेट की गई कुकी को ऐक्सेस नहीं कर सकता.

यही समस्या तब भी होगी, जब उपयोगकर्ता को top-level.example से 3-party-app.example और फिर से top-level.example पर रीडायरेक्ट किया जाए. कुकी को 3-party-app.example साइट के पहले पक्ष के कॉन्टेक्स्ट में लिखा गया है, लेकिन इसे अलग-अलग हिस्सों में बांटा गया है और इसे 3-party-app.example iframe में ऐक्सेस नहीं किया जा सकता.

अगर उपयोगकर्ता ने टॉप-लेवल के कॉन्टेक्स्ट में एम्बेड किए गए ऑरिजिन पर विज़िट किया है, तो Storage Access API एक अच्छा समाधान है.

हमारा सुझाव है कि पहचान की पुष्टि करने वाली सेवा देने वाली कंपनियां, तीसरे पक्ष की कुकी पर निर्भर रहने वाले समाधानों से माइग्रेट करें. इसके लिए, वे FedCM API का इस्तेमाल करें. साथ ही, FedCM को पॉप-अप के बजाय एम्बेड किए गए कॉन्टेंट से कॉल करें.

इस फ़्लो के लिए, पार्टिशन किए गए पॉपिन का एक और सुझाया गया समाधान लागू किया जा रहा है.

सोशल साइन-इन

Google से साइन इन करें, Facebook लॉगिन, और Twitter से लॉग इन करें जैसे साइन इन बटन से पता चलता है कि आपकी वेबसाइट, फ़ेडरेटेड आइडेंटिटी प्रोवाइडर का इस्तेमाल कर रही है. फ़ेडरेटेड आइडेंटिटी प्रोवाइडर का अपना लागू करने का तरीका होगा.

अगर Google Sign-In JavaScript प्लैटफ़ॉर्म लाइब्रेरी के अब काम न करने वाले वर्शन का इस्तेमाल किया जा रहा है, तो पुष्टि करने और अनुमति देने की प्रक्रिया के लिए, Google Identity Services की नई लाइब्रेरी पर माइग्रेट करने का तरीका जानें.

Google Identity Services की नई लाइब्रेरी का इस्तेमाल करने वाली ज़्यादातर साइटों ने तीसरे पक्ष की कुकी पर निर्भरता कम कर दी है. ऐसा इसलिए किया गया है, क्योंकि काम करने के लिए लाइब्रेरी, FedCM का इस्तेमाल करने के लिए चुपचाप माइग्रेट हो जाएगी. हमारा सुझाव है कि तीसरे पक्ष की कुकी को धीरे-धीरे हटाने की जांच करने के लिए फ़्लैग चालू करके अपनी साइट की जांच करें. साथ ही, ज़रूरत पड़ने पर, FedCM माइग्रेशन की चेकलिस्ट का इस्तेमाल करके तैयारी करें.

एम्बेड किए गए कॉन्टेंट से उपयोगकर्ता का डेटा ऐक्सेस करना और उसमें बदलाव करना

एम्बेड किए गए कॉन्टेंट का इस्तेमाल, अक्सर लोगों के काम के लिए किया जाता है. जैसे, उपयोगकर्ता की प्रोफ़ाइल या सदस्यता के डेटा को ऐक्सेस या मैनेज करना.

उदाहरण के लिए, कोई उपयोगकर्ता website.example में लॉगिन कर सकता है, जो subscriptions.example विजेट को एम्बेड करता है. इस विजेट की मदद से, उपयोगकर्ता अपना डेटा मैनेज कर सकते हैं. जैसे, प्रीमियम कॉन्टेंट की सदस्यता लेना या बिलिंग जानकारी अपडेट करना. उपयोगकर्ता के डेटा में बदलाव करने के लिए, हो सकता है कि एम्बेड किए गए विजेट को website.example पर एम्बेड करते समय, अपनी कुकी ऐक्सेस करनी पड़े. अगर यह डेटा website.example के लिए अलग से होना चाहिए, तो CHIPS की मदद से यह पक्का किया जा सकता है कि एम्बेड की गई जानकारी को ऐक्सेस किया जा सके. CHIPS की मदद से, website.example पर एम्बेड किए गए subscriptions.example विजेट के पास, अन्य वेबसाइटों पर उपयोगकर्ता की सदस्यता के डेटा का ऐक्सेस नहीं होगा.

एक और उदाहरण देखें: streaming.example का कोई वीडियो website.example पर एम्बेड किया गया है और उपयोगकर्ता के पास streaming.example की प्रीमियम सदस्यता है. विज्ञापनों को बंद करने के लिए, विजेट को इसकी जानकारी चाहिए. अगर एक ही कुकी को अलग-अलग साइटों पर ऐक्सेस करना है, तो Storage Access API का इस्तेमाल करें. ऐसा तब करें, जब उपयोगकर्ता ने पहले टॉप-लेवल के तौर पर streaming.example पर विज़िट किया हो. अगर website.example के सेट के पास streaming.example का मालिकाना हक है, तो मिलती-जुलती वेबसाइट के सेट का इस्तेमाल करें.

Chrome 131 से, FedCM को Storage Access API के साथ इंटिग्रेट किया गया है. इस इंटिग्रेशन की मदद से, जब उपयोगकर्ता FedCM प्रॉम्प्ट स्वीकार करता है, तो ब्राउज़र आईडीपी को बिना बंटे हुए स्टोरेज का ऐक्सेस दे देगा.

एम्बेड किए गए कॉन्टेंट की मदद से, उपयोगकर्ता के सफ़र को मैनेज करने के लिए, किस एपीआई को चुनना है, इस बारे में ज़्यादा जानने के लिए, एम्बेड करने के बारे में गाइड देखें.

फ़्रंट-चैनल लॉग आउट

फ़्रंट-चैनल लॉग आउट एक ऐसा तरीका है जिसकी मदद से, उपयोगकर्ता किसी एक सेवा से लॉग आउट करने पर, उससे जुड़े सभी ऐप्लिकेशन से लॉग आउट कर सकता है. OIDC के फ़्रंट-चैनल लॉगआउट के लिए, आईडीपी को ऐसे कई भरोसेमंद पक्ष (आरपी) iframe को जोड़ना ज़रूरी है जो आरपी की कुकी पर निर्भर करते हैं.

अगर आपका समाधान किसी आइडेंटिटी प्रोवाइडर पर निर्भर है, तो हो सकता है कि आपको कुछ मामूली बदलाव करने पड़ें. जैसे, लाइब्रेरी अपग्रेड करना. ज़्यादा जानकारी के लिए, अपने आइडेंटिटी प्रोवाइडर से संपर्क करें.

इस इस्तेमाल के उदाहरण को हल करने के लिए, FedCM ने logoutRPs सुविधा के साथ प्रयोग किया. इससे आईडीपी, किसी भी ऐसे आरपी को लॉग आउट कर सकता था जिसके लिए उपयोगकर्ता ने पहले आरपी-आईडीपी कम्यूनिकेशन की अनुमति दी थी. यह सुविधा अब उपलब्ध नहीं है. हालांकि, अगर आपको इस सुविधा में दिलचस्पी है या इसकी ज़रूरत है, तो हमारा सुझाव है कि आप शुरुआती प्रस्ताव देखें और अपने सुझाव/राय/शिकायत शेयर करें.

उपयोगकर्ता की अन्य गतिविधियां

तीसरे पक्ष की कुकी पर निर्भर न होने वाली उपयोगकर्ता यात्राओं पर, तीसरे पक्ष की कुकी को मैनेज करने के Chrome के तरीके में हुए बदलावों का असर नहीं पड़ेगा. पहले पक्ष (2FA) के लिए साइन इन, साइन आउट या खाता वापस पाने जैसे मौजूदा तरीके, उम्मीद के मुताबिक काम करने चाहिए. पहले ही, ब्रेक होने की संभावित जगहों के बारे में बताया गया है. किसी खास एपीआई के बारे में ज़्यादा जानकारी के लिए, एपीआई का स्टेटस पेज देखें. किसी भी तरह की गड़बड़ी की शिकायत करने के लिए, goo.gle/report-3pc-broken पर जाएं. सुझाव/राय, शिकायत या राय देने वाला फ़ॉर्म सबमिट किया जा सकता है. इसके अलावा, GitHub पर Privacy Sandbox के डेवलपर सहायता रिपॉज़िटरी में जाकर, समस्या की शिकायत भी की जा सकती है.

अपनी साइट की जांच करें

अगर आपकी वेबसाइट, इस गाइड में बताई गई उपयोगकर्ता यात्राओं में से किसी एक को लागू करती है, तो आपको पक्का करना होगा कि आपकी साइटें तैयार हैं: तीसरे पक्ष की कुकी के इस्तेमाल के लिए अपनी साइट का ऑडिट करें, ब्रेकेज की जांच करें, और सुझाए गए समाधानों पर ट्रांज़िशन करें.