मिलती-जुलती ऑरिजिन अनुरोधों की मदद से, अपनी सभी साइटों पर पासकी का फिर से इस्तेमाल करने की अनुमति दें

Maud Nalpas

ऑरिजिन से जुड़े अनुरोधों से हल होने वाली समस्या

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

इसकी जानकारी भरोसेमंद पक्ष के आईडी (आरपी आईडी) में दी जाती है. example.com डोमेन के लिए बनाई गई पासकी के लिए, यह आईडी www.example.com या example.com हो सकता है.

आरपी आईडी की मदद से, पासकी का इस्तेमाल हर जगह पुष्टि करने के लिए, एक क्रेडेंशियल के तौर पर नहीं किया जा सकता. हालांकि, इनसे ये समस्याएं आती हैं:

• एक से ज़्यादा डोमेन वाली साइटें: उपयोगकर्ता, एक ही कंपनी के मैनेज किए गए अलग-अलग देश के डोमेन (उदाहरण के लिए, example.com और example.co.uk) में साइन इन करने के लिए, एक ही पासकी का इस्तेमाल नहीं कर सकते.
• ब्रैंड वाले डोमेन: उपयोगकर्ता, एक ही ब्रैंड के इस्तेमाल किए गए अलग-अलग डोमेन (उदाहरण के लिए, acme.com और acmerewards.com) में एक ही क्रेडेंशियल का इस्तेमाल नहीं कर सकते.
• मोबाइल ऐप्लिकेशन: मोबाइल ऐप्लिकेशन का अक्सर अपना खुद का डोमेन नहीं होता है. इस वजह से, क्रेडेंशियल मैनेजमेंट मुश्किल हो जाता है.

आइडेंटिटी फ़ेडरेशन और iframes के आधार पर, समस्या हल करने के कुछ तरीके हैं. हालांकि, कुछ मामलों में ये तरीके काम के नहीं होते. मिलते-जुलते ऑरिजिन रिक्वेस्ट से समाधान मिलता है.

समाधान

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

इससे, उपयोगकर्ताओं को आपकी ओर से मैनेज की जा रही कई साइटों पर, एक ही पासकी का फिर से इस्तेमाल करने की सुविधा मिलती है.

मिलते-जुलते ऑरिजिन अनुरोधों का इस्तेमाल करने के लिए, आपको किसी खास यूआरएल https://{RP ID}/.well-known/webauthn पर एक खास JSON फ़ाइल देनी होगी. अगर example.com को अन्य ऑरिजिन को आरपी आईडी के तौर पर इस्तेमाल करने की अनुमति देनी है, तो उसे https://example.com/.well-known/webauthn: पर यह फ़ाइल दिखानी चाहिए

{
    "origins": [
        "https://example.co.uk",
        "https://example.de",
        "https://example-rewards.com"
    ]
}

अगली बार जब इनमें से कोई साइट, पासकी बनाने (navigator.credentials.create) या पुष्टि करने (navigator.credentials.get) के लिए कॉल करेगी, तो ब्राउज़र को एक ऐसा आरपी आईडी दिखेगा जो अनुरोध करने वाले ऑरिजिन से मेल नहीं खाता. इस आरपी आईडी में example.com का इस्तेमाल किया जाता है. अगर ब्राउज़र, मिलते-जुलते ऑरिजिन अनुरोधों के साथ काम करता है, तो वह सबसे पहले https://{RP ID}/.well-known/webauthn पर webauthn फ़ाइल खोजता है. अगर फ़ाइल मौजूद है, तो ब्राउज़र यह देखता है कि अनुरोध करने वाले ऑरिजिन को उस फ़ाइल में अनुमति दी गई है या नहीं. अगर ऐसा होता है, तो पासकी बनाने या पुष्टि करने की प्रोसेस शुरू हो जाती है. अगर ब्राउज़र, मिलते-जुलते ऑरिजिन अनुरोधों के साथ काम नहीं करता है, तो वह SecurityError दिखाता है.

ब्राउज़र समर्थन

• Chrome: यह सुविधा Chrome 128 से काम करती है.
• Safari: यह सुविधा macOS 15 बीटा 3 और मोबाइल पर iOS 18 बीटा 3 से काम करती है.
• Firefox: स्थिति का इंतज़ार किया जा रहा है.

मिलते-जुलते ऑरिजिन अनुरोधों को सेट अप करने का तरीका

नीचे दिए गए डेमो में दो साइटों, https://ror-1.glitch.me और https://ror-2.glitch.me के उदाहरण का इस्तेमाल किया गया है.
उपयोगकर्ता इन दोनों साइटों में एक ही पासकी से साइन इन कर सकें, इसके लिए यह मिलती-जुलती ऑरिजिन अनुरोधों का इस्तेमाल करता है. इससे ror-2.glitch.me, ror-1.glitch.me को अपने आरपी आईडी के तौर पर इस्तेमाल कर पाता है.

डेमो

https://ror-2.glitch.me, ror-1.glitch.me को आरपी आईडी के तौर पर इस्तेमाल करने के लिए, मिलते-जुलते ऑरिजिन अनुरोध लागू करता है. इसलिए, पासकी बनाने या उससे पुष्टि करने पर, ror-1 और ror-2, दोनों ror-1.glitch.me को आरपी आईडी के तौर पर इस्तेमाल करते हैं.
हमने इन साइटों पर, शेयर किए गए पासकी का डेटाबेस भी लागू किया है.

