अलग-अलग सेक्टर के इंडस्ट्री लीडर यह समझते हैं कि सभी उपयोगकर्ताओं को शानदार अनुभव देने के साथ-साथ, उनकी निजता की सुरक्षा करना कितना ज़रूरी है. Seznam, उपयोगकर्ता को बेहतर अनुभव देने और उसकी निजता को सुरक्षित रखने के लिए प्रतिबद्ध है. इसने Federated Credential Management (FedCM) को इंटिग्रेट कर लिया है.
टारगेट प्रोफ़ाइलें: FedCM का इस्तेमाल करने वाली कंपनियां
अलग-अलग डोमेन के संगठनों ने, FedCM को अपने सलूशन के साथ इंटिग्रेट किया है. फ़ेडरेटेड आइडेंटिटी मैनेजमेंट के लिए FedCM को डिज़ाइन किया गया है. इसलिए, आइडेंटिटी प्रोवाइडर (आईडीपी) को इससे सबसे ज़्यादा फ़ायदा मिलता है. वे इसका इस्तेमाल, लॉगिन करने का बेहतर अनुभव देने के लिए करते हैं. ई-कॉमर्स की सेवा देने वाली कंपनियों और पेमेंट की सेवा देने वाली कंपनियों ने भी FedCM को लागू करके, उपयोगकर्ता अनुभव को बेहतर बनाने के मौकों की पहचान की है. इनमें से कई कंपनियां, पहचान की पुष्टि करने वाली कंपनियों के तौर पर भी काम करती हैं.
Seznam
Seznam, यूरोप की एक टेक्नोलॉजी कंपनी है. यह पहचान की पुष्टि करने वाली सेवा देती है. इसकी पहुंच, चेक गणराज्य की 90% आबादी तक है. यह एक सोशल, नॉलेज, और कॉन्टेंट हब के तौर पर काम करता है. Seznam ने FedCM को अपनाया है, ताकि उसके पार्टनर के प्लैटफ़ॉर्म पर काम करने वाली ऑनलाइन दुकानों के ग्राहक, अपने Seznam खाते का इस्तेमाल करके साइन इन कर सकें.
FedCM की मदद से, Seznam को अपने पार्टनर के नेटवर्क पर उपयोगकर्ताओं के साइन-इन करने की दरों में काफ़ी बढ़ोतरी देखने को मिली. साथ ही, उपयोगकर्ताओं को बेहतर अनुभव मिला. इसके अलावा, तीसरे पक्ष की कुकी की उपलब्धता के बावजूद, पहचान की पुष्टि करने की प्रोसेस में कोई बदलाव नहीं हुआ.
वजह
Seznam ने FedCM को लागू करने का फ़ैसला इसलिए लिया, क्योंकि उन्हें इसके कई फ़ायदों के बारे में पता था:
- FedCM को असली उपयोगकर्ता को ध्यान में रखकर डिज़ाइन किया गया है. इससे उपयोगकर्ता को यह कंट्रोल मिलता है कि वह आईडीपी को कौनसी जानकारी दे. इससे Seznam के उपयोगकर्ताओं को सुरक्षित और निजी माहौल देने के विज़न को पूरा करने में मदद मिलती है.
- FedCM, ब्राउज़र में पहले से मौजूद एक सुविधा है. यह Seznam के मौजूदा लॉगिन सिस्टम के साथ काम करती है. यह सिस्टम, OAuth 2.0 स्टैंडर्ड का इस्तेमाल करता है.
- FedCM को आइडेंटिटी फ़ेडरेशन के लिए, निजता पर आधारित नज़रिया रखने के लिए डिज़ाइन किया गया है. उदाहरण के लिए, अगर उपयोगकर्ता साइन इन करने का विकल्प चुनता है, तो ही यह जानकारी आईडीपी (IdP) के साथ शेयर की जाती है कि उपयोगकर्ता ने आरपी (RP) पर विज़िट किया है. यह, Seznam के टिकाऊ कारोबार के नज़रिए के मुताबिक है.
क्रियान्वयन विवरण
Seznam ने FedCM को अपने मौजूदा OAuth समाधान के ऊपर एक लेयर के तौर पर लागू किया. इस आर्किटेक्चर में, FedCM फ़्लो का इस्तेमाल किया जाता है. इससे, IdP से आरपी को OAuth ऑथराइज़ेशन कोड सुरक्षित तरीके से भेजा जा सकता है.
लागू करने में लगने वाला समय
Seznam ने बताया कि FedCM को लागू करना आसान था. यह उनके मौजूदा तरीके के मुताबिक था. उन्होंने एक महीने तक रिसर्च की और एपीआई को लागू किया. इसके लिए, दो डेवलपर की ज़रूरत पड़ी. उन्हें FedCM को प्रोडक्शन में लाने में दो महीने से भी कम समय लगा. यह एक दोहराई जाने वाली प्रोसेस थी. इसमें एपीआई को ध्यान से समझने में काफ़ी समय लगा.
चुनौतियां
Seznam ने इस एपीआई को सबसे पहले इस्तेमाल किया. इस दौरान, उसे कई चुनौतियों का सामना करना पड़ा. उसने हमें अहम सुझाव दिए, जिनकी मदद से हम इस एपीआई को बेहतर बना पाए.
पहचान देने वाली एक से ज़्यादा सेवाओं के साथ काम करता है
Seznam को FedCM की इस सुविधा में दिलचस्पी थी कि यह एक से ज़्यादा आइडेंटिटी प्रोवाइडर के साथ काम करता है. इस सुविधा के ज़रिए, Seznam का मकसद उपयोगकर्ताओं को अपने पार्टनर के आरपी पर Seznam या Google खातों में से किसी एक को चुनने की अनुमति देना था. हालांकि, जब Seznam ने पहली बार FedCM को लागू करने के लिए संपर्क किया था, तब यह सुविधा शुरुआती चरण में थी. साथ ही, डेवलपर को ओरिजिन ट्रायल के लिए साइन अप करना पड़ा था. इसके अलावा, उन्हें टोकन का इस्तेमाल करके, उपयोगकर्ताओं के लिए इस सुविधा को चालू करना पड़ा था. इस वजह से, Seznam ने इस सुविधा को Chrome के स्टेबल वर्शन में उपलब्ध होने तक इंतज़ार करने का फ़ैसला किया.
यह सुविधा Chrome 136 से उपलब्ध है. साथ ही, डेवलपर एक से ज़्यादा पहचान देने वाली कंपनियों के लिए, इस सुविधा को कॉन्फ़िगर कर सकते हैं. उदाहरण के लिए, Seznam और Google, दोनों आइडेंटिटी प्रोवाइडर (IdP) के साथ काम करने के लिए, IdP एक ही get() कॉल में दोनों प्रोवाइडर को शामिल कर सकता है. साथ ही, आरपी भी ऐसा अलग से कर सकता है:
// Executed on the RP's side:
const credential = await navigator.credentials.get({
identity: {
providers: [
{
// IdP1: Seznam's config file URL
configURL: 'https://szn.cz/.well-known/web-identity',
clientId: '123',
},
{
// Also allow Google Sign-in
configURL: 'https://accounts.google.com/gsi/fedcm.json',
clientId: '456',
},
],
},
});
Seznam ने बताया है कि यह सुविधा उनके समाधान का हिस्सा होगी. इसके अलावा, FedCM टीम एक से ज़्यादा SDK के साथ काम करने की सुविधा लागू कर रही है. साथ ही, एक से ज़्यादा get() कॉल के साथ काम करने की सुविधा भी लागू कर रही है.
निजी डीएनएस
जांच के दौरान, Seznam को नेटवर्क कॉन्फ़िगरेशन से जुड़ी समस्या का सामना करना पड़ा. उनका टेस्ट IdP सर्वर, निजी नेटवर्क में मौजूद था. इसे सिर्फ़ निजी डीएनएस के ज़रिए ऐक्सेस किया जा सकता था. यह सेटअप, इंटरनल टेस्टिंग और डेवलपमेंट एनवायरमेंट के लिए आम है. ऐसा तब किया जाता है, जब सेवाओं को सार्वजनिक तौर पर उपलब्ध कराने से पहले उनकी जांच करनी हो.
हालांकि, इस सेटअप से एक समस्या आती है: well-known फ़ाइल को eTLD+1 से सर्व किया जाना चाहिए. साथ ही, निजी डेवलपमेंट डोमेन को सार्वजनिक सफ़िक्स सूची में रजिस्टर नहीं किया जाता है. इसलिए, ब्राउज़र डेवलपमेंट डोमेन पर होस्ट की गई well-known फ़ाइल को फ़ेच करने के लिए अनुरोध नहीं भेजेगा:
login.idp.example: प्रोडक्शन डोमेन का उदाहरण.idp.example/.well-known/web-identity: प्रोडक्शन में मौजूद well-known फ़ाइल का उदाहरण.login.dev.idp.example: उदाहरण के लिए डेवलपमेंट डोमेन.login.dev.idp.example/.well-known/web-identity: डेवलपमेंट एनवायरमेंट में .well-known फ़ाइल का उदाहरण.
जब FedCM को किसी निजी डोमेन पर होस्ट किया जाता है, तब ब्राउज़र के well-known
फ़ाइल के अनुरोध पर यह गड़बड़ी दिखती है:
The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED
इस गड़बड़ी को ठीक करने के लिए, Chrome #fedcm-without-well-known-enforcement फ़्लैग चालू करें. इस फ़्लैग के चालू होने पर, ब्राउज़र जांच के लिए well-known फ़ाइल को फ़ेच नहीं करता. Chrome में टेस्टिंग फ़्लैग चालू करने का तरीका जानें.
अपनी पसंद के मुताबिक जानकारी ज़ाहिर करना
Seznam ने यह भी बताया कि वह FedCM यूज़र इंटरफ़ेस (यूआई) के शुरुआती डिज़ाइन के साथ-साथ, ज़्यादा जानकारी भी शामिल करना चाहता है. FedCM का स्टैंडर्ड डायलॉग, उपयोगकर्ता को एक तय मैसेज दिखाता है. इसमें बताया जाता है कि कुछ डेटा, जैसे कि उपयोगकर्ता की प्रोफ़ाइल इमेज, नाम, और ईमेल पता, आरपी के साथ शेयर किया जा रहा है.
FedCM टीम ने सुझाव, शिकायत या राय को शामिल किया और एपीआई को इस तरह से बढ़ाया कि उपयोगकर्ता को दिखाई गई जानकारी को पसंद के मुताबिक बनाया जा सके. उदाहरण के लिए, जारी रखें सुविधा की मदद से, IdP उपयोगकर्ता को कस्टम पेज पर रीडायरेक्ट कर सकता है, ताकि वह अतिरिक्त जानकारी या अनुमतियों का अनुरोध कर सके. कस्टम पैरामीटर और फ़ील्ड की सुविधाओं को Chrome 132 से इस्तेमाल किया जा सकता है. इनकी मदद से, Chrome को अपनी पसंद के मुताबिक बनाया जा सकता है.
रिलाइंग पार्टी के ऑरिजिन की पुष्टि करना
आईडीपी सर्वर को, FedCM के किसी भी अनुरोध के लिए Origin एचटीटीपी हेडर की पुष्टि करनी होगी. इससे यह पक्का किया जा सकेगा कि अनुरोध उस ऑरिजिन से भेजा गया है जिसे आरपी ने आईडीपी के साथ पहले से रजिस्टर किया है. इससे यह पक्का किया जाता है कि FedCM आईडी असर्शन का अनुरोध किसी ऐसे आरपी से आ रहा है जिसे अनुमति मिली है. यह अनुरोध, client_id का इस्तेमाल करने वाले किसी हमलावर से नहीं आ रहा है.
Seznam के साथ एक खास समस्या है: जब उनके पार्टनर आरपी, Seznam के साथ रजिस्टर करते हैं, तो वे आरपी के ऑरिजिन डेटा का अनुरोध नहीं करते हैं. इसका मतलब है कि आरपी के ऑरिजिन की पुष्टि नहीं की जा सकती.
Seznam का FedCM इंटिग्रेशन, मौजूदा OAuth सलूशन पर आधारित है. उन्होंने आरपी के client_id और client_secret, दोनों की पुष्टि करने का दूसरा तरीका अपनाया. इससे यह पक्का किया जा सका कि समाधान सुरक्षित रहे और ओरिजन की जांच करने की ज़रूरत न पड़े.
उपयोगकर्ता के लिए आइडेंटिटी प्रोवाइडर का डोमेन
Seznam का उपयोगकर्ता की पुष्टि करने वाला इन्फ़्रास्ट्रक्चर, मुख्य रूप से szn.cz डोमेन पर काम करता है. इस डोमेन पर, FedCM के लिए ज़रूरी आईडीपी एंडपॉइंट होस्ट किए जाते हैं. हालांकि, उनकी मुख्य कॉर्पोरेट पहचान और वह डोमेन जिसके तहत उपयोगकर्ता उनकी सेवाओं को पहचानते हैं और उन पर भरोसा करते हैं, seznam.cz है.
FedCM डायलॉग में, IdP एंडपॉइंट का असली ऑरिजिन डोमेन दिखता है. इस मामले में, यह szn.cz है.
seznam.cz ब्रैंड के बारे में जानने वाले उपयोगकर्ताओं को भ्रम हो सकता है. साथ ही, लॉगिन प्रोसेस के दौरान कम जाने-पहचाने szn.cz डोमेन से साइन इन करने के लिए कहे जाने पर, वे हिचकिचा सकते हैं.
Chrome 141 के मुताबिक, FedCM में IdP लागू करने वाले डोमेन के अलावा किसी दूसरे डोमेन को दिखाने की अनुमति नहीं है. यह पाबंदी, जान-बूझकर डिज़ाइन की गई है. इसका मकसद, उपयोगकर्ता के लिए पारदर्शिता बनाए रखना है. हालांकि, FedCM टीम को पता है कि इस सीमा की वजह से समस्याएं आ सकती हैं. इसलिए, वह इसमें संभावित बदलावों पर बातचीत कर रही है.
असर
FedCM API की मदद से, Seznam अब अपने पार्टनर के उपयोगकर्ताओं को सिंगल टैप ऑथराइज़ेशन फ़्लो उपलब्ध करा सकता है. उन्होंने पुष्टि करने के अन्य तरीकों की तुलना में, FedCM के यूज़र एक्सपीरियंस (यूएक्स) के फ़ायदों के बारे में बताया.
Seznam ने बताया कि जिन वेबसाइटों ने FedCM लॉगिन पर स्विच किया है उन पर उपयोगकर्ता जुड़ाव में काफ़ी बढ़ोतरी हुई है. हालांकि, उन्होंने अन्य फ़ैक्टर से सीधे तौर पर पड़ने वाले असर का पता लगाने के लिए, पूरी तरह से विश्लेषण नहीं किया. FedCM इंटिग्रेट करने से पहले, मेहमान के तौर पर चेकआउट करने की सुविधा उपलब्ध थी. इसमें उपयोगकर्ता की पहचान करने के लिए, सहमति वाले हैश किए गए ईमेल का इस्तेमाल किया जाता था. इस तरह का विश्लेषण करने में यह चुनौती थी कि यह अनुमान लगाया जाए कि क्या उपयोगकर्ता का कन्वर्ज़न, FedCM की वजह से हुआ है या उपयोगकर्ता ने बिना लॉग-इन के खरीदारी की है. Seznam के अनुमान के मुताबिक, FedCM के इस्तेमाल में आसानी होने की वजह से, कन्वर्ज़न रेट में बढ़ोतरी हुई है.
नतीजा
Seznam ने FedCM को सफलतापूर्वक लागू किया है. इससे, उन्हें अपने मौजूदा OAuth समाधान के साथ-साथ, ऑथराइज़ेशन का एक वैकल्पिक फ़्लो उपलब्ध कराने में मदद मिली है. Seznam के डेवलपर को आइडेंटिटी प्रोवाइडर के सपोर्ट, निजी डीएनएस सेटअप, डिसक्लोज़र टेक्स्ट को पसंद के मुताबिक बनाने, रिलाइंग पार्टी के ऑरिजिन की पुष्टि करने, और उपयोगकर्ता को दिखने वाले डोमेन को दिखाने से जुड़ी कुछ समस्याओं का सामना करना पड़ा. हालांकि, एपीआई को लागू करने के बाद से, इसमें सुधार हुआ है. FedCM टीम ने Seznam और अन्य शुरुआती उपयोगकर्ताओं से मिले सुझावों को शामिल किया है. इससे इन चुनौतियों को हल करने के लिए बेहतर टूल उपलब्ध कराए जा सकेंगे. अगले चरण के तौर पर, Seznam का प्लान FedCM को कई आइडेंटिटी प्रोवाइडर के साथ काम करने की सुविधा देना है.