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

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. अगर 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 पर इंस्टॉल किया गया. अगर फ़ाइल मौजूद है, ब्राउज़र यह जांच करता है कि अनुरोध करने वाले ऑरिजिन को अनुमति मिली है या नहीं फ़ाइल से लिए जाते हैं. अगर ऐसा है, तो पासकी बनाने या पुष्टि करने के चरणों पर जाया जाता है. अगर ब्राउज़र मिलते-जुलते ऑरिजिन अनुरोधों के साथ काम नहीं करता, तो वह SecurityError दिखाता है.

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

• Chrome: यह Chrome के साथ काम करता है 128 हैं.
• Safari: macOS 15 beta 3 और मोबाइल iOS 18 beta 3 और इसके बाद के वर्शन पर काम करता है.
• फ़ायरफ़ॉक्स: स्थिति का इंतज़ार किया जा रहा है.

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

नीचे दिए गए डेमो में दो साइटों, 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 को प्रतिबंधित पार्टी का आईडी. ऐसा करने के लिए, अपनी webauthn JSON फ़ाइल बनाएं:

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

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

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

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

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

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

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

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

समस्या का हल

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

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

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

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

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

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

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

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