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

Maud Nalpas
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 दिखाता है.

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

इस डेमो में, दो साइटों 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 होगा.
Chrome, दोनों साइटों पर जानकारी को ऑटोमैटिक भरता है.
मिलते-जुलते ऑरिजिन अनुरोधों की मदद से, उपयोगकर्ता ror-1 और ror-2 में एक ही पासकी क्रेडेंशियल का इस्तेमाल कर सकते हैं. Chrome, क्रेडेंशियल भी अपने-आप भर देगा.

कोड देखें:

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

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

समस्या का हल

Chrome में गड़बड़ी का मैसेज पॉप-अप.
क्रेडेंशियल बनाने पर, Chrome में गड़बड़ी का मैसेज. यह गड़बड़ी तब दिखती है, जब `https://{RP ID}/.well-known/webauthn` पर आपकी `.well-known/webauthn` फ़ाइल नहीं मिलती.
Chrome में गड़बड़ी का मैसेज पॉप-अप.
क्रेडेंशियल बनाने पर, Chrome में गड़बड़ी का मैसेज. यह गड़बड़ी तब दिखती है, जब आपकी `.well-known/webauthn` फ़ाइल मिल जाती है, लेकिन उसमें उस ऑरिजिन की जानकारी नहीं होती जिससे क्रेडेंशियल बनाया जा रहा है.

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

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

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

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

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

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

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