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