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

Maud Nalpas

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

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

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

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

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

समाधान

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

इससे उपयोगकर्ता, आपकी अलग-अलग साइटों पर एक ही पासकी का दोबारा इस्तेमाल कर सकते हैं.

'मिलते-जुलते ऑरिजिन से किए गए अनुरोध' सुविधा का इस्तेमाल करने के लिए, आपको किसी खास यूआरएल 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 को आरपी आईडी के तौर पर इस्तेमाल करती है, तो ब्राउज़र को एक ऐसा आरपी आईडी दिखेगा जो अनुरोध करने वाले ऑरिजिन से मेल नहीं खाता. अगर ब्राउज़र, मिलते-जुलते ऑरिजिन से किए गए अनुरोधों का समर्थन करता है, तो वह सबसे पहले webauthn पर https://{RP ID}/.well-known/webauthn फ़ाइल ढूंढता है. अगर फ़ाइल मौजूद है, तो ब्राउज़र यह जांच करता है कि अनुरोध करने वाला ऑरिजिन, allowlist पर है या नहीं. अगर जवाब हां है, तो पासकी बनाने या पुष्टि करने के चरणों पर जाएं.

अगर ब्राउज़र, मिलते-जुलते ऑरिजिन के अनुरोधों के साथ काम नहीं करता है, तो वह SecurityError दिखाता है.

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

'एक ही ऑरिजिन से जुड़े अनुरोध' की सुविधा, Chrome और Safari पर काम करती है. जनवरी 2026 तक, Firefox इस सुविधा पर अब भी विचार कर रहा है. Mozilla standards position issue में जाकर, इसके स्टेटस को ट्रैक किया जा सकता है.

'मिलते-जुलते ऑरिजिन से किए गए अनुरोध' सुविधा सेट अप करना

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

डेमो

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

उपयोगकर्ता अनुभव के बारे में यहां बताया गया है:

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

कोड देखें:

• ror-1 codebase में सेट अप की गई /.well-known/webauthn फ़ाइल देखें.
• ror-2 codebase में RP_ID_ROR के उदाहरण देखें.

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

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

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

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

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

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

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

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

तीसरा चरण: site-1 में .well-known/webauthn JSON फ़ाइल को उपलब्ध कराएं

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

उदाहरण के लिए, Express में:

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

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

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

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

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

समस्या का हल

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

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

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

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

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

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

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

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