क्रॉस-डोमेन लॉगिन को डीफ़्रैगमेंट करना

Eiji Kitamura

आजकल, कारोबार के लिए इस्तेमाल होने वाले आधुनिक आर्किटेक्चर में अक्सर एक से ज़्यादा अलग-अलग डोमेन शामिल होते हैं. संगठन, अलग-अलग सुविधाओं के लिए अलग-अलग एनवायरमेंट बनाए रखते हैं. जैसे, मार्केटिंग के लिए brand.example, मुख्य प्रॉडक्ट के लिए service-app.example, और ग्राहक सेवा के लिए support-portal.example. हमारा सुझाव है कि उपयोगकर्ताओं को इन सभी प्रॉपर्टी पर एक जैसा और सिंगल साइन-इन का अनुभव दें. हालांकि, इंजीनियरिंग टीमें अक्सर इन डोमेन को ऐडहॉक तकनीकों का इस्तेमाल करके इंटिग्रेट करती हैं. इससे फ़्रैगमेंटेशन की समस्या होती है. इससे ब्राउज़र में क्रेडेंशियल मैनेज करने की इन-बिल्ट सुविधा में रुकावट आती है. ऐसा पासवर्ड मैनेजर के ऑटोमैटिक भरने की प्रोसेस में गड़बड़ी होने और पासकी को अपनाने में देरी होने की वजह से होता है.

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

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

आम तौर पर इस्तेमाल किए जाने वाले वर्कअराउंड

संगठन, क्रॉस-डोमेन के लिए कई तरीकों का इस्तेमाल करते हैं. हालांकि, ये तरीके आम तौर पर इस्तेमाल किए जाते हैं, लेकिन इनमें कुछ समस्याएं आती हैं. ऐसा इसलिए होता है, क्योंकि ब्राउज़र, निजता और सुरक्षा के मानकों को ज़्यादा सख्ती से लागू करते हैं.

सीओआरएस फ़ेच के अनुरोध

जब डोमेन अलग-अलग काम करते हैं, तो फ़्रंटएंड अक्सर, क्रॉस-ऑरिजिन fetch() के अनुरोधों पर निर्भर करते हैं. ये अनुरोध, पुष्टि करने वाले एक सेंट्रलाइज़्ड एपीआई को भेजे जाते हैं. इन्हें सुरक्षित तरीके से अनुमति दी जा सकती है. इसके लिए, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का इस्तेमाल किया जाता है. ब्राउज़र अक्सर क्रॉस-साइट कुकी को ब्लॉक या सीमित करते हैं. इसलिए, डेवलपर इन एपीआई को इस तरह से डिज़ाइन कर सकते हैं कि वे Set-Cookie हेडर पर निर्भर रहने के बजाय, JSON पेलोड में पुष्टि करने वाले टोकन लौटाएं. जैसे, JSON वेब टोकन (JWT).

खाते के डेटाबेस को शेयर करना

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

अलग-अलग साइन-इन से जुड़ी समस्याएं

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

पासवर्ड मैनेजर का फ़्रैगमेंटेशन

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

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

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

फ़िशिंग गेटवे

यह रुकावट, फ़िशिंग गेटवे की तरह काम करती है. किसी ऐसे डोमेन पर ऑटोमैटिक भरने की सुविधा न देना जिसे पासवर्ड मैनेजर नहीं पहचानता, सुरक्षा का एक अहम तरीका है. उपयोगकर्ताओं को अलग-अलग यूआरएल पर मैन्युअल तरीके से क्रेडेंशियल डालने के लिए कहकर, आप अनजाने में ही उन्हें फ़िशिंग के हमलों का शिकार होने के लिए तैयार करते हैं.

पासकी से जुड़ी समस्या

पासकी का इस्तेमाल करने पर, समस्या और बढ़ जाती है. WebAuthn के मुख्य सुरक्षा आर्किटेक्चर में, पासकी को क्रिप्टोग्राफ़िक तरीके से, तय किए गए Relying Party ID (RP ID)से जोड़ा जाता है.

इससे "RP ID ट्रैप" की समस्या होती है. brand.example पर रजिस्टर की गई पासकी का इस्तेमाल service-app.example पर नहीं किया जा सकता, क्योंकि ब्राउज़र, क्रॉस-डोमेन ऐक्सेस की अनुमति नहीं देता. उपयोगकर्ताओं को हर साइट के लिए अलग-अलग पासकी रजिस्टर करने के लिए कहने से बचने के लिए, आपको इन प्रॉपर्टी को एक ही RP ID में कंसोलिडेट करना होगा.

