WebAuthn Related Origins: क्रॉस-डोमेन Passkey गाइड

Passkeys सुरक्षित और उपयोगकर्ता-अनुकूल प्रमाणीकरण के लिए नया मानक हैं। FIDO/WebAuthn मानकों पर बने, वे फ़िशिंग और क्रेडेंशियल स्टफिंग के प्रति स्वाभाविक प्रतिरोध प्रदान करने के लिए पब्लिक-की क्रिप्टोग्राफी का लाभ उठाते हैं, जिससे उपयोगकर्ताओं के लिए लॉगिन अनुभव को सरल बनाते हुए सुरक्षा स्थिति में नाटकीय रूप से सुधार होता है। संगठनों के लिए, इसका मतलब ठोस व्यावसायिक लाभ है: पासवर्ड रीसेट और SMS OTP से परिचालन लागत में कमी, अकाउंट टेकओवर धोखाधड़ी से वित्तीय जोखिमों में कमी और उच्च कन्वर्ज़न रेट्स के माध्यम से राजस्व में वृद्धि।

हालांकि, WebAuthn की सबसे बड़ी सुरक्षा शक्तियों में से एक - इसकी सख्त, ऑरिजिन-बाध्य प्रकृति - विविध डिजिटल पदचिह्नों वाले वैश्विक ब्रांडों और कंपनियों के लिए एक महत्वपूर्ण वास्तविक दुनिया की चुनौती पैदा करती है। डिज़ाइन के अनुसार, एक विशिष्ट वेब डोमेन के लिए बनाया गया Passkey उस डोमेन के लिए क्रिप्टोग्राफ़िक रूप से लॉक होता है, जो एक मौलिक सिद्धांत है जो फ़िशिंग हमलों को रोकता है। जबकि यह एक शक्तिशाली सुरक्षा सुविधा है, यह एक खंडित और भ्रामक उपयोगकर्ता अनुभव की ओर ले जाती है जब एक ही ब्रांड कई डोमेन पर काम करता है।

इस चुनौती का एक प्रमुख उदाहरण Twitter की X के रूप में रीब्रांडिंग है। एक उपयोगकर्ता जिसने twitter.com पर Passkey बनाया था, वह इसे x.com पर अनुपयोगी पाएगा, जिससे कंपनी को बोझिल रीडायरेक्ट लागू करने या उपयोगकर्ताओं को फिर से नामांकन करने की आवश्यकता होगी, जिससे घर्षण पैदा होगा जो सीधे तौर पर अपनाने में बाधा डालता है। यह कोई अकेली समस्या नहीं है। Amazon जैसी बड़ी कंपनियाँ amazon.com, amazon.de और amazon.co.uk जैसे कई कंट्री-कोड टॉप-लेवल डोमेन (ccTLDs) पर काम करती हैं, जो सभी एक सामान्य उपयोगकर्ता खाता प्रणाली साझा करते हैं। Passkey से पहले की दुनिया में, पासवर्ड मैनेजर इस जटिलता को कुशलता से संभालते हैं, लेकिन WebAuthn के डिफ़ॉल्ट व्यवहार के लिए प्रत्येक डोमेन के लिए एक अलग Passkey की आवश्यकता होगी, जिससे उपयोगकर्ता निराश होंगे और एक सहज लॉगिन के वादे को कमज़ोर किया जाएगा।

इस महत्वपूर्ण अपनाने वाले अवरोधक को हल करने के लिए, W3C ने WebAuthn मानक में एक नई सुविधा पेश की है: Related Origin Requests (ROR)। यह शक्तिशाली तंत्र विश्वसनीय डोमेन के एक सेट के लिए एक मानकीकृत, सुरक्षित तरीका प्रदान करता है ताकि एक ही Passkey को साझा किया जा सके, जिससे एक ब्रांड के पूरे डिजिटल इकोसिस्टम में एक एकीकृत और सहज प्रमाणीकरण अनुभव बनाया जा सके। यह गहन पड़ताल ROR की तकनीकी नींव की खोज करती है, इसके कार्यान्वयन के लिए एक व्यावहारिक मार्गदर्शिका प्रदान करती है और आधुनिक प्रमाणीकरण वास्तुकला के लिए इसके रणनीतिक प्रभावों का विश्लेषण करती है।

ROR की शुरूआत WebAuthn मानक की एक महत्वपूर्ण परिपक्वता का प्रतीक है। प्रारंभिक विनिर्देशों ने मुख्य क्रिप्टोग्राफ़िक और सुरक्षा सिद्धांतों की स्थापना को प्राथमिकता दी, जिसमें एक क्रेडेंशियल को Relying Party ID (rpID) से सख्ती से बांधना इसके एंटी-फ़िशिंग डिज़ाइन का एक आधार था। जैसे-जैसे Amazon और Google जैसी कंपनियों द्वारा बड़े पैमाने पर एंटरप्राइज़ परिनियोजन एक वास्तविकता बन गया, इस कठोरता के कारण होने वाला व्यावहारिक घर्षण स्पष्ट हो गया। यह घर्षण उच्च उपयोगकर्ता अपनाने को प्राप्त करने में एक सीधी बाधा है, जो किसी भी Passkey परियोजना के लिए सफलता का अंतिम उपाय है। ROR का विकास इस एंटरप्राइज़ फ़ीडबैक की सीधी प्रतिक्रिया है, जो मानक के एक व्यावहारिक विकास को प्रदर्शित करता है। यह स्वीकार करता है कि एक सुरक्षा प्रोटोकॉल को व्यापक सफलता प्राप्त करने के लिए, इसकी उपयोगिता को इसे तैनात करने वाले संगठनों की जटिल व्यावसायिक वास्तविकताओं और ब्रांडिंग रणनीतियों को समायोजित करने के लिए मापना चाहिए।

यह व्यापक मार्गदर्शिका WebAuthn Related Origin Requests को लागू करने के लिए पाँच महत्वपूर्ण प्रश्नों का उत्तर देती है:

1. Passkeys कई डोमेन पर विफल क्यों होते हैं? WebAuthn के ऑरिजिन-बाध्य सुरक्षा मॉडल और इसके वास्तविक दुनिया के घर्षण बिंदुओं को समझना
2. Related Origin Requests तकनीकी रूप से कैसे काम करते हैं? ब्राउज़र सत्यापन प्रवाह और .well-known URI तंत्र में गहन पड़ताल
3. ROR को लागू करने के लिए क्या आवश्यक है? व्यावहारिक कोड उदाहरणों के साथ चरण-दर-चरण सर्वर और क्लाइंट-साइड कॉन्फ़िगरेशन
4. आपको ROR को फ़ेडरेटेड लॉगिन पर कब चुनना चाहिए? ROR की OIDC/SAML दृष्टिकोणों से तुलना करने वाला रणनीतिक निर्णय ढाँचा
5. आप ब्राउज़र संगतता और सुरक्षा विचारों को कैसे संभालते हैं? वर्तमान समर्थन मैट्रिक्स और सुरक्षा सर्वोत्तम अभ्यास

अधिक तकनीकी विवरण के लिए, आधिकारिक WebAuthn Related Origin Requests Explainer देखें।

Related Origin Requests समाधान की सुंदरता की पूरी तरह से सराहना करने के लिए, पहले उन अंतर्निहित तकनीकी अवधारणाओं को समझना आवश्यक है जो इसके अस्तित्व को आवश्यक बनाती हैं: वेब की सेम-ऑरिजिन पॉलिसी और WebAuthn की Relying Party ID (rpID) स्कोपिंग नियम। ये तंत्र वेब सुरक्षा के लिए मौलिक हैं लेकिन वही घर्षण पैदा करते हैं जिसे ROR कम करने के लिए डिज़ाइन किया गया है।

एक वेब "ऑरिजिन" एक महत्वपूर्ण सुरक्षा अवधारणा है जिसे प्रोटोकॉल (जैसे, https), डोमेन (जैसे, app.example.com) और पोर्ट (जैसे, 443) के अद्वितीय संयोजन द्वारा परिभाषित किया गया है जहाँ से सामग्री परोसी जाती है। सेम-ऑरिजिन पॉलिसी ब्राउज़रों द्वारा लागू किया गया एक सुरक्षा तंत्र है जो यह प्रतिबंधित करता है कि एक ऑरिजिन से लोड की गई स्क्रिप्ट दूसरे से किसी संसाधन के साथ कैसे इंटरैक्ट कर सकती है। यह वेब सुरक्षा का एक महत्वपूर्ण तत्व है, जो संभावित रूप से दुर्भावनापूर्ण दस्तावेज़ों को प्रभावी ढंग से अलग करता है और एक धोखाधड़ी वाली वेबसाइट को, उदाहरण के लिए, दूसरे टैब में उपयोगकर्ता के प्रमाणित वेबमेल सत्र से संवेदनशील डेटा पढ़ने से रोकता है।

WebAuthn इकोसिस्टम में, "Relying Party" (RP) वह वेबसाइट या एप्लिकेशन है जिसके साथ उपयोगकर्ता प्रमाणित करने का प्रयास कर रहा है। प्रत्येक Passkey अपने निर्माण के समय एक Relying Party ID (rpID) से क्रिप्टोग्राफ़िक रूप से बंधा होता है। rpID एक डोमेन नाम है जो उस क्रेडेंशियल के लिए दायरे और सीमा को परिभाषित करता है।

डिफ़ॉल्ट रूप से, rpID उस ऑरिजिन का प्रभावी डोमेन है जहाँ Passkey बनाया जा रहा है। WebAuthn के स्कोपिंग नियम एक ऑरिजिन को एक rpID सेट करने की अनुमति देते हैं जो या तो अपने स्वयं के डोमेन के बराबर है या एक रजिस्ट्रार करने योग्य डोमेन प्रत्यय है। उदाहरण के लिए, https://www.accounts.example.co.uk पर चलने वाली एक स्क्रिप्ट निम्नलिखित में से किसी एक rpID के साथ एक Passkey बना सकती है:

• www.accounts.example.co.uk (पूरा डोमेन)
• accounts.example.co.uk
• example.co.uk

यह लचीलापन एक सबडोमेन पर बनाए गए Passkey को उसी पैरेंट डोमेन के अन्य सबडोमेन में उपयोग करने की अनुमति देता है, जो एक सामान्य और आवश्यक पैटर्न है। हालांकि, नियम सख्ती से एक rpID सेट करने से रोकते हैं जो एक प्रत्यय नहीं है। www.accounts.example.co.uk पर वही स्क्रिप्ट example.com के rpID के साथ एक Passkey नहीं बना सकती है, क्योंकि .com एक अलग टॉप-लेवल डोमेन है।

यह सख्त बाइंडिंग एक महत्वपूर्ण उद्देश्य पूरा करती है: डोमेन स्कोप द्वारा क्रेडेंशियल्स को अलग करना। mybank.com के लिए बनाया गया एक Passkey phishing-site.com पर नहीं चलाया जा सकता क्योंकि दुर्भावनापूर्ण साइट mybank.com के वैध rpID का दावा नहीं कर सकती है। ब्राउज़र Passkey को एक विकल्प के रूप में भी प्रस्तुत नहीं करेगा।

हालांकि, rpID स्वयं प्राथमिक एंटी-फ़िशिंग नियंत्रण नहीं है। WebAuthn की फ़िशिंग सुरक्षा वास्तव में clientDataJSON ऑब्जेक्ट में ऑरिजिन सत्यापन से आती है। प्रत्येक WebAuthn समारोह के दौरान, ब्राउज़र एक JSON ऑब्जेक्ट बनाता है जिसमें महत्वपूर्ण संदर्भ होता है, जिसमें अनुरोध शुरू करने वाला सटीक ऑरिजिन भी शामिल है। यह पूरा ऑब्जेक्ट फिर प्रमाणक की निजी कुंजी द्वारा क्रिप्टोग्राफ़िक रूप से हस्ताक्षरित होता है। सर्वर (Relying Party) को इस हस्ताक्षर को सत्यापित करना होगा और, महत्वपूर्ण रूप से, यह मान्य करना होगा कि हस्ताक्षरित clientDataJSON में ऑरिजिन फ़ील्ड एक अपेक्षित, विश्वसनीय मान से मेल खाता है। यह ऑरिजिन सत्यापन ही है जो फ़िशिंग हमलों को रोकता है।

Related Origin Requests के साथ, rpID स्कोपिंग में ढील दी जाती है—जिससे bar.com को ब्राउज़र द्वारा .well-known/webauthn फ़ाइल को मान्य करने के बाद foo.com के rpID का वैध रूप से दावा करने की अनुमति मिलती है—लेकिन ऑरिजिन सत्यापन की आवश्यकता अपरिवर्तित रहती है। clientDataJSON अभी भी सच्चाई से ऑरिजिन को bar.com के रूप में रिपोर्ट करेगा। foo.com पर सर्वर इस हस्ताक्षरित डेटा को प्राप्त करता है, इसे सत्यापित करता है, और देखता है कि अनुरोध bar.com से आया है। प्रमाणीकरण स्वीकार करने से पहले सर्वर को यह जांचना होगा कि bar.com एक अपेक्षित संबंधित ऑरिजिन है। यह एक बहु-स्तरीय दृष्टिकोण प्रदर्शित करता है जो ऑरिजिन सत्यापन के मूल सिद्धांत का त्याग किए बिना अधिक लचीलेपन की अनुमति देता है।

Related Origin Requests तंत्र डोमेन के लिए Passkeys साझा करने के उद्देश्य से एक विश्वास संबंध को सार्वजनिक रूप से घोषित करने का एक सुंदर और मानकीकृत तरीका प्रस्तुत करता है। यह एक सुस्थापित वेब पैटर्न का लाभ उठाता है—/.well-known/ URI एक सत्यापन योग्य और मशीन-पठनीय "अलाउलिस्ट" बनाने के लिए जिसे ब्राउज़र परामर्श कर सकते हैं।

मूल अवधारणा सीधी है: एक डोमेन जो संबंधित साइटों के एक सेट के लिए प्राथमिक, कैनोनिकल rpID के रूप में कार्य करता है, एक मानकीकृत, "वेल-नोन" URL पर एक विशेष JSON फ़ाइल होस्ट कर सकता है: https://{rpID}/.well-known/webauthn। यह फ़ाइल एक सार्वजनिक मैनिफ़ेस्ट के रूप में कार्य करती है, जो स्पष्ट रूप से उन सभी अन्य ऑरिजिन को सूचीबद्ध करती है जो उस प्राथमिक rpID के तहत Passkeys बनाने और उपयोग करने के लिए आधिकारिक तौर पर अधिकृत हैं।

ब्राउज़र का सत्यापन प्रवाह तब शुरू होता है जब भी उसे वर्तमान ऑरिजिन और अनुरोधित rpID के बीच एक बेमेल का सामना करना पड़ता है:

1. एक "संबंधित" साइट पर एक उपयोगकर्ता, जैसे कि https://example.co.uk, एक Passkey ऑपरेशन (निर्माण या प्रमाणीकरण) शुरू करता है जहाँ क्लाइंट-साइड कोड एक अलग डोमेन को rpID के रूप में निर्दिष्ट करता है, उदाहरण के लिए, example.com।
2. ब्राउज़र इस बेमेल का पता लगाता है। पुराने नियमों के तहत, इसका परिणाम तुरंत एक SecurityError होता।
3. ROR समर्थन के साथ, ब्राउज़र, विफल होने से पहले, दावा किए गए rpID के वेल-नोन URL पर एक सुरक्षित HTTPS GET अनुरोध करता है: https://example.com/.well-known/webauthn। यह अनुरोध उपयोगकर्ता क्रेडेंशियल्स (जैसे कुकीज़) के बिना और उपयोगकर्ता गोपनीयता की रक्षा करने और ट्रैकिंग को रोकने के लिए एक रेफरर हेडर के बिना किया जाता है।
4. ब्राउज़र सर्वर से JSON प्रतिक्रिया प्राप्त करता है। यह फ़ाइल को पार्स करता है और जाँचता है कि क्या वर्तमान ऑरिजिन (https://example.co.uk) JSON ऑब्जेक्ट के भीतर ऑरिजिन सरणी में मौजूद है।
5. यदि ऑरिजिन अलाउलिस्ट में पाया जाता है, तो WebAuthn ऑपरेशन को example.com को वैध rpID के रूप में उपयोग करके आगे बढ़ने की अनुमति दी जाती है। यदि ऑरिजिन नहीं पाया जाता है, या यदि फ़ाइल गायब है या विकृत है, तो ऑपरेशन विफल हो जाता है जैसा कि यह पहले होता।

/.well-known/ URI का उपयोग करने का विकल्प जानबूझकर किया गया है और ROR को सेवा खोज और डोमेन नियंत्रण सत्यापन के लिए स्थापित वेब मानकों के साथ संरेखित करता है। यह URI पथ, RFC 8615 द्वारा परिभाषित, पहले से ही कई महत्वपूर्ण प्रोटोकॉल द्वारा उपयोग किया जाता है, जिसमें Let's Encrypt SSL प्रमाणपत्र जारी करने के लिए acme-challenge और वेबसाइटों को Android एप्लिकेशन से जोड़ने के लिए assetlinks.json शामिल है। इस परंपरा को अपनाकर, W3C एक ऐसे पैटर्न का लाभ उठाता है जो स्वाभाविक रूप से डोमेन स्वामित्व का अर्थ है। इस विशिष्ट, मानकीकृत पथ पर एक फ़ाइल रखने के लिए, किसी के पास उस डोमेन के लिए वेब सर्वर पर प्रशासनिक नियंत्रण होना चाहिए। यह नियंत्रण का एक सरल लेकिन प्रभावी प्रमाण प्रदान करता है, जिससे विश्वास की घोषणा सत्यापन योग्य हो जाती है। जब example.com का स्वामी example.co.uk को एक संबंधित ऑरिजिन के रूप में सूचीबद्ध करने वाली फ़ाइल परोसता है, तो यह एक सत्यापन योग्य दावा है। यह वेब-देशी दृष्टिकोण उन विकल्पों की तुलना में बहुत सरल और अधिक मजबूत है जिन पर मानकीकरण प्रक्रिया के दौरान विचार किया गया और अस्वीकार कर दिया गया, जैसे कि प्राधिकरणों पर हस्ताक्षर करने के लिए क्रिप्टोग्राफ़िक कुंजियों का उपयोग करना (RP Keys) या गैर-डोमेन-आधारित यादृच्छिक पहचानकर्ता (RP UUIDs)। ROR विश्वास संबंध को वेब के मौजूदा, अच्छी तरह से समझे जाने वाले डोमेन नियंत्रण मॉडल में आधारित करता है।

Related Origin Requests को लागू करने के लिए सर्वर-साइड, ऑरिजिन को अधिकृत करने के लिए, और क्लाइंट-साइड, साझा rpID को लागू करने के लिए, दोनों पर समन्वित परिवर्तनों की आवश्यकता होती है। यह अनुभाग आपके डोमेन में एक एकीकृत Passkey अनुभव को सक्षम करने के लिए आवश्यक व्यावहारिक कोड और कॉन्फ़िगरेशन विवरण प्रदान करता है।

प्राथमिक rpID को होस्ट करने वाला सर्वर संबंधित ऑरिजिन की अलाउलिस्ट प्रकाशित करने के लिए जिम्मेदार है।

प्राधिकरण फ़ाइल को प्राथमिक rpID डोमेन की रूट के सापेक्ष सटीक पथ /.well-known/webauthn पर रखा जाना चाहिए। यह महत्वपूर्ण है कि यह फ़ाइल निम्नलिखित शर्तों के तहत परोसी जाए:

• प्रोटोकॉल: इसे HTTPS पर परोसा जाना चाहिए।
• Content-Type: HTTP प्रतिक्रिया हेडर Content-Type को application/json पर सेट किया जाना चाहिए।
• फ़ाइल एक्सटेंशन: URL में .json एक्सटेंशन शामिल नहीं होना चाहिए। सही पथ /webauthn है, न कि /webauthn.json।

फ़ाइल में एक कुंजी, origins के साथ एक एकल JSON ऑब्जेक्ट होना चाहिए, जिसका मान स्ट्रिंग्स की एक सरणी है। सरणी में प्रत्येक स्ट्रिंग पूरा ऑरिजिन (प्रोटोकॉल, डोमेन और वैकल्पिक पोर्ट) है जिसे अधिकृत किया जा रहा है।

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

उदाहरण: example.com के rpID के लिए, फ़ाइल को https://example.com/.well-known/webauthn पर परोसा जाना चाहिए (ध्यान दें: कोई .json एक्सटेंशन नहीं)।

एक बार सर्वर .well-known/webauthn फ़ाइल के साथ कॉन्फ़िगर हो जाने के बाद, सभी संबंधित डोमेन को अपने WebAuthn API कॉल में लगातार एक ही साझा rpID का उपयोग करना चाहिए। यह समन्वय ROR के सही ढंग से काम करने के लिए महत्वपूर्ण है।

प्रमुख समन्वय आवश्यकताएँ:

1. बैकएंड जिम्मेदारी: सर्वर क्रिप्टोग्राफ़िक चुनौती उत्पन्न करता है और क्रेडेंशियल निर्माण और प्रमाणीकरण अनुरोधों दोनों में साझा rpID निर्दिष्ट करता है
2. फ्रंटएंड जिम्मेदारी: सभी क्लाइंट एप्लिकेशन (example.com, example.co.uk, example.de) को ब्राउज़र के navigator.credentials API को समान साझा rpID पास करना होगा
3. कॉन्फ़िगरेशन प्रबंधन: साझा rpID को एक महत्वपूर्ण वैश्विक कॉन्फ़िगरेशन मान के रूप में माना जाना चाहिए जो सभी संबंधित साइटों पर लगातार लागू होता है

एक भी साइट पर एक गलत कॉन्फ़िगरेशन—जहाँ यह साझा मान के बजाय अपने स्वयं के ऑरिजिन को rpID के रूप में डिफ़ॉल्ट करता है—उस डोमेन पर उपयोगकर्ताओं के लिए एकीकृत Passkey अनुभव को तोड़ देगा।

महत्वपूर्ण: सर्वर को प्रत्येक अनुरोध के लिए clientDataJSON में origin फ़ील्ड को सत्यापित करना होगा, यह सुनिश्चित करते हुए कि यह अधिकृत संबंधित ऑरिजिन में से एक से मेल खाता है। यह ऑरिजिन सत्यापन प्राथमिक फ़िशिंग सुरक्षा तंत्र है।

Related Origin Requests (ROR) और फ़ेडरेटेड पहचान प्रोटोकॉल (OIDC/SAML) अलग-अलग समस्याओं का समाधान करते हैं। ROR Single Sign-On का प्रतिस्थापन नहीं है—यह एक पूरक है जो एक विशिष्ट संकीर्ण उपयोग के मामले को संबोधित करता है।

ROR एकल तार्किक एप्लिकेशन के लिए उपयुक्त है जो कई संबंधित डोमेन में वितरित है जो एक ही उपयोगकर्ता डेटाबेस साझा करते हैं:

• एकल ब्रांड जो कई कंट्री-कोड TLDs (जैसे, amazon.com, amazon.de, amazon.co.uk) संचालित करता है
• सभी डोमेन एक ही बैकएंड प्रमाणीकरण प्रणाली और उपयोगकर्ता डेटाबेस साझा करते हैं
• आप रीडायरेक्ट-आधारित प्रवाह से बचना चाहते हैं और प्रत्येक डोमेन के लिए प्रमाणीकरण को प्रासंगिक रखना चाहते हैं
• आपके डोमेन 5-लेबल सीमा के भीतर आते हैं
• उपयोगकर्ताओं को सभी डोमेन को एक सामंजस्यपूर्ण सेवा के रूप में अनुभव करना चाहिए

ROR क्या प्रदान करता है: एक ही Passkey सभी संबंधित डोमेन पर काम करता है, जिससे उपयोगकर्ताओं को प्रत्येक क्षेत्रीय साइट के लिए अलग-अलग Passkeys बनाने की आवश्यकता समाप्त हो जाती है।

अलग-अलग एप्लिकेशन में सच्चे Single Sign-On के लिए फ़ेडरेटेड पहचान प्रोटोकॉल का उपयोग करें:

• अलग-अलग उपयोगकर्ता डेटाबेस या पहचान प्रणालियों वाली कई सेवाएँ
• एंटरप्राइज़ परिदृश्य जहाँ उपयोगकर्ताओं को कई अलग-अलग एप्लिकेशन (Salesforce, Office 365, आंतरिक उपकरण) तक पहुँच की आवश्यकता होती है
• तृतीय-पक्ष एप्लिकेशन एकीकरण
• आपको केंद्रीकृत पहुँच नियंत्रण, ऑडिट ट्रेल्स और पहचान शासन की आवश्यकता है
• आप संबंधित ऑरिजिन के लिए 5-लेबल सीमा से अधिक हैं

OIDC/SAML क्या प्रदान करता है: केंद्रीकृत प्रमाणीकरण जहाँ उपयोगकर्ता एक पहचान प्रदाता (IdP) पर एक बार लॉग इन करते हैं और सुरक्षित टोकन के माध्यम से कई सेवा प्रदाताओं (SPs) तक पहुँच प्राप्त करते हैं।

महत्वपूर्ण: Passkeys दोनों दृष्टिकोणों के साथ उपयोग किए जा सकते हैं। आप फ़ेडरेटेड SSO के लिए एक केंद्रीकृत IdP पर Passkeys लागू कर सकते हैं, या एक बहु-डोमेन एकल एप्लिकेशन के लिए ROR का उपयोग कर सकते हैं। अपनी वास्तुकला के आधार पर चुनें, न कि अपने प्रमाणीकरण विधि के आधार पर।

जबकि ROR एक शक्तिशाली तकनीकी समाधान है, इसका कार्यान्वयन एक जानबूझकर रणनीतिक निर्णय होना चाहिए। आर्किटेक्ट्स और उत्पाद प्रबंधकों को एक मजबूत और भविष्य-प्रूफ प्रमाणीकरण प्रणाली बनाने के लिए इसके लाभों को वैकल्पिक पैटर्न के खिलाफ तौलना चाहिए और इसकी सीमाओं को समझना चाहिए।

ROR की एक प्रमुख बाधा "लेबल सीमा" है। इस संदर्भ में एक "लेबल" प्रभावी टॉप-लेवल डोमेन प्लस एक स्तर (eTLD+1) को संदर्भित करता है, जो एक डोमेन नाम का रजिस्ट्रार करने योग्य हिस्सा है। उदाहरण के लिए:

• shopping.com, shopping.co.uk, और shopping.ca सभी एक ही लेबल "shopping" साझा करते हैं
• myshoppingrewards.com एक नया, अलग लेबल पेश करता है: "myshoppingrewards"
• travel.shopping.com अभी भी "shopping" लेबल के अंतर्गत आता है

WebAuthn लेवल 3 विनिर्देश के लिए ब्राउज़र कार्यान्वयन को origins सूची में न्यूनतम पाँच अद्वितीय लेबल का समर्थन करने की आवश्यकता है। 2025 तक, कोई भी ज्ञात ब्राउज़र इस न्यूनतम पाँच लेबल से अधिक का समर्थन नहीं करता है। इसलिए, संगठनों को अपने ROR परिनियोजन को इस कठिन सीमा को ध्यान में रखते हुए डिज़ाइन करना चाहिए—पाँच को प्रभावी अधिकतम मानें।

यह सीमा एक जानबूझकर दुरुपयोग-रोधी तंत्र है जिसे दुरुपयोग को रोकने के लिए डिज़ाइन किया गया है। यह साझा होस्टिंग प्रदाताओं (जैसे, wordpress.com) जैसी संस्थाओं को एक सार्वभौमिक Passkey बनाने से रोकता है जो हजारों असंबंधित ग्राहक सबडोमेन पर काम कर सकता है, जो सुरक्षा मॉडल को कमज़ोर कर देगा।

अधिकांश संगठनों के लिए, यहाँ तक कि बड़े बहुराष्ट्रीय ब्रांडों के लिए भी, यह पाँच-लेबल सीमा पर्याप्त है। उदाहरण के लिए, अमेज़ॅन के विभिन्न कंट्री-कोड TLDs (amazon.com, amazon.de, amazon.co.uk, आदि) सभी "amazon" लेबल साझा करते हैं, जिससे उनके पोर्टफोलियो में "audible" या "zappos" जैसे अन्य ब्रांडों के लिए चार अतिरिक्त लेबल स्लॉट उपलब्ध रहते हैं।

ROR को लागू करने की जटिलता इस बात पर बहुत अधिक निर्भर करती है कि इसे एक नई प्रणाली में पेश किया जा रहा है या किसी मौजूदा प्रणाली पर रेट्रोफिट किया जा रहा है।

• ग्रीनफील्ड परिनियोजन: नई परियोजनाओं के लिए, रणनीति सीधी है। एक एकल, कैनोनिकल डोमेन को शुरू से ही साझा rpID के रूप में चुना जाना चाहिए (जैसे, प्राथमिक .com डोमेन)। इस rpID का उपयोग तब सभी संबंधित वेबसाइटों और अनुप्रयोगों के कॉन्फ़िगरेशन में पहले दिन से लगातार किया जाना चाहिए।
• मौजूदा परिनियोजन: ROR को एक ऐसी प्रणाली पर रेट्रोफिट करना जिसमें पहले से ही अपने डोमेन में अलग-अलग rpIDs के साथ Passkeys तैनात हैं, काफी अधिक जटिल है। एक सीधा माइग्रेशन संभव नहीं है, क्योंकि मौजूदा Passkeys स्थायी रूप से अपने मूल rpIDs से बंधे होते हैं। इस परिदृश्य में अनुशंसित दृष्टिकोण एक "आइडेंटिफ़ायर-फ़र्स्ट" लॉगिन प्रवाह को लागू करना है। उपयोगकर्ता को पहले अपना उपयोगकर्ता नाम या ईमेल दर्ज करने के लिए प्रेरित किया जाता है। बैकएंड तब यह निर्धारित करने के लिए एक लुकअप करता है कि उनका मौजूदा Passkey किस rpID से जुड़ा है। अंत में, उपयोगकर्ता को प्रमाणीकरण समारोह को पूरा करने के लिए उस rpID के अनुरूप सही ऑरिजिन पर रीडायरेक्ट किया जाता है। एक सफल लॉगिन के बाद, उन्हें उनकी मूल साइट पर वापस रीडायरेक्ट किया जा सकता है। यह एक काफी वास्तुशिल्प उपक्रम है जिसके लिए सावधानीपूर्वक योजना और कार्यान्वयन की आवश्यकता होती है।

यह समझना कि स्थापित कंपनियाँ Related Origin Requests को कैसे लागू करती हैं, आपकी अपनी परिनियोजन रणनीति के लिए मूल्यवान अंतर्दृष्टि प्रदान करता है। नीचे वास्तविक कार्यान्वयन पर आधारित उदाहरण दिए गए हैं (अक्टूबर 2025 तक):

Microsoft अपने प्रमाणीकरण बुनियादी ढाँचे के लिए ROR का उपयोग करता है। login.microsoftonline.com पर वास्तविक कॉन्फ़िगरेशन में शामिल हैं:

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

यह रूढ़िवादी दृष्टिकोण एक केंद्रित सुरक्षा परिधि बनाए रखते हुए Microsoft के एंटरप्राइज़ और उपभोक्ता लॉगिन पोर्टल्स के बीच Passkey साझाकरण को सक्षम बनाता है।

Shopify चुनिंदा डोमेन में प्रमाणीकरण को एकीकृत करने के लिए ROR लागू करता है:

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

यह कॉन्फ़िगरेशन Shopify को अपने मुख्य प्लेटफ़ॉर्म को अपने शॉप ऐप से जोड़ने की अनुमति देता है, जो संबंधित ऑरिजिन के लिए एक केंद्रित दृष्टिकोण प्रदर्शित करता है।

Amazon के पास एक बहुत बड़ी फ़ाइल है:

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

यह पैटर्न एक ब्रांड को प्राथमिक .com डोमेन को rpID के रूप में उपयोग करते हुए क्षेत्रीय डोमेन में एकीकृत Passkey प्रमाणीकरण प्रदान करने की अनुमति देगा।

ये वास्तविक दुनिया के उदाहरण कई प्रमुख पैटर्न प्रकट करते हैं:

1. rpID के रूप में प्राथमिक डोमेन: सभी कंपनियाँ अपने प्राथमिक .com डोमेन को कैनोनिकल rpID के रूप में उपयोग करती हैं
2. तार्किक समूहीकरण: ऑरिजिन को तकनीकी वास्तुकला के बजाय व्यावसायिक कार्य द्वारा समूहीकृत किया जाता है
3. रूढ़िवादी दायरा: अधिकांश कार्यान्वयन 5-लेबल सीमा के भीतर अच्छी तरह से रहते हैं, आमतौर पर 3-4 ऑरिजिन का उपयोग करते हैं
4. सबडोमेन रणनीति: कई ब्रांड स्थिरता बनाए रखने के लिए प्राथमिक डोमेन के सबडोमेन का उपयोग करते हैं

एक आधुनिक वेब मानक के रूप में, ROR को सुरक्षा को प्राथमिक विचार के रूप में डिज़ाइन किया गया है और प्रमुख ब्राउज़रों में सक्रिय रूप से अपनाया जा रहा है।

Related Origin Requests WebAuthn की मुख्य एंटी-फ़िशिंग गारंटी से समझौता नहीं करते हैं। तंत्र को एक मजबूत सुरक्षा स्थिति बनाए रखने के लिए सावधानीपूर्वक डिज़ाइन किया गया है:

• ऑरिजिन सत्यापन: जैसा कि चर्चा की गई है, ब्राउज़र अभी भी हस्ताक्षरित clientDataJSON में अनुरोध के वास्तविक ऑरिजिन को शामिल करता है। Relying Party सर्वर को यह सुनिश्चित करने के लिए इस ऑरिजिन को सत्यापित करना होगा कि अनुरोध एक अपेक्षित स्रोत से आ रहा है, जिससे एक समझौता किए गए संबंधित ऑरिजिन को दूसरे का प्रतिरूपण करने से रोका जा सके।
• सुरक्षित फ़ेच: ब्राउज़र का .well-known/webauthn फ़ाइल के लिए अनुरोध HTTPS पर किया जाता है। इसके अलावा, विनिर्देश यह अनिवार्य करता है कि यह फ़ेच क्रेडेंशियल्स (जैसे, कुकीज़) के बिना और एक रेफरर हेडर के बिना किया जाए। यह अनुरोध को उपयोगकर्ता की जानकारी लीक करने या क्रॉस-साइट ट्रैकिंग उद्देश्यों के लिए उपयोग किए जाने से रोकता है।
• सर्वर सुरक्षा: .well-known/webauthn फ़ाइल स्वयं एक महत्वपूर्ण सुरक्षा संपत्ति बन जाती है। एक हमलावर जो प्राथमिक rpID को होस्ट करने वाले वेब सर्वर पर नियंत्रण प्राप्त कर लेता है, वह संभावित रूप से इस फ़ाइल को संशोधित करके अपने स्वयं के दुर्भावनापूर्ण डोमेन को अलाउलिस्ट में जोड़ सकता है। इसलिए, इस फ़ाइल को परोसने वाले बुनियादी ढाँचे को सुरक्षित करना अत्यंत महत्वपूर्ण है।

Related Origin Requests WebAuthn लेवल 3 विनिर्देश की एक विशेषता है। ब्राउज़र समर्थन 2024 के अंत में शुरू हुआ:

मुख्य तथ्य:

• Chrome और Edge: संस्करण 128 (अगस्त 2024) में ROR समर्थन जोड़ा
• Safari: Safari 18 में ROR समर्थन जोड़ा, जो macOS 15 और iOS 18 (सितंबर 2024) पर उपलब्ध है
• Firefox: ROR के लिए कोई वर्तमान समर्थन नहीं; फ़ीचर-डिटेक्ट और फ़ॉलबैक प्रवाह लागू करें

पुराने ब्राउज़रों या Firefox का समर्थन करने वाले अनुप्रयोगों के लिए, एक फ़ॉलबैक रणनीति लागू करें:

1. फ़ीचर डिटेक्शन: PublicKeyCredential.getClientCapabilities() का उपयोग करके ROR समर्थन की जाँच करें
2. आइडेंटिफ़ायर-फ़र्स्ट प्रवाह: उपयोगकर्ता नाम/ईमेल के लिए पूछें, उपयोगकर्ता के संबंधित rpID को देखें, फिर प्रमाणीकरण के लिए उपयुक्त ऑरिजिन पर रीडायरेक्ट करें
3. ग्रेसफुल डिग्रेडेशन: यदि ROR अनुपलब्ध है तो उपयोगकर्ताओं को प्रति डोमेन अलग-अलग Passkeys बनाने की अनुमति दें

अक्टूबर 2025 तक वर्तमान समर्थन मैट्रिक्स पर आधारित डेटा।

Related Origin Requests को लागू करने के लिए कई तकनीकी टीमों के बीच सावधानीपूर्वक समन्वय और WebAuthn प्रोटोकॉल में गहरी विशेषज्ञता की आवश्यकता होती है। Corbado का Passkey अपनाने का प्लेटफ़ॉर्म बहु-डोमेन Passkey परिनियोजन के लिए एंटरप्राइज़-तैयार समाधान प्रदान करके इस जटिलता को समाप्त करता है।

Corbado Related Origin Requests की तकनीकी जटिलता को संभालता है:

• स्वचालित कॉन्फ़िगरेशन: हमारा प्लेटफ़ॉर्म स्वचालित रूप से आवश्यक .well-known/webauthn फ़ाइलों को उचित सुरक्षा हेडर और JSON स्वरूपण के साथ उत्पन्न और होस्ट करता है
• बहु-डोमेन डैशबोर्ड: आपके पूरे डोमेन पोर्टफोलियो में संबंधित ऑरिजिन को कॉन्फ़िगर करने के लिए केंद्रीकृत प्रबंधन इंटरफ़ेस
• सत्यापन उपकरण: यह सुनिश्चित करने के लिए अंतर्निहित परीक्षण और सत्यापन कि आपका ROR कॉन्फ़िगरेशन सभी ब्राउज़रों और प्लेटफ़ॉर्म पर सही ढंग से काम करता है

तकनीकी कार्यान्वयन से परे, Corbado वह सुरक्षा ढाँचा प्रदान करता है जिसकी उद्यमों को आवश्यकता होती है:

• ऑरिजिन सत्यापन: संबंधित डोमेन के दुरुपयोग को रोकने के लिए clientDataJSON ऑरिजिन का स्वचालित सत्यापन
• ऑडिट लॉगिंग: अनुपालन और सुरक्षा निगरानी के लिए सभी संबंधित डोमेन में Passkey उपयोग की व्यापक ट्रैकिंग
• घटना प्रतिक्रिया: संदिग्ध क्रॉस-डोमेन प्रमाणीकरण प्रयासों के लिए वास्तविक समय अलर्ट और स्वचालित प्रतिक्रियाएँ

मौजूदा Passkey परिनियोजन वाले संगठनों के लिए, Corbado प्रदान करता है:

• विरासत माइग्रेशन उपकरण: मौजूदा rpID कॉन्फ़िगरेशन और माइग्रेशन पथ सिफारिशों का स्वचालित विश्लेषण
• आइडेंटिफ़ायर-फ़र्स्ट प्रवाह: पूर्व-निर्मित लॉगिन घटक जो संक्रमण अवधि के दौरान जटिल बहु-rpID परिदृश्यों को संभालते हैं
• API एकीकरण: RESTful APIs और SDKs जो आपके मौजूदा प्रमाणीकरण बुनियादी ढाँचे के साथ सहजता से एकीकृत होते हैं

क्या आप अपने संगठन के लिए Related Origin Requests लागू करने के लिए तैयार हैं? Corbado की विशेषज्ञ टीम आपको अपने पूरे डिजिटल इकोसिस्टम में एक एकीकृत Passkey अनुभव डिजाइन और तैनात करने में मदद कर सकती है। अपनी विशिष्ट आवश्यकताओं और समय-सीमा पर चर्चा करने के लिए हमारी समाधान टीम से संपर्क करें।

Passkeys का वादा एक ऐसा भविष्य देने की उनकी क्षमता में निहित है जो उपयोगकर्ताओं के लिए अधिक सुरक्षित और उल्लेखनीय रूप से सरल दोनों है। हालांकि, इस भविष्य को वैश्विक स्तर पर एक वास्तविकता बनने के लिए, मानक को आधुनिक डिजिटल ब्रांडों की वास्तुशिल्प जटिलताओं को समायोजित करना होगा। सख्ती से डोमेन-बाध्य Passkeys द्वारा बनाया गया घर्षण बहु-आयामी ऑनलाइन उपस्थिति वाले संगठनों के लिए अपनाने में एक महत्वपूर्ण अवरोधक रहा है।

WebAuthn Related Origin Requests इस समस्या का मानकीकृत, सुरक्षित और सुंदर समाधान प्रदान करता है। एक ही Passkey को संबंधित डोमेन के एक विश्वसनीय सेट में निर्बाध रूप से काम करने की अनुमति देकर, ROR उपयोगकर्ता भ्रम और निराशा के एक प्रमुख बिंदु को समाप्त करता है।

इस गाइड ने WebAuthn Related Origin Requests को लागू करने के लिए पाँच महत्वपूर्ण प्रश्नों को संबोधित किया:

1. Passkeys कई डोमेन पर विफल क्यों होते हैं? WebAuthn का ऑरिजिन-बाध्य सुरक्षा मॉडल फ़िशिंग को रोकने के लिए Passkeys को विशिष्ट डोमेन से क्रिप्टोग्राफ़िक रूप से लॉक करता है, लेकिन यह तब घर्षण पैदा करता है जब ब्रांड विभिन्न देश TLDs जैसे कई डोमेन पर काम करते हैं।
2. Related Origin Requests तकनीकी रूप से कैसे काम करते हैं? ROR संबंधित डोमेन की एक सत्यापन योग्य अलाउलिस्ट बनाने के लिए एक मानकीकृत .well-known/webauthn फ़ाइल का उपयोग करता है, जिससे ब्राउज़रों को एक सुरक्षित HTTPS फ़ेच प्रक्रिया के माध्यम से क्रॉस-डोमेन Passkey उपयोग को मान्य करने में सक्षम बनाता है।
3. ROR को लागू करने के लिए क्या आवश्यक है? कार्यान्वयन के लिए .well-known/webauthn मैनिफ़ेस्ट फ़ाइल के सर्वर-साइड कॉन्फ़िगरेशन और सभी संबंधित ऑरिजिन में लगातार एक साझा rpID का उपयोग करने के लिए क्लाइंट-साइड समन्वय की आवश्यकता होती है।
4. आपको ROR को फ़ेडरेटेड लॉगिन पर कब चुनना चाहिए? साझा उपयोगकर्ता डेटाबेस वाले संबंधित डोमेन में एकीकृत ब्रांड अनुभवों के लिए ROR का उपयोग करें; अलग-अलग अनुप्रयोगों में सच्चे SSO के लिए या 5-लेबल सीमा से अधिक होने पर OIDC/SAML का उपयोग करें।
5. आप ब्राउज़र संगतता और सुरक्षा विचारों को कैसे संभालते हैं? ROR Chrome/Firefox 128+, macOS 15+ पर Safari, और iOS 18+ से प्रमुख ब्राउज़रों में समर्थित है, जिसमें पुराने ब्राउज़रों के लिए आइडेंटिफ़ायर-फ़र्स्ट प्रवाह के माध्यम से फ़ॉलबैक रणनीतियाँ उपलब्ध हैं।

तकनीकी टीमों और उत्पाद नेताओं के लिए, आवश्यक बिंदु हैं:

• ROR एक ही तार्किक एप्लिकेशन के लिए एक एकीकृत Passkey अनुभव को सक्षम बनाता है जो कई डोमेन में फैला हुआ है, जैसे कि विभिन्न कंट्री-कोड TLDs या वैकल्पिक ब्रांडिंग वाले।
• कार्यान्वयन के लिए एक समन्वित प्रयास की आवश्यकता होती है: एक सर्वर-साइड .well-known/webauthn फ़ाइल को प्राथमिक rpID के डोमेन पर प्रकाशित किया जाना चाहिए, और सभी क्लाइंट-साइड एप्लिकेशन को उसी साझा rpID का उपयोग करने के लिए कॉन्फ़िगर किया जाना चाहिए।
• ROR का उपयोग करने का निर्णय एक रणनीतिक निर्णय है। यह अपने विशिष्ट उपयोग के मामलों के लिए एक उत्कृष्ट उपकरण है, लेकिन इसे एक अधिक पारंपरिक फ़ेडरेटेड लॉगिन वास्तुकला (OIDC/SAML) के खिलाफ तौला जाना चाहिए, विशेष रूप से सच्चे Single Sign-On को शामिल करने वाले परिदृश्यों में।

Related Origin Requests जैसी सुविधाएँ पासवर्ड रहित आंदोलन की निरंतर गति के लिए महत्वपूर्ण हैं। वे वास्तविक दुनिया के कार्यान्वयन चुनौतियों को संबोधित करने के लिए मानक निकायों से एक प्रतिबद्धता प्रदर्शित करते हैं, यह सुनिश्चित करते हुए कि Passkeys के लाभ—अद्वितीय सुरक्षा और सरल उपयोगकर्ता अनुभव—सबसे बड़े और सबसे जटिल संगठनों के लिए भी सुलभ हैं। जैसे ही यह सुविधा सार्वभौमिक ब्राउज़र समर्थन प्राप्त करती है, यह वास्तव में वैश्विक, पासवर्ड रहित इंटरनेट के लिए अंतिम बाधाओं को तोड़ने में एक महत्वपूर्ण भूमिका निभाएगी।