इस उपयोगकर्ता अनुभव को देखें:

• ror-2 पर पासकी बनाई जा सकती है और उसकी मदद से पुष्टि की जा सकती है. भले ही, उसका आरपी आईडी ror-1 हो, न कि ror-2.
• ror-1 या ror-2 में से किसी एक पर पासकी बनाने के बाद, ror-1 और ror-2, दोनों पर पुष्टि की जा सकती है. ror-2, ror-1 को आरपी आईडी के तौर पर बताता है. इसलिए, इनमें से किसी भी साइट से पासकी बनाने या पुष्टि करने का अनुरोध करना, ror-1 पर अनुरोध करने जैसा ही है. आरपी आईडी ही एक ऐसी चीज़ है जो किसी अनुरोध को ऑरिजिन से जोड़ती है.
• ror-1 या ror-2 में से किसी एक पर पासकी बनाने के बाद, Chrome उसे ror-1 और ror-2, दोनों पर अपने-आप भर सकता है.
• इनमें से किसी भी साइट पर बनाए गए क्रेडेंशियल का आरपी आईडी ror-1 होगा.

कोड देखें:

• ror-1 कोड बेस में सेट अप की गई ./well-known/webauthn फ़ाइल देखें.
• ror-2 कोड बेस में RP_ID_ROR बार होने की संख्या देखें.

पहला चरण: शेयर किया गया खाता डेटाबेस लागू करना

अगर आपको अपने उपयोगकर्ताओं को site-1 और site-2, दोनों साइटों पर एक ही पासकी से साइन इन करने की सुविधा देनी है, तो एक ऐसा खाता डेटाबेस लागू करें जो इन दोनों साइटों पर शेयर किया गया हो.

दूसरा चरण: साइट-1 में अपनी .well-known/webauthn JSON फ़ाइल सेट अप करना

सबसे पहले, site-1.com को इस तरह कॉन्फ़िगर करें कि site-2.com उसे RP आईडी के तौर पर इस्तेमाल कर सके. ऐसा करने के लिए, अपनी webauthn JSON फ़ाइल बनाएं:

{
    "origins": [
        "https://site-2.com"
    ]
}

JSON ऑब्जेक्ट में, नाम वाले ऐसे ऑरिजिन होने चाहिए जिनकी वैल्यू, वेब ऑरिजिन वाली एक या उससे ज़्यादा स्ट्रिंग की ऐरे हो.

अहम पाबंदी: ज़्यादा से ज़्यादा पांच लेबल

इस सूची के हर एलिमेंट को प्रोसेस करके, ईटीएलडी + 1 लेबल निकाला जाएगा. उदाहरण के लिए, example.co.uk और example.de के ईटीएलडी + 1 लेबल, दोनों example हैं. हालांकि, example-rewards.com का eTLD + 1 लेबल example-rewards है. Chrome में, ज़्यादा से ज़्यादा पांच लेबल बनाए जा सकते हैं.

तीसरा चरण: साइट-1 में अपना .well-known/webauthn JSON सबमिट करना

इसके बाद, site-1.com/.well-known/webauthn में अपनी JSON फ़ाइल दिखाएं.

उदाहरण के लिए, एक्सप्रेस में:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

यहां हम एक्सप्रेस res.json का इस्तेमाल कर रहे हैं, जो पहले से ही सही content-type ('application/json') सेट करता है;

चौथा चरण: साइट-2 में मनचाहे आरपी आईडी की जानकारी देना

अपने site-2 कोडबेस में, site-1.com को आरपी आईडी के तौर पर हर जगह सेट करें:

• क्रेडेंशियल बनाने पर:
  • क्रेडेंशियल बनाने के लिए, site-1.com को RP आईडी के तौर पर सेट करें. ये क्रेडेंशियल, navigator.credentials.create के फ़्रंटएंड कॉल में भेजे जाते हैं और आम तौर पर सर्वर साइड पर जनरेट होते हैं.
  • site-1.com को उम्मीद के मुताबिक आरपी आईडी के तौर पर सेट करें, क्योंकि इसे अपने डेटाबेस में सेव करने से पहले, क्रेडेंशियल की पुष्टि की जाती है.
• पुष्टि होने के बाद:
  • पुष्टि करने वाले options में site-1.com को RP आईडी के तौर पर सेट करें, जो navigator.credentials.get फ़्रंटएंड कॉल को पास किए जाते हैं और आम तौर पर सर्वर-साइड पर जनरेट किए जाते हैं.
  • site-1.com को सर्वर पर पुष्टि किए जाने वाले आरपी आईडी के तौर पर सेट करें, क्योंकि उपयोगकर्ता की पुष्टि करने से पहले, आपने क्रेडेंशियल की पुष्टि की है.

समस्या का हल

दूसरी ज़रूरी बातें

सभी साइटों और मोबाइल ऐप्लिकेशन पर पासकी शेयर करना

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

• Chrome में: डिजिटल ऐसेट लिंक. ज़्यादा जानने के लिए, डिजिटल ऐसेट लिंक के लिए सहायता जोड़ें पर जाएं.
• Safari में: जुड़े हुए डोमेन.

सभी साइटों पर पासवर्ड शेयर करना

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

क्रेडेंशियल मैनेजर और उपयोगकर्ता एजेंट की भूमिका

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