सुझाए गए तरीके

आइडेंटिटी की जानकारी को बनाए रखने के लिए, आपको ऐडहॉक साइन-इन इंटिग्रेशन के बजाय, आर्किटेक्चर के मान्य स्टैंडर्ड अपनाने होंगे:

• मेटाडेटा कॉन्फ़िगरेशन फ़ाइलों का इस्तेमाल करना: क्रिप्टोग्राफ़िक ट्रस्ट चेन बनाने के लिए, डिजिटल एसेट लिंक और मिलते-जुलते ऑरिजिन के अनुरोध जैसी मेटाडेटा फ़ाइलें होस्ट करें. इससे अलग-अलग डोमेन और मोबाइल ऐप्लिकेशन के बीच, क्रेडेंशियल और पासकी को आसानी से शेयर किया जा सकता है. यह तरीका, आइडेंटिटी फ़्रैगमेंटेशन की समस्या को कम लागत में और बिना किसी रुकावट के ठीक करता है. इसके लिए, मौजूदा वेब इन्फ़्रास्ट्रक्चर को फिर से डिज़ाइन करने की ज़रूरत नहीं होती.
• क्रॉस-ऑरिजिन iframe का इस्तेमाल करना: अलग-अलग साइटों पर सेव किए गए क्रेडेंशियल और पासकी को जोड़ने के लिए, भरोसेमंद पक्ष में पुष्टि करने वाले सेंट्रलाइज़्ड ऑरिजिन को iframe के तौर पर एम्बेड करें. इस तरीके में, Permissions Policy और पार्टिशन की गई कुकी का इस्तेमाल किया जाता है. इससे, कॉन्टेक्स्ट में साइन-इन करने का बेहतर अनुभव मिलता है. साथ ही, सीएसपी और क्रॉस-डॉक्यूमेंट मैसेजिंग की मदद से, सुरक्षा के सख्त मानकों को बनाए रखा जाता है.
• आइडेंटिटी फ़ेडरेशन के स्टैंडर्ड का पालन करना: पुष्टि करने के लिए, OpenID Connect जैसे इंडस्ट्री-स्टैंडर्ड प्रोटोकॉल अपनाएं. इससे, पुष्टि करने की प्रोसेस को आइडेंटिटी प्रोवाइडर (आईडीपी) के किसी खास डोमेन पर सेंट्रलाइज़ किया जा सकता है. इससे, सुरक्षित रीडायरेक्ट की मदद से लॉग इन करने की प्रोसेस को फ़ॉर्मलाइज़ किया जाता है. साथ ही, कमज़ोर इंटिग्रेशन को, पहले पक्ष के भरोसेमंद और स्केलेबल समाधान से बदला जाता है.
• सबडोमेन को कंसोलिडेट करना: एक ही रूट के तहत सबडोमेन पर ट्रांज़िशन करना. इससे, वाइल्डकार्ड कुकी की मदद से सेशन को आसानी से शेयर किया जा सकता है. साथ ही, रजिस्टर किए जा सकने वाले पूरे डोमेन पर पासकी की सुविधा बनी रहती है. कई पासवर्ड मैनेजर, शेयर किए गए रूट डोमेन को पहचान सकते हैं. साथ ही, मिलते-जुलते सबडोमेन पर सेव किए गए क्रेडेंशियल को अपने-आप सुझा सकते हैं.

मेटाडेटा कॉन्फ़िगरेशन फ़ाइलों का इस्तेमाल करना

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

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

पक्का करें कि आपने अलग-अलग प्लैटफ़ॉर्म और इकोसिस्टम के लिए, दो अलग-अलग कॉन्फ़िगरेशन फ़ाइलों का इस्तेमाल किया हो:

• Android और Chrome पर Google Password Manager: किसी संगठन से जुड़े ऐप्लिकेशन और वेबसाइटों के बीच, पुष्टि किए जा सकने वाला भरोसेमंद संबंध बनाने के लिए, डिजिटल एसेट लिंक (डीएएल) JSON फ़ाइल को /.well-known/assetlinks.json पर होस्ट करें. इस भरोसे से, ऐप्लिकेशन पर डीप लिंक और आसानी से क्रेडेंशियल शेयर करने की सुविधा मिलती है., इसमें, वेब पर सेव किए गए पासवर्ड, मिलते-जुलते वेबसाइटों पर अपने-आप भर जाते हैं. हालांकि, एक से ज़्यादा वेब डोमेन पर पासकी शेयर करने के लिए, अब भी मिलते-जुलते ऑरिजिन के अनुरोधों की ज़रूरत होती है. आसानी से क्रेडेंशियल शेयर करने की सुविधा के बारे में ज़्यादा जानने के लिए, गाइड पढ़ें.

• iOS और Safari पर Apple Passwords: iOS ऐप्लिकेशन और Safari पर Apple Passwords की स्थितियों को जोड़ने के लिए ज़रूरी क्रिप्टोग्राफ़िक ट्रस्ट चेन बनाने के लिए, /.well-known/apple-app-site-association पर Apple App Site Association (AASA) फ़ाइल होस्ट करें. तीसरे पक्ष के इकोसिस्टम के साथ काम करने के लिए, आप क्राउडसोर्सिंग से बनाए गए रिपॉज़िटरी का इस्तेमाल करके, इन मिलते-जुलते डोमेन को एक जगह पर घोषित कर सकते हैं. ऐसा करने से, अलग-अलग टूल (जैसे, 1Password, जो इस रिपॉज़िटरी को साफ़ तौर पर इस्तेमाल करता है) भी शेयर किए गए आइडेंटिटी कॉन्टेक्स्ट को पहचान पाते हैं. Apple App Site Association के बारे में ज़्यादा जानने के लिए, मिलते-जुलते डोमेन के साथ काम करना लेख पढ़ें.

डेवलपर, अलग-अलग वेब डोमेन पर पासकी की सुविधा चालू करने और पासकी से जुड़ी समस्या हल करने के लिए, मिलते-जुलते ऑरिजिन के अनुरोध (आरओआर) वाली फ़ाइल /.well-known/webauthn पर होस्ट कर सकते हैं. आरओआर, अनुमति वाले उन डोमेन के बारे में साफ़ तौर पर बताता है जिन्हें एक ही पासकी आरपी आईडी को सुरक्षित तरीके से शेयर करने की अनुमति है. मिलते-जुलते ऑरिजिन के अनुरोधों के बारे में ज़्यादा जानने के लिए , मिलते-जुलते ऑरिजिन के अनुरोधों की मदद से, अपनी साइटों पर पासकी को फिर से इस्तेमाल करने की अनुमति देना लेख पढ़ें.

• फ़ायदे:
  • एंड यूज़र के लिए बैकग्राउंड में ठीक होने वाली समस्या: यह पूरी तरह से बैकग्राउंड में काम करता है. इससे, ऑटोमैटिक भरने की सुविधा के फ़्रैगमेंटेशन की समस्या अपने-आप हल हो जाती है. साथ ही, ओएस या ब्राउज़र लेवल पर पासकी की सुविधा बनी रहती है. यूएक्स में कोई बदलाव नहीं दिखता.
  • आसान तरीके से लागू करना: यह कम लागत वाला समाधान है. इसके लिए, सिर्फ़ स्टैटिक JSON फ़ाइलें होस्ट करनी होती हैं. इसके लिए, बैकएंड को फिर से डिज़ाइन करने या टोकन एक्सचेंज के जटिल लॉजिक की ज़रूरत नहीं होती.
  • मौजूदा इन्फ़्रास्ट्रक्चर को बनाए रखना: अपने ब्रैंड में बदलाव किए बिना या डोमेन को कंसोलिडेट किए बिना, क्रॉस-डोमेन के लिए बेहतर अनुभव दिया जा सकता है.
• नुकसान:
  • प्लैटफ़ॉर्म की पाबंदियां: प्लैटफ़ॉर्म आम तौर पर, आरओआर पर सख्त सीमाएं लागू करते हैं. उदाहरण के लिए, Chrome, एक आरपी आईडी को ज़्यादा से ज़्यादा पांच मिलते-जुलते eTLD+1 लेबल तक सीमित करता है. उदाहरण के लिए, example.co.uk और example.de एक ही example eTLD+1 लेबल शेयर करते हैं. हालांकि, example-rewards.com एक अलग example-rewards लेबल इस्तेमाल करता है. अगर आपके पास डोमेन का बड़ा या अलग-अलग पोर्टफ़ोलियो है, तो ये सीमाएं काफ़ी नहीं हो सकती हैं.
  • ऑपरेशनल लेटेंसी बढ़ना: मेटाडेटा फ़ाइलों को हल करने के लिए, नेटवर्क का एक अतिरिक्त राउंडट्रिप ज़रूरी होता है. इससे, ब्राउज़र के पुष्टि करने की प्रोसेस में लेटेंसी बढ़ जाती है.

क्रॉस-ऑरिजिन iframe का इस्तेमाल करना

अगर आरओआर डोमेन की सीमाओं की वजह से, मेटाडेटा कॉन्फ़िगरेशन फ़ाइलों का इस्तेमाल नहीं किया जा सकता, तो क्रॉस-ऑरिजिन iframe एलिमेंट, क्रॉस-डोमेन साइन-इन की चुनौतियों को हल करने के लिए, स्टैंडर्ड के साथ काम करने वाला एक मज़बूत तरीका है.

भरोसेमंद पक्ष (उदाहरण के लिए, brand.example) में पुष्टि करने वाले सेंट्रलाइज़्ड ऑरिजिन (उदाहरण के लिए, auth.brand.example) को iframe के तौर पर एम्बेड करके, सामान्य फ़ॉर्म फ़ील्ड और आधुनिक एपीआई, दोनों के साथ इंटरैक्ट किया जा सकता है. पासवर्ड के लिए, ब्राउज़र का क्रेडेंशियल मैनेजर, ऑटोमैटिक भरने की कार्रवाइयों को iframe के ऑरिजिन (auth.example) से जोड़ता है. इससे उपयोगकर्ता, अलग-अलग साइटों पर अपने सेंट्रलाइज़्ड क्रेडेंशियल को आसानी से ऐक्सेस कर पाते हैं.

पासकी के लिए, पैरंट विंडो को Permissions Policy फ़्रेमवर्क का इस्तेमाल करके, iframe को ऐक्सेस करने की अनुमति देनी होगी. इससे iframe, अपने ऑरिजिन के आरपी आईडी के ख़िलाफ़ पुष्टि करने के लिए, WebAuthn को लागू कर पाएगा. दोनों फ़्लो में, सीएसपी (कॉन्टेंट की सुरक्षा के लिए नीति) का इस्तेमाल, उपयोगकर्ताओं को क्लिकजैकिंग और क्रॉस-साइट स्क्रिप्टिंग जैसे हमलों से बचाने के लिए किया जाता है. पुष्टि हो जाने के बाद, पार्टिशन की गई कुकी की मदद से सेशन बनाया जाता है. साथ ही, टोकन को `postMessage()` का इस्तेमाल करके, पैरंट विंडो पर सुरक्षित तरीके से वापस भेजा जाता है. postMessage()

• फ़ायदे:
  • सेंट्रलाइज़्ड क्रेडेंशियल: क्रेडेंशियल फ़्रैगमेंटेशन की समस्या से बचा जा सकता है. एक सेंट्रलाइज़्ड ऑरिजिन, सेव किए गए पासवर्ड और एक ही पासकी आरपी आईडी, दोनों को मैनेज करता है. इससे अलग-अलग डोमेन, डोमेन को कंसोलिडेट किए बिना इन क्रेडेंशियल को शेयर कर पाते हैं.
  • कॉन्टेक्चुअल पुष्टि: साइन-इन का पूरा फ़्लो—चाहे पासवर्ड को ऑटोमैटिक तरीके से भरना हो या पासकी से पुष्टि करना हो—पैरंट पेज में कॉन्टेक्स्ट में आसानी से होता है. इससे, फ़ेडरेटेड रीडायरेक्ट की समस्या नहीं होती.
  • ट्रैकिंग से सुरक्षा के लिए बेहतर: पार्टिशन की गई कुकी का इस्तेमाल करके, क्रॉस-साइट ट्रैकिंग से सुरक्षा के सख्त नियमों के तहत भी यह तरीका सही तरीके से काम करता है.
• नुकसान:
  • लागू करने से जुड़ी पाबंदियां: इस आर्किटेक्चर के लिए, खास इंजीनियरिंग की ज़रूरत होती है. इसके लिए, सख्त सीएसपी (frame-ancestors) की ज़रूरत होती है, ताकि एम्बेड करने की सुविधा को भरोसेमंद पैरंट डोमेन तक सीमित किया जा सके और क्लिकजैकिंग को रोका जा सके. साथ ही, WebAuthn एपीआई को चालू करने के लिए, एचटीटीपी Permissions Policy को कॉन्फ़िगर करने और ऑरिजिन-स्पूफ़िंग और सीएसआरएफ़ के हमलों को कम करने के लिए, सुरक्षित और पुष्टि की गई क्रॉस-डॉक्यूमेंट मैसेजिंग (postMessage()) की ज़रूरत होती है. iframe में पासकी इस्तेमाल करने के सबसे सही तरीकों के बारे में जानें.

आइडेंटिटी फ़ेडरेशन के स्टैंडर्ड का पालन करना

OpenID Connect जैसे आइडेंटिटी फ़ेडरेशन के स्टैंडर्ड को अपनाना, आपके खाते के सिस्टम को बनाए रखने का एक मज़बूत और टिकाऊ तरीका है. इस तरीके से, पुष्टि करने के वर्कफ़्लो को फ़ॉर्मलाइज़ किया जाता है. इसके लिए, पुष्टि करने की प्रोसेस को आइडेंटिटी प्रोवाइडर (आईडीपी) के किसी खास डोमेन पर कंसोलिडेट किया जाता है. जैसे, auth.brand.example. किसी प्रोटोकॉल के सेट अप होने के बाद, ऐप्लिकेशन, उपयोगकर्ताओं को पुष्टि करने के लिए इस सेंट्रल हब पर रीडायरेक्ट करते हैं. इसके बाद, टारगेट डोमेन पर लॉग इन करने के लिए, टोकन को सुरक्षित तरीके से ट्रांसफ़र किया जाता है. हालांकि, अक्सर तीसरे पक्ष के लॉग इन (जैसे, Google से साइन इन करें) के साथ, फ़ेडरेशन के स्टैंडर्ड का इस्तेमाल किया जाता है. फिर भी, यह पहले पक्ष के समाधान के तौर पर पूरी तरह से मान्य है और इसका इस्तेमाल, कमज़ोर वर्कअराउंड को बदलने के लिए बड़े पैमाने पर किया जाता है.

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

सबडोमेन को कंसोलिडेट करना

एक और तरीका यह है कि अलग-अलग डिजिटल प्रॉपर्टी को, रजिस्टर किए जा सकने वाले एक ही रूट डोमेन (eTLD+1) के तहत लाकर, सभी डोमेन को एक साथ लाया जाए. इसके लिए, brand.example और service-app.example जैसे अलग-अलग डोमेन को, www.brand.example और service.brand.example जैसे सबडोमेन में बदला जाता है.

• फ़ायदे:
  • क्रेडेंशियल मैनेजमेंट को एक साथ लाना: पासवर्ड मैनेजर, रूट डोमेन को पहचान सकते हैं. साथ ही, सभी सबडोमेन को एक ही एंट्री के तौर पर मानते हैं. इससे, डुप्लीकेट सूचनाएं और पासवर्ड के लिए मैन्युअल एंट्री की ज़रूरत नहीं पड़ती.
  • पासकी की सुविधा को बनाए रखना: डेवलपर, रजिस्टर किए जा सकने वाले डोमेन के लिए, पासकी आरपी आईडी को स्वाभाविक तौर पर स्कोप कर सकते हैं. इससे, मिलते-जुलते सभी सबडोमेन पर पासकी की सुविधा तुरंत बढ़ जाती है. इस मामले में, brand.example का आरपी आईडी, www.brand.example और service.brand.example, दोनों पर काम करेगा.
  • सेशन को आसानी से शेयर करना: डोमेन स्ट्रक्चर को कंसोलिडेट करने से, वाइल्डकार्ड कुकी (उदाहरण के लिए, Domain=brand.example के लिए कुकी को स्कोप करना) का इस्तेमाल करके, एक ही सेशन को शेयर किया जा सकता है.
• नुकसान:
  • ब्रैंडिंग और माइग्रेशन से जुड़ी पाबंदियां: अगर आपका संगठन, अलग-अलग टॉप-लेवल डोमेन का इस्तेमाल करता है, तो इस तरीके से ब्रैंडिंग की सीमाएं लागू हो सकती हैं. माइग्रेशन की प्रोसेस जटिल होती है. इसके लिए, एचटीटीपी रीडायरेक्ट को ध्यान से मैनेज करना और लेगसी क्रॉस-ऑरिजिन कॉन्फ़िगरेशन को ठीक करना ज़रूरी होता है.

नतीजा

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

मिलते-जुलते विषयों के बारे में ज़्यादा जानने के लिए, हमारे ब्लॉग को फ़ॉलो करें. साथ ही, Chrome के आइडेंटिटी पोर्टल पर ज़्यादा संसाधन देखें.