WebAuthn और पासकी में, रिलाइंग पार्टी आईडी (आरपी आईडी), डोमेन नेम के हिसाब से क्रेडेंशियल का स्कोप तय करता है. पासकी बनाते समय, ब्राउज़र उसे किसी खास आरपी आईडी से जोड़ता है. इसके बाद, ब्राउज़र उस पासकी को ऐसे डोमेन पर इस्तेमाल करने से रोकता है जो उस आईडी से मेल नहीं खाता या उसके दायरे में नहीं आता. आरपी आईडी को सही तरीके से सेट करने से, यह पक्का होता है कि सभी सबडोमेन, अलग-अलग साइटों के ऑरिजिन, और पहले पक्ष (ग्राहक) के मोबाइल ऐप्लिकेशन पर पासकी का इस्तेमाल बिना किसी रुकावट के किया जा सके.
आरपी आईडी के बारे में बुनियादी जानकारी
रिलाइंग पार्टी आईडी (आरपी आईडी) एक यूनीक स्ट्रिंग होती है. इससे आपकी सेवा या वेबसाइट की पहचान होती है. आरपी आईडी, डोमेन स्ट्रिंग होना चाहिए. यह मौजूदा होस्टनेम या कोई बड़ा पैरंट डोमेन हो सकता है. हालांकि, यह eTLD+1 या इससे ज़्यादा होना चाहिए. आर पी आईडी के तौर पर, आईपी पतों और पब्लिक सफ़िक्स (ईटीएलडी) का इस्तेमाल नहीं किया जा सकता.
उदाहरण के लिए, अगर आपने अपना सर्वर https://www.example.com पर होस्ट किया है, तो अपनी खास ज़रूरतों के हिसाब से, example.com या www.example.com को इसके आरपी आईडी के तौर पर इस्तेमाल किया जा सकता है.
यहां दी गई टेबल में, आपके ऑरिजिन होस्ट के हिसाब से, इस्तेमाल किए जा सकने वाले आरपी आईडी के उदाहरण दिए गए हैं:
| ऑरिजिन होस्ट | अनुमति वाला आरपी आईडी (eTLD+1) |
|---|---|
https://login.example.com |
example.com या login.example.com |
https://example.com:8080 |
example.com (पोर्ट नंबर शामिल नहीं हैं) |
https://mobile.example.co.jp |
example.co.jp या mobile.example.co.jp |
https://sub.project.org.uk |
project.org.uk या sub.project.org.uk |
https://user.github.io |
user.github.io (github.io एक ईटीएलडी है) |
https://myapp.pages.dev |
myapp.pages.dev (pages.dev एक ईटीएलडी है) |
http://localhost |
localhost (एचटीटीपीएस की ज़रूरी शर्त का अपवाद) |
पासकी बनाते समय, ब्राउज़र क्रिप्टोग्राफ़िक तरीके से पासकी को आरपी आईडी से जोड़ता है. क्रेडेंशियल का इस्तेमाल करने के लिए, पुष्टि करने के अनुरोध का ऑरिजिन, उस आरपी आईडी से मेल खाना चाहिए.
आरपी आईडी के तौर पर eTLD+1 का इस्तेमाल करने पर, पासकी से जुड़े सभी सबडोमेन पर काम करती है. उदाहरण के लिए, example.com का आरपी आईडी, https://login.example.com और https://shop.example.com के लिए काम करता है. login.example.com जैसे ज़्यादा खास RP
ID, अपने सटीक ऑरिजिन पर काम करता है, लेकिन https://shop.example.com पर नहीं.
क्रॉस-साइट कॉन्टेक्स्ट में आरपी आईडी
अगर आपकी सेवा कई eTLD+1 पर काम करती है (उदाहरण के लिए, example.com और
example.co.jp), तो यह क्रॉस-साइट कॉन्फ़िगरेशन है. स्टैंडर्ड आरपी आईडी, क्रॉस-साइट सेटअप के साथ काम नहीं करते.
अलग-अलग साइटों के बीच पासकी शेयर करने के लिए, रिलेटेड ऑरिजिन अनुरोध (आरओआर) का इस्तेमाल करें. ROR की मदद से, अलग-अलग साइटों के बीच पासकी शेयर की जा सकती हैं. ऐसा इसलिए, क्योंकि क्लाइंट (ब्राउज़र) अलग-अलग ऑरिजिन को एक ही लॉजिकल सेवा के हिस्से के तौर पर पहचानता है.
आरओआर के लिए ज़रूरी शर्तें:
- एक आरपी आईडी चुनें: आपको एक आरपी आईडी चुनना होगा और उसे सभी साइटों पर इस्तेमाल करना होगा.
- कॉन्फ़िगरेशन फ़ाइल होस्ट करना: प्राइमरी आरपी आईडी डोमेन को
/.well-known/webauthnपर एक कॉन्फ़िगरेशन फ़ाइल होस्ट करनी होगी. इसमें अनुमति वाले ऑरिजिन की सूची दी गई हो. - एक जैसा बनाए रखें: भले ही, उपयोगकर्ता
https://www.example.co.jpपर हो, लेकिन WebAuthn कॉल मेंrpId, प्राइमरी होना चाहिए. उदाहरण के लिए,example.com. ऐसा, क्रेडेंशियल बनाते समय और पुष्टि करते समय, दोनों बार होना चाहिए.
प्रतिबंधित पार्टी के आईडी example.com के लिए, ROR का उदाहरण: https://example.com/.well-known/webauthn
{
"origins": [
"https://www.example.co.jp",
"https://shop.example"
]
}
मिलते-जुलते ऑरिजिन के अनुरोधों को लागू करने के बारे में ज़्यादा जानने के लिए, मिलते-जुलते ऑरिजिन के अनुरोधों की मदद से, अपनी सभी साइटों पर पासकी के फिर से इस्तेमाल करने की अनुमति दें लेख पढ़ें
मोबाइल ऐप्लिकेशन पर आरपी आईडी
मोबाइल ऐप्लिकेशन, किसी वेब डोमेन से जुड़कर पासकी का इस्तेमाल कर सकते हैं. यह संबंध बनाने के लिए, आपको अपने सर्वर पर पुष्टि करने वाली फ़ाइल को होस्ट करना होगा.
Android: डिजिटल ऐसेट लिंक
Android Credential Manager को ऐप्लिकेशन से जोड़ने के लिए, RP ID डोमेन पर Digital Asset Link (DAL) फ़ाइल की ज़रूरत होती है.
- होस्टिंग: फ़ाइल को
https://<RP ID>/.well-known/assetlinks.jsonपर होस्ट करें. - पुष्टि:
clientDataJSONमें जाकर,originकी पुष्टि करें. Android के लिए, यहandroid:apk-key-hash:<hash>जैसी स्ट्रिंग होती है.
आरपी आईडी example.com के लिए डीएएल का उदाहरण (https://example.com/.well-known/assetlinks.json पर होस्ट किया गया)
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.google.credentialmanager.sample",
"sha256_cert_fingerprints": [
"4F:20:47:1F:D9:9A:BA:96:47:8D:59:27:C2:C8:A6:EA:8E:D2:8D:14:C0:B6:A2:39:99:9F:A3:4D:47:3D:FA:11"
]
}
}
]
ज़्यादा जानकारी के लिए, अपने ऐप्लिकेशन और वेबसाइट के बीच डिजिटल ऐसेट लिंक कॉन्फ़िगर करना लेख पढ़ें
iOS: Associated Domains
Apple प्लैटफ़ॉर्म पर, ऐप्लिकेशन को RP ID डोमेन से जोड़ने के लिए, apple-app-site-association (AASA) फ़ाइल की ज़रूरत होती है.
- AASA फ़ाइल: होस्ट
https://<RP_ID>/.well-known/apple-app-site-association. - एनटाइटलमेंट: ऐप्लिकेशन के एनटाइटलमेंट में
webcredentials:<app info>जोड़ें.
आरपी आईडी example.com के लिए AASA का उदाहरण:
https://example.com/.well-known/apple-app-site-association:
{
"webcredentials":
{
"apps": ["EXAMPLE123.com.example.passkey"]
}
}
ज़्यादा जानकारी के लिए, Apple Developer Documentation में पासकी की मदद से किसी सेवा से कनेक्ट करना लेख पढ़ें.
खास जानकारी
आरपी आईडी से यह तय होता है कि आपके उपयोगकर्ता अपनी पासकी कहां से ऐक्सेस करेंगे. इन बातों का ध्यान रखें:
- क्रम और सबडोमेन: आरपी आईडी, डोमेन स्ट्रिंग (eTLD+1 या इससे ज़्यादा) होना चाहिए.
example.comजैसे बड़े डोमेन का इस्तेमाल करने से, पासकी सभी सबडोमेन (उदाहरण के लिए,login.example.comऔरshop.example.com) पर काम करती हैं. - अलग-अलग साइटों पर काम करने वाले समाधान: एक से ज़्यादा eTLD+1 पर काम करने वाली सेवाओं के लिए, मिलते-जुलते ऑरिजिन से किए गए अनुरोध (आरओआर) का इस्तेमाल करें. इसके लिए, एक आरपी आईडी और
/.well-known/webauthnपर कॉन्फ़िगरेशन फ़ाइल की ज़रूरत होती है. - मोबाइल इंटिग्रेशन: Android के लिए
/.well-known/assetlinks.jsonपर Digital Asset Links (DAL) फ़ाइल और iOS के लिए/.well-known/apple-app-site-associationपर apple-app-site-association (AASA) फ़ाइल का इस्तेमाल करके, अपनी वेबसाइट और मोबाइल ऐप्लिकेशन के बीच पुष्टि किया गया संबंध बनाएं.