WebAuthn रेजिडेंट की: पासकीज़ के रूप में खोजे जाने योग्य क्रेडेंशियल्स

Passkeys और इसके अंतर्निहित WebAuthn प्रोटोकॉल ऑथेंटिकेशन के परिदृश्य में क्रांति ला रहे हैं। हालाँकि, एक WebAuthn सर्वर को सही तरीके से सेट अप करना एक मुश्किल काम हो सकता है। गलत कॉन्फ़िगरेशन न केवल कमजोरियों (vulnerabilities) को जन्म दे सकती हैं, बल्कि अगर आपको बाद में उन्हें बदलने की ज़रूरत पड़ी तो मौजूदा पासकीज़ को भी तोड़ सकती हैं। यह ब्लॉग पोस्ट आपको अक्सर जटिल WebAuthn स्पेसिफिकेशन्स को बेहतर ढंग से समझने में मदद करेगा और आपको सलाह देगा कि आपके उपयोग के मामले के लिए कौन सी सेटिंग्स सबसे अच्छी हैं।

WebAuthn तीन मुख्य संस्थाओं के साथ काम करता है:

• Relying Party (RP): यह आपकी वेब सर्विस है जो एक यूज़र को ऑथेंटिकेट करना चाहती है। यह क्लाइंट को चैलेंज भेजती है, प्रतिक्रियाओं को वेरिफाई करती है और एक पासकी की पब्लिक की को मैनेज करती है।
• Authenticators: ये ऐसे डिवाइस हैं जो क्रेडेंशियल के अधिकार को साबित कर सकते हैं। उदाहरणों में स्मार्टफोन, लैपटॉप, या सिक्योरिटी कीज़ (जैसे YubiKeys) शामिल हैं। Authenticators प्लेटफ़ॉर्म-विशिष्ट (जैसे Windows Hello या Apple का Touch ID / Face ID) या क्रॉस-प्लेटफ़ॉर्म (जैसे सिक्योरिटी कीज़, उदाहरण के लिए YubiKeys) हो सकते हैं।
• Clients: आमतौर पर, ये वेब ब्राउज़र या नेटिव ऐप्स होते हैं जो RP और ऑथेंटिकेटर के बीच मध्यस्थ के रूप में कार्य करते हैं। वे संचार को सुविधाजनक बनाते हैं, यह सुनिश्चित करते हुए कि डेटा सही और सुरक्षित रूप से प्रवाहित हो।

Live demo में passkeys आज़माएं.

Passkeys आज़माएं

नीचे, एक ऑथेंटिकेशन प्रक्रिया (या तो लॉगिन या साइन-अप) के दौरान उच्च-स्तरीय डेटा प्रवाह का वर्णन किया गया है।

1. क्लाइंट द्वारा शुरुआत: प्रक्रिया क्लाइंट साइड पर शुरू होती है, आमतौर पर जब कोई यूज़र लॉगिन या साइन अप करने का प्रयास करता है। उदाहरण के लिए, वे "Login with WebAuthn" बटन पर क्लिक कर सकते हैं और क्लाइंट RP को एक चैलेंज के लिए अनुरोध भेजता है।
2. RP का अनुरोध: RP फिर क्लाइंट को एक चैलेंज वापस भेजता है। यह चैलेंज एक रैंडम रूप से जेनरेट किया गया मान है जो बाद की प्रतिक्रिया की प्रामाणिकता सुनिश्चित करता है।
3. क्लाइंट से ऑथेंटिकेटर: साइन-अप के दौरान, क्लाइंट ऑथेंटिकेटर से संबंधित पब्लिक-प्राइवेट की जोड़ी बनाकर एक नई पासकी बनाने का अनुरोध करता है। लॉगिन के दौरान, क्लाइंट ऑथेंटिकेटर से चैलेंज पर हस्ताक्षर करने का अनुरोध करता है। यह ऑथेंटिकेटर पर प्राइवेट की का उपयोग करके किया जाता है, जो RP पर संग्रहीत पहले से रजिस्टर्ड पब्लिक की से मेल खाती है।
4. ऑथेंटिकेटर की प्रतिक्रिया: साइन-अप के दौरान, ऑथेंटिकेटर पब्लिक की को क्लाइंट को वापस भेजता है। लॉगिन के दौरान, ऑथेंटिकेटर चैलेंज पर हस्ताक्षर करता है और इस हस्ताक्षरित एसर्शन को क्लाइंट को वापस भेजता है।
5. क्लाइंट से RP: क्लाइंट इस नई पब्लिक की / हस्ताक्षरित एसर्शन को RP को फॉरवर्ड करता है।
6. RP द्वारा वेरिफिकेशन: RP पब्लिक की को संग्रहीत करता है / संग्रहीत पब्लिक की का उपयोग करके हस्ताक्षरित एसर्शन को वेरिफाई करता है। यदि यह मान्य है, तो ऑथेंटिकेशन सफल होता है।

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

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

निम्नलिखित अनुभागों को बेहतर ढंग से समझने के लिए, हम एक सामान्य समझ रखने के लिए WebAuthn प्रोटोकॉल में कुछ महत्वपूर्ण शब्दों को परिभाषित करते हैं।

• क्रेडेंशियल ID: क्रेडेंशियल ID एक ऑथेंटिकेटर द्वारा जेनरेट किए गए एक विशिष्ट पब्लिक की क्रेडेंशियल को सौंपा गया एक यूनिक आइडेंटिफायर है। यह Relying Parties (RPs) को ऑथेंटिकेशन प्रक्रियाओं के लिए सही PublicKeyCredential की पहचान करने और चुनने की अनुमति देता है।
• PublicKeyCredential: यह ब्राउज़र या नेटिव ऐप्स WebAuthn API से लौटाया जाने वाला प्राथमिक डेटा स्ट्रक्चर है। इसमें साइन-अप के दौरान अटेस्टेशन डेटा और लॉगिन के दौरान एसर्शन डेटा दोनों शामिल हैं। अनिवार्य रूप से, इसमें वह डेटा होता है जिसकी RP को प्रक्रिया को वेरिफाई करने की आवश्यकता होती है।
• अटेस्टेशन: WebAuthn के संदर्भ में अटेस्टेशन ऑथेंटिकेटर की उत्पत्ति और उसकी अखंडता के प्रमाण के रूप में कार्य करता है। साइन-अप के दौरान, यह ऑथेंटिकेटर के लिए यह कहने का एक तरीका है, "मैंने यूज़र के क्रेडेंशियल को सुरक्षित रूप से रजिस्टर कर लिया है, और यहाँ एक स्टेटमेंट है जिसका उपयोग आप इसे वेरिफाई करने के लिए कर सकते हैं"। Relying Party फिर यह वेरिफाई कर सकता है कि हस्ताक्षर एक विशिष्ट ऑथेंटिकेटर से आता है जिसकी अनुमति है (जैसे Yubikey)। सभी पासकी ऑथेंटिकेटर ऐसे अटेस्टेशन के साथ जवाब नहीं देते हैं, कुछ बस उपयोगी डेटा वापस नहीं भेजते हैं (पासकी ऑथेंटिकेटर की सूची यहाँ देखें)। आगे AAGUIDs (Authenticator Attestation GUIDs) जो अधिक ऑथेंटिकेटर्स (मुख्य रूप से सिक्योरिटी कीज़, जैसे YubiKeys) की पहचान करते हैं, FIDO Alliance Metadata Service में पाए जा सकते हैं।
• एसर्शन: साइन-अप प्रक्रिया के बाद, जब कोई यूज़र लॉग इन करने का प्रयास करता है, तो ऑथेंटिकेटर एक एसर्शन उत्पन्न करता है। एसर्शन मूल रूप से PublicKeyCredential + हस्ताक्षरित चैलेंज है। यह एसर्शन साबित करता है कि यूज़र के पास रजिस्टर्ड पब्लिक की से जुड़ी प्राइवेट की है, बिना वास्तविक प्राइवेट की को प्रकट किए। यह ऑथेंटिकेटर का यह कहने का तरीका है, "यह असली यूज़र है, और मैं उनके लिए गारंटी दे सकता हूँ।"

Latest news के लिए हमारे Passkeys Substack को subscribe करें.

Subscribe करें

रेजिडेंट कीज़ (RKs) और नॉन-रेजिडेंट कीज़ (NRKs) WebAuthn प्रोटोकॉल में उपयोग की जाने वाली दो प्रकार की क्रिप्टोग्राफिक कीज़ हैं, और वे मुख्य रूप से उनके स्टोरेज स्थान और पुनर्प्राप्ति तंत्र में भिन्न होती हैं।

परिभाषा:

रेजिडेंट कीज़ सीधे ऑथेंटिकेटर पर ही संग्रहीत की जाती हैं। यह एक सिक्योरिटी की (जैसे, YubiKey), एक प्लेटफ़ॉर्म का सिक्योर एन्क्लेव (जैसे, iPhone का सिक्योर एन्क्लेव), या एक लैपटॉप पर ट्रस्टेड प्लेटफ़ॉर्म मॉड्यूल (TPM) हो सकता है। कंडीशनल UI (पासकी ऑटोफिल) केवल रेजिडेंट कीज़ के लिए काम करता है और WebAuthn वर्किंग ग्रुप वर्तमान में रेजिडेंट कीज़ को पासकी के रूप में माने जाने की आवश्यकता रखता है।

निम्नलिखित स्क्रीनशॉट में, आप सभी रेजिडेंट कीज़ (क्रेडेंशियल ID, rpID, यूज़रनेम, डिस्प्ले नाम) की एक सूची देखते हैं जो एक YubiKey पर संग्रहीत हैं। नॉन-रेजिडेंट कीज़ सूची में नहीं हैं, क्योंकि वे ऑथेंटिकेटर पर संग्रहीत नहीं हैं:

लॉगिन प्रवाह:

Source: William Brown

लॉगिन प्रक्रिया के दौरान, Relying Party क्लाइंट (ब्राउज़र) को क्रेडेंशियल्स निर्दिष्ट किए बिना एक अनुरोध भेजता है जो ऑथेंटिकेटर से पूछताछ करना शुरू कर देता है (यहाँ चार्ट में: सिक्योरिटी की)। ऑथेंटिकेटर संबंधित Relying Party के लिए सभी रेजिडेंट कीज़ की खोज करता है और क्लाइंट (ब्राउज़र) वांछित रेजिडेंट की का चयन करता है। इस रेजिडेंट की का उपयोग चैलेंज पर हस्ताक्षर करने के लिए किया जाता है। हस्ताक्षर ऑथेंटिकेटर से क्लाइंट के माध्यम से Relying Party को भेजा जाता है।

फायदे:

1. सुव्यवस्थित यूज़र अनुभव: रेजिडेंट कीज़ का एक सबसे महत्वपूर्ण लाभ यह है कि ऑथेंटिकेटर यूज़र हैंडल (जैसे ईमेल, फ़ोन नंबर, यूज़रनेम) को संग्रहीत करता है और इस प्रकार लॉगिन के लिए यूज़र हैंडल (जैसे ईमेल, फ़ोन नंबर, यूज़रनेम) को प्रीफिल कर सकता है। यूज़र्स को यूज़र हैंडल (जैसे ईमेल, फ़ोन नंबर, यूज़रनेम) याद रखने या इनपुट करने की आवश्यकता नहीं होती है, जिससे लॉगिन प्रक्रिया सुव्यवस्थित होती है, खासकर बायोमेट्रिक क्षमताओं वाले उपकरणों पर। यह कंडीशनल UI के साथ स्वचालित रूप से भी हो सकता है।
2. डिवाइस-विशिष्ट ऑथेंटिकेशन: रेजिडेंट कीज़ एक विशिष्ट डिवाइस से ऑथेंटिकेशन को जोड़कर सुरक्षा की एक अतिरिक्त परत प्रदान कर सकती हैं। यह उन सेवाओं के लिए विशेष रूप से उपयोगी हो सकता है जो यह सुनिश्चित करना चाहती हैं कि यूज़र्स विश्वसनीय उपकरणों से लॉग इन कर रहे हैं।
3. कंडीशनल UI (पासकी ऑटोफिल): कंडीशनल UI केवल रेजिडेंट कीज़ के साथ काम करता है जो सबसे सहज लॉगिन अनुभव प्रदान करता है (विवरण के लिए नीचे देखें)।

नुकसान:

1. स्टोरेज सीमा: कुछ ऑथेंटिकेटर्स की एक सीमित स्टोरेज क्षमता होती है। विशेष रूप से सिक्योरिटी कीज़ (जैसे YubiKeys) के लिए, वे अक्सर रेजिडेंट कीज़ की संख्या पर एक सीमा रखते हैं (अधिकांश में 8 से ~100 रेजिडेंट कीज़ की सीमा होती है)। एक बार यह सीमा पूरी हो जाने पर, नई कीज़ के लिए जगह बनाने के लिए पुरानी कीज़ को हटाना पड़ सकता है, या यूज़र को दूसरे ऑथेंटिकेटर का उपयोग करना पड़ सकता है।
2. ऑथेंटिकेटर का खो जाना: यदि ऑथेंटिकेटर, जैसे, एक सिक्योरिटी की (जैसे YubiKey) या स्मार्टफोन, खो जाता है या क्षतिग्रस्त हो जाता है, तो उस डिवाइस पर सभी रेजिडेंट कीज़ खो जाती हैं। यह यूज़र्स को कई सेवाओं से बाहर कर सकता है जब तक कि वे अपने खातों को फिर से रजिस्टर या पुनर्प्राप्त नहीं कर लेते। एक क्लाउड खाते (जैसे iCloud Keychain, Google Password Manager) या एक आधुनिक पासवर्ड मैनेजर (जैसे 1Password या Dashlane) के माध्यम से कीज़ को सिंक करना इस नुकसान को रोकता है।
3. सुरक्षा चिंताएँ: यदि रेजिडेंट कीज़ वाला कोई ऑथेंटिकेटर चोरी हो जाता है, तो एक हमलावर कीज़ निकालने का प्रयास कर सकता है। जबकि आधुनिक ऑथेंटिकेटर्स में निकालने से रोकने के लिए मजबूत सुरक्षा तंत्र होते हैं, जैसे यूज़र डिवाइस को एक मजबूत पिन, पासकोड या जेस्चर से बचाता है, जोखिम, यद्यपि न्यूनतम, फिर भी मौजूद है।

उपयोग के मामले: उन उपकरणों के लिए आदर्श जहाँ यूज़र अक्सर ऑथेंटिकेट करता है, जैसे व्यक्तिगत स्मार्टफोन या लैपटॉप।

देखें कि वास्तव में कितने लोग passkeys इस्तेमाल करते हैं.

Adoption data देखें

परिभाषा:

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

लॉगिन प्रवाह:

Source: William Brown

लॉगिन प्रक्रिया के दौरान, Relying Party को पहले यह पहचानना होगा कि कौन सा यूज़र ऑथेंटिकेशन का अनुरोध कर रहा है (जैसे यूज़र हैंडल, जैसे ईमेल, फ़ोन नंबर या यूज़रनेम मांगकर) और फिर वह क्रेडेंशियल IDs भेजता है जिनके बारे में वह अनुरोध करने वाले यूज़र के लिए जानता है, क्लाइंट (ब्राउज़र) को। क्लाइंट उन्हें ऑथेंटिकेटर (यहाँ: सिक्योरिटी की) को फॉरवर्ड करता है। ऑथेंटिकेटर क्रेडेंशियल ID को ऑथेंटिकेटर की मास्टर की के साथ उपयोग करके अस्थायी प्राइवेट की प्राप्त करता है, जेनरेट की गई की के साथ चैलेंज पर हस्ताक्षर करता है और इसे क्लाइंट (यहाँ: ब्राउज़र) को लौटाता है, जो इसे Relying Party को फॉरवर्ड करता है। नॉन-रेजिडेंट कीज़ मूल रूप से पासकीज़ की शुरुआत से पहले दूसरे फैक्टर के रूप में उपयोग की जाती थीं। इसलिए, पहले यूज़र की पहचान करना नियमित लॉगिन प्रक्रिया का हिस्सा था।

फायदे:

1. स्केलेबिलिटी: चूंकि नॉन-रेजिडेंट कीज़ ऑथेंटिकेटर पर नहीं रहती हैं, इसलिए यूज़र्स के पास विभिन्न सेवाओं से जुड़ी लगभग असीमित संख्या में नॉन-रेजिडेंट कीज़ हो सकती हैं। यह उन यूज़र्स के लिए विशेष रूप से फायदेमंद है जिनके कई प्लेटफ़ॉर्म पर खाते हैं।
2. रोमिंग क्षमता: नॉन-रेजिडेंट कीज़ सिक्योरिटी कीज़ (जैसे YubiKey) जैसे रोमिंग ऑथेंटिकेटर्स के लिए आदर्श हैं। एक यूज़र एक ही सिक्योरिटी की (जैसे YubiKey) का उपयोग कई उपकरणों और प्लेटफ़ॉर्म पर ऑथेंटिकेट करने के लिए कर सकता है, जिससे एक सुसंगत अनुभव मिलता है।
3. ऑथेंटिकेटर स्टोरेज पर कम निर्भरता: उपयुक्त WebAuthn सर्वर सेटिंग्स के लिए, ऑथेंटिकेटर की स्टोरेज सीमाओं के बारे में चिंता करने की कोई आवश्यकता नहीं है। यह कम-स्टोरेज ऑथेंटिकेटर्स, जैसे सिक्योरिटी कीज़ (जैसे YubiKeys) के लिए विशेष रूप से फायदेमंद हो सकता है।

नुकसान:

1. यूज़र हैंडल की आवश्यकता के कारण कम UX: नॉन-रेजिडेंट कीज़ का सबसे बड़ा नकारात्मक पहलू यह है कि यूज़र हैंडल (जैसे ईमेल, फ़ोन नंबर, यूज़रनेम) यूज़र द्वारा प्रदान किया जाना चाहिए जो कंडीशनल UI के माध्यम से यूज़रनेम प्रीफिल को असंभव बना देता है। इस यूज़र हैंडल को क्रेडेंशियल ID से जोड़ा जाना चाहिए जो इफेमरल की-रैप्ड की की गणना के लिए आवश्यक है।
2. कुप्रबंधन की संभावना: RPs को यूज़र खातों और पब्लिक कीज़ के बीच संबंधों को प्रबंधित और सुरक्षित करने की आवश्यकता है। खराब प्रबंधन या कमजोरियाँ सुरक्षा मुद्दों को जन्म दे सकती हैं।

उपयोग के मामले: सिक्योरिटी कीज़ (जैसे YubiKeys) जैसे रोमिंग ऑथेंटिकेटर्स के लिए आदर्श जो कई सेवाओं या प्लेटफ़ॉर्म पर उपयोग किए जाते हैं।

कल्पना कीजिए कि आपके पास एक सिक्योरिटी की (जैसे YubiKey) है, और आप इसे दो ऑनलाइन सेवाओं: सर्विस A और सर्विस B के साथ रजिस्टर करते हैं। सर्विस A के लिए, आप एक रेजिडेंट की का उपयोग करते हैं। सर्विस B के लिए, एक नॉन-रेजिडेंट की। जब आप सर्विस A पर ऑथेंटिकेट करते हैं, तो आप बस अपनी सिक्योरिटी की (जैसे YubiKey) को टैप करते हैं, और आप अंदर हैं - यूज़रनेम निर्दिष्ट करने की कोई आवश्यकता नहीं है। सर्विस B के लिए, आप पहले ब्राउज़र / नेटिव ऐप में अपना यूज़रनेम प्रदान करेंगे। सेवा तब संबंधित क्रेडेंशियल ID को आपकी सिक्योरिटी की (जैसे YubiKey) को भेजती है, जो फिर ऑथेंटिकेशन के लिए इफेमरल प्राइवेट की को फिर से जेनरेट करती है।

संक्षेप में, जबकि रेजिडेंट और नॉन-रेजिडेंट दोनों कीज़ क्रिप्टोग्राफिक ऑथेंटिकेशन का लाभ उठाकर सुरक्षा को बढ़ाती हैं, उनके यूज़र अनुभव और स्टोरेज तंत्र अलग-अलग होते हैं, जो विभिन्न उपयोग मामलों को पूरा करते हैं।

Passkeys Debugger में passkey flows के साथ experiment करें.

मुफ्त में आज़माएं

कंडीशनल UI पासकीज़ / WebAuthn की एक मील का पत्थर सुविधा है। यह यूज़र से और भी अधिक बोझ हटाता है, क्योंकि यूज़र को न केवल एक पासवर्ड याद रखने की आवश्यकता नहीं है, बल्कि उसे उस यूज़र हैंडल (जैसे ईमेल, फ़ोन नंबर, यूज़रनेम) को भी याद रखने की आवश्यकता नहीं है जिसके साथ उसने एक Relying Party पर साइन-अप किया था। विशेष रूप से, उन मामलों में जहाँ Relying Parties की सेवाओं का उपयोग केवल कभी-कभी किया जाता है, यह एक बहुत बड़ा कदम है।

यह इसलिए काम करता है क्योंकि जैसे ही लॉगिन पेज खोला जाता है, Relying Party सर्वर पृष्ठभूमि में क्लाइंट को एक चैलेंज भेजता है (याद रखें कि इस कॉल में भेजे जाने के लिए किसी क्रेडेंशियल ID की आवश्यकता नहीं है)। क्लाइंट इस चैलेंज को लेता है और जाँचता है कि कौन सी पासकीज़ इस ऑथेंटिकेटर पर Relying Party ID से मेल खाती हैं और ऑटोफिल मेनू के माध्यम से चयन की पेशकश करती है, जहाँ यूज़र उपयुक्त पासकी का चयन कर सकता है।

इसके अलावा, यह यूज़र को लॉगिन बटन पर एक अतिरिक्त क्लिक से भी बचाता है, क्योंकि जैसे ही पासकी को ऑटोफिल मेनू से चुना जाता है, लॉगिन प्रक्रिया शुरू हो जाती है।

CTAP FIDO2 मानक में एक मूलभूत प्रोटोकॉल है, जो क्लाइंट (जैसे ब्राउज़र) और ऑथेंटिकेटर्स (जैसे सिक्योरिटी कीज़, उदाहरण के लिए YubiKeys, या स्मार्टफोन) के बीच संचार की खाई को पाटता है। CTAP को बेहतर ढंग से समझने के लिए, आइए रेजिडेंट और नॉन-रेजिडेंट कीज़ पर प्रभाव का विश्लेषण करने से पहले विभिन्न प्रोटोकॉल संस्करणों पर एक संक्षिप्त नज़र डालें।

पुराना संस्करण, जिसे अक्सर यूनिवर्सल 2nd फैक्टर (U2F) के रूप में जाना जाता है, मुख्य रूप से दूसरे-कारक ऑथेंटिकेशन के लिए डिज़ाइन किया गया था। U2F में, सर्वर एक चैलेंज प्रदान करता है, और ऑथेंटिकेटर एक प्रतिक्रिया प्रदान करता है, जो प्राइवेट की के अधिकार को साबित करता है। हालाँकि, U2F रेजिडेंट कीज़ का समर्थन नहीं करता है, जिसका अर्थ है कि इसे हमेशा यह पहचानने के लिए सर्वर-साइड लुकअप की आवश्यकता होती है कि किसी यूज़र के लिए कौन सी की का उपयोग करना है, क्योंकि यह दूसरे फैक्टर के लिए पूछने की प्रक्रिया का हिस्सा था।

U2F का उत्तराधिकारी, CTAP2 ने रेजिडेंट कीज़ के लिए समर्थन पेश किया, जिससे पासवर्ड रहित और यूज़रनेम रहित ऑथेंटिकेशन की अनुमति मिली। रेजिडेंट कीज़ के साथ, ऑथेंटिकेटर यूज़र का यूज़रनेम और क्रेडेंशियल ID ( Relying Party ID के साथ) संग्रहीत करता है, जिससे ऑथेंटिकेशन के दौरान Relying Party सर्वर को इसे प्रदान करने की आवश्यकता समाप्त हो जाती है। यह एक अधिक सहज UX की दिशा में एक महत्वपूर्ण छलांग है।

हालाँकि, CTAP2 चुनौतियों के साथ आता है। एक उल्लेखनीय मुद्दा रेजिडेंट कीज़ का प्रबंधन है। उदाहरण के लिए, CTAP2.0 डिवाइस में एक विशिष्ट रेजिडेंट की को हटाने के लिए अक्सर एक पूर्ण डिवाइस रीसेट की आवश्यकता होती है (इसलिए आपकी मास्टर की भी रीसेट हो जाती है, जिसका अर्थ है कि आपकी सभी नॉन-रेजिडेंट कीज़ भी अब काम नहीं करेंगी), जो यूज़र-फ्रेंडली नहीं है और उन परिदृश्यों में समस्याग्रस्त हो सकता है जहाँ एक ही डिवाइस पर कई रेजिडेंट कीज़ संग्रहीत हैं। यह CTAP2.0 डिवाइस पर रेजिडेंट कीज़ को एक गंभीर प्रतिबद्धता बनाता है। आप वास्तव में गलती से उस सीमित स्थान को भरना नहीं चाहते हैं जो आपके पास अक्सर होता है, खासकर सिक्योरिटी कीज़ (जैसे YubiKeys) पर।

CTAP2.1 CTAP2 का एक बाद का संस्करण है, जो प्रोटोकॉल में अतिरिक्त सुविधाएँ और सुधार लाता है। CTAP 2.1 के बारे में कुछ मुख्य बातें शामिल हैं:

• बेहतर रेजिडेंट की प्रबंधन: CTAP 2.1 आपको अपने डिवाइस से विशिष्ट रेजिडेंट कीज़ को व्यक्तिगत रूप से प्रबंधित करने, अपडेट करने और हटाने की अनुमति देता है।
• एंटरप्राइज अटेस्टेशन: यह सुविधा उद्यमों को अपने कर्मचारियों द्वारा उपयोग की जाने वाली कीज़ पर अधिक नियंत्रण रखने की अनुमति देती है। यह उद्यमों को यह वेरिफाई करने का एक तरीका प्रदान करता है कि उपयोग की जा रही कीज़ कंपनी द्वारा जारी की गई हैं।
• एकाधिक यूज़र पहचान: कुछ ऑथेंटिकेटर्स कई यूज़र्स को पहचान सकते हैं। CTAP 2.1 इन ऑथेंटिकेटर्स को यह इंगित करने का एक तरीका प्रदान करता है कि किस यूज़र को पहचाना गया है।
• बैकवर्ड संगतता: CTAP 2.1 को CTAP2 के साथ बैकवर्ड संगत होने के लिए डिज़ाइन किया गया है, यह सुनिश्चित करते हुए कि पुराने संस्करण का समर्थन करने वाले डिवाइस और प्लेटफ़ॉर्म अभी भी नए के साथ काम कर सकते हैं।

रेजिडेंट कीज़, नॉन-रेजिडेंट कीज़ और विभिन्न CTAP संस्करणों पर एक नज़र डालने के बाद, अब हम Relying Party पक्ष और इस प्रकार WebAuthn सर्वर पक्ष का अधिक गहराई से विश्लेषण करते हैं।

WebAuthn का लचीलापन (लेकिन इसकी जटिलता भी) काफी हद तक इसकी सर्वर सेटिंग्स के कारण है, विशेष रूप से authenticatorSelection ऑब्जेक्ट के भीतर। यह ऑब्जेक्ट क्लाइंट को काम के लिए सही ऑथेंटिकेटर चुनने में मार्गदर्शन करता है।

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

यह सर्वर विकल्प निर्दिष्ट करता है कि ऑथेंटिकेटर क्लाइंट डिवाइस से कैसे जुड़ा है। यह इस बारे में जानकारी प्रदान करता है कि ऑथेंटिकेटर क्लाइंट के साथ कैसे संचार करता है:

संभावित मान

• Platform: यह इंगित करता है कि ऑथेंटिकेटर क्लाइंट के प्लेटफ़ॉर्म से जुड़ा हुआ है और इसलिए इसे हटाया नहीं जा सकता है।
• Cross-platform: यह इंगित करता है कि ऑथेंटिकेटर क्लाइंट के प्लेटफ़ॉर्म से बंधा नहीं है और इसका उपयोग कई उपकरणों पर किया जा सकता है।

उपयोग के मामले और उदाहरण

• Platform: उदाहरणों में एक फिंगरप्रिंट स्कैनर शामिल है जो एक लैपटॉप में बनाया गया है या एक फोन पर एक चेहरे की पहचान प्रणाली, जैसे Face ID, Touch ID या Windows Hello।
• Cross-platform: उदाहरणों में USB सिक्योरिटी कीज़ (जैसे YubiKeys), ब्लूटूथ डिवाइस, या NFC कार्ड शामिल हैं।

WebAuthn लेवल 1 स्पेसिफिकेशन में, इस सर्वर विकल्प को requireResidentKey कहा जाता था और यह बूलियन मान true (ऑथेंटिकेटर को एक रेजिडेंट की बनानी चाहिए) या false (ऑथेंटिकेटर को एक नॉन-रेजिडेंट की बनानी चाहिए) रख सकता था। WebAuthn लेवल 2 ने इस सर्वर विकल्प को नए सर्वर विकल्प residentKey से बदल दिया:

संभावित मान

• Required: ऑथेंटिकेटर को एक रेजिडेंट की बनानी होगी (यदि संभव न हो तो ऑपरेशन विफल होना चाहिए)।
• Preferred: ऑथेंटिकेटर को एक रेजिडेंट की बनाने का प्रयास करना चाहिए (यदि संभव न हो तो उसे एक नॉन-रेजिडेंट की बनानी चाहिए)।
• Discouraged: ऑथेंटिकेटर को एक नॉन-रेजिडेंट की बनानी होगी (यदि संभव न हो तो ऑपरेशन विफल होना चाहिए)।

उपयोग के मामले और उदाहरण

• Required: उन परिदृश्यों के लिए आदर्श जहाँ यूज़रनेम रहित चाहा जाता है या जहाँ यूज़र्स को केवल पहले से रजिस्टर्ड उपकरणों से ऑथेंटिकेट करना चाहिए (यूज़र्स के क्रेडेंशियल को एक विशिष्ट डिवाइस से बांधकर एक अतिरिक्त सुरक्षा परत जोड़कर)।
• Preferred: उन परिदृश्यों के लिए उपयुक्त जहाँ वेब सेवा यदि संभव हो तो सर्वश्रेष्ठ लॉगिन UX प्रदान करना चाहती है (रेजिडेंट कीज़ के माध्यम से), लेकिन यदि रेजिडेंट कीज़ संभव न हों तो भी नॉन-रेजिडेंट कीज़ का समर्थन करना चाहती है।
• Discouraged: एक सेवा पासकी ऑथेंटिकेशन की पेशकश करना चाहती है और यह भी सुनिश्चित करना चाहती है कि यूज़र्स किसी भी ऑथेंटिकेटर का उपयोग कर सकते हैं, यहाँ तक कि बिना स्टोरेज क्षमताओं वाले भी, क्रेडेंशियल को एक विशिष्ट डिवाइस से बांधे बिना।

यूज़र वेरिफिकेशन उस प्रक्रिया को संदर्भित करता है जो यह सुनिश्चित करती है कि ऑथेंटिकेटर के साथ बातचीत करने वाला व्यक्ति वैध मालिक है, आमतौर पर एक विशिष्ट ऑथेंटिकेशन जेस्चर की आवश्यकता होती है जैसे पिन दर्ज करना, फिंगरप्रिंट प्रदान करना, या चेहरे की पहचान का उपयोग करना।

कभी-कभी यूज़र प्रेजेंस (UP) का भी उल्लेख या उपयोग यूज़र वेरिफिकेशन के समान किया जाता है, लेकिन वास्तव में इसमें कुछ अंतर हैं। यूज़र प्रेजेंस केवल यह पुष्टि करता है कि कोई व्यक्ति - कोई भी - शारीरिक रूप से मौजूद है और डिवाइस के साथ बातचीत कर रहा है। यह उस व्यक्ति की पहचान को वेरिफाई नहीं करता है। यूज़र प्रेजेंस के लिए बिना किसी और पहचान जाँच के एक सिक्योरिटी की का एक साधारण स्पर्श पर्याप्त हो सकता है। पासकीज़ / WebAuthn के लिए, यूज़र को हमेशा उपस्थित रहना पड़ता है।

संभावित मान

• Required: ऑपरेशन में यूज़र वेरिफिकेशन होना चाहिए।
• Preferred: ऑपरेशन में यदि संभव हो तो यूज़र वेरिफिकेशन होना चाहिए, लेकिन इसके बिना भी आगे बढ़ सकता है।
• Discouraged: ऑपरेशन में यूज़र वेरिफिकेशन नहीं होना चाहिए।

उपयोग के मामले और उदाहरण

• Required: बैंकिंग या हेल्थकेयर जैसे उच्च-सुरक्षा अनुप्रयोगों के लिए आदर्श, जहाँ यूज़र की पहचान (जैसे, एक फिंगरप्रिंट या पिन के माध्यम से) को वेरिफाई करना महत्वपूर्ण है।
• Preferred: सामान्य अनुप्रयोगों के लिए उपयोगी जहाँ अतिरिक्त सुरक्षा एक बोनस है लेकिन सख्ती से आवश्यक नहीं है।
• Discouraged: कम-जोखिम वाले संचालन या परिदृश्यों के लिए उपयुक्त जहाँ यूज़र वेरिफिकेशन एक असुविधा हो सकती है।

पैटर्न

• ऑथेंटिकेटर अटैचमेंट: platform
• रेजिडेंट की: required
• यूज़र वेरिफिकेशन: required

उदाहरण: एक कॉर्पोरेट एप्लिकेशन चाहता है कि कर्मचारी अपनी कंपनी द्वारा जारी लैपटॉप पर बिल्ट-इन फिंगरप्रिंट रीडर का उपयोग करके बिना पासवर्ड के लॉग इन करें। क्रेडेंशियल डिवाइस पर संग्रहीत होता है, और यूज़र को हर बार एक फिंगरप्रिंट के साथ वेरिफाई करना होगा।

पैटर्न

• ऑथेंटिकेटर अटैचमेंट: cross-platform
• रेजिडेंट की: required
• यूज़र वेरिफिकेशन: required

उदाहरण: एक यूज़र अपनी ऑनलाइन बैंकिंग के लिए एक सिक्योरिटी की (जैसे YubiKey) रजिस्टर करता है। वे इस की का उपयोग किसी भी डिवाइस पर ऑथेंटिकेट करने के लिए कर सकते हैं, बिना यूज़रनेम दर्ज करने की आवश्यकता के।

कई हार्डवेयर-आधारित सिक्योरिटी कीज़ (जैसे YubiKeys) में अंतर्निहित स्टोरेज की कमी होती है। यह सीमा डिवाइस पर उपलब्ध भौतिक मेमोरी और निर्माता के डिजाइन विचारों के कारण है।

उदाहरण: एक YubiKey में केवल 20 रेजिडेंट कीज़ संग्रहीत करने की क्षमता हो सकती है। एक बार यह सीमा पूरी हो जाने पर, मौजूदा कीज़ को हटाए बिना कोई अतिरिक्त रेजिडेंट की नहीं जोड़ी जा सकती है।

समाधान:

• रेजिडेंट कीज़ का चयनात्मक उपयोग: प्रत्येक यूज़र के लिए रेजिडेंट कीज़ का उपयोग करने के बजाय, उन्हें विशिष्ट भूमिकाओं या परिदृश्यों के लिए मानें। उदाहरण के लिए, एडमिन भूमिकाओं या उच्च-विशेषाधिकार प्राप्त यूज़र्स के लिए रेजिडेंट कीज़ को प्राथमिकता दें जिन्हें बढ़ी हुई सुरक्षा की आवश्यकता है।
• यूज़र शिक्षा: यूज़र्स को उनकी सिक्योरिटी कीज़ (जैसे YubiKeys) की सीमाओं के बारे में सूचित करें। उन्हें उन उपकरणों पर स्विच करने के लिए प्रोत्साहित करें जो असीमित रेजिडेंट कीज़ का उपयोग कर सकते हैं, जैसे लैपटॉप या स्मार्टफोन।

विभिन्न ऑथेंटिकेटर्स रेजिडेंट की अनुरोधों को अलग-अलग तरीके से संभाल सकते हैं। कुछ डिफ़ॉल्ट रूप से एक रेजिडेंट की बनाने के लिए हो सकते हैं, भले ही इसका स्पष्ट रूप से अनुरोध न किया गया हो, जबकि दूसरों को स्पष्ट निर्देश की आवश्यकता हो सकती है।

विभिन्न प्लेटफ़ॉर्म पर विभिन्न WebAuthn सर्वर विकल्पों के लिए असंगत व्यवहार एक बड़ी समस्या है। उदाहरण के लिए, iOS WebAuthn सर्वर विकल्पों की परवाह किए बिना हमेशा एक रेजिडेंट की बनाएगा, जबकि Android को एक ऑप्ट-इन की आवश्यकता होती है (जैसे residentKey: preferred या residentKey: required के साथ)।

व्यवहार के अलावा, यह और भी बुरा है कि सर्वर-साइड संग्रहीत डेटा के आधार पर, आप 100% निश्चितता के साथ यह नहीं कह सकते कि संग्रहीत क्रेडेंशियल एक रेजिडेंट की है या नॉन-रेजिडेंट की। इसके बजाय, आप कुछ जाँचों का पालन कर सकते हैं और इसे सीमित कर सकते हैं (नीचे देखें), लेकिन फिर भी उम्मीद करनी होगी कि क्रेडेंशियल का व्यवहार आपके विश्वास के अनुसार हो।

इसके पीछे का कारण यह है कि क्रेडेंशियल प्रॉपर्टीज एक्सटेंशन (clientExtensionResults.credProps.rk जो या तो true है या false) में क्रेडेंशियल के प्रकार (रेजिडेंट की या नॉन-रेजिडेंट की) के बारे में जानकारी संग्रहीत करने का एक WebAuthn सुझाव है। हालाँकि, RP को यह जानकारी प्रदान करना गारंटीकृत नहीं है क्योंकि सभी WebAuthn एक्सटेंशन वैकल्पिक हैं, जैसे iOS इसे नहीं भेजता है (इसलिए आप नहीं जानते कि यह एक रेजिडेंट की है या नॉन-रेजिडेंट की)।

हमारे शोध के दौरान, हमने विभिन्न प्लेटफ़ॉर्म और ऑथेंटिकेटर्स (Windows 10, Windows 11, Android 7, Android 13, iOS17, macOS Ventura, YubiKey) पर व्यवहार का परीक्षण करने का प्रयास किया, दो WebAuthn डेमो पेजों के साथ जो बनाए गए क्रेडेंशियल्स पर अधिक विवरण प्रदान करते हैं: https://webauthn.io और https://webauthntest.identitystandards.io/। बाद वाला लीगेसी requireResidentKey प्रॉपर्टी (WebAuthn लेवल 1) के साथ काम करने और इसे residentKey प्रॉपर्टी (WebAuthn लेवल 2) के साथ संयोजित करने की संभावना प्रदान करता है। हालाँकि, परिणाम विश्वसनीय नहीं थे (जैसे इसने iOS के लिए नॉन-रेजिडेंट की बताया लेकिन स्पष्ट रूप से कंडीशनल UI काम कर रहा था)।

सबसे भरोसेमंद जाँच योजना जो हमें मिली वह निम्नलिखित है:

1. जाँचें कि आपके WebAuthn सर्वर सेटिंग्स "residentKey" एट्रिब्यूट के लिए क्या हैं
   1. यदि "residentKey: required" और एक क्रेडेंशियल सफलतापूर्वक बनाया गया है -> यह एक रेजिडेंट की है
   2. यदि "residentKey: preferred" या "residentKey: discouraged", तो अगली जाँच पर जाएँ
2. क्या एक्सटेंशन credProps.rk समर्थित है और सर्वर पर क्रेडेंशियल में संग्रहीत है?
   1. यदि credProps.rk = true, तो क्रेडेंशियल एक रेजिडेंट की है
   2. यदि credProps.rk = false, तो क्रेडेंशियल एक नॉन-रेजिडेंट की है
   3. यदि credProps खाली है, तो क्रेडेंशियल का प्रकार अज्ञात है

जैसा कि आप देख सकते हैं, यह इसे सीमित करने में मदद करता है, फिर भी अज्ञात विकल्प रहता है और आप 100% निश्चितता के साथ की के प्रकार का निर्धारण नहीं कर सकते हैं।

यह SUSE के विलियम ब्राउन के उनके महान लेख में निष्कर्षों के अनुरूप भी है, जिसमें बताया गया है कि यदि Relying Parties द्वारा रेजिडेंट कीज़ की आवश्यकता होती है तो सिक्योरिटी कीज़ (जैसे YubiKeys) कैसे बेकार हो सकती हैं (हमने उनकी तालिका का विस्तार किया है):

तालिका में, आप विभिन्न WebAuthn सर्वर रेजिडेंट की विकल्पों के लिए देखते हैं कि क्या एक रेजिडेंट की बनाई गई थी (true), क्या एक नॉन-रेजिडेंट की बनाई गई थी (false) या कुछ और हुआ।

समाधान:

• पूरी तरह से परीक्षण: परिनियोजन से पहले, अपने WebAuthn कार्यान्वयन का परीक्षण लोकप्रिय ऑथेंटिकेटर्स की एक श्रृंखला में करें ताकि उनके व्यवहार को समझा जा सके।
• स्पष्ट सर्वर सेटिंग्स: अपने WebAuthn सर्वर को सेट अप करते समय, अपनी आवश्यकताओं में स्पष्ट रहें। यदि आप केवल पासकीज़ चाहते हैं, तो residentKey विकल्प को required पर सेट करें (ध्यान दें: कि यह सीमित रेजिडेंट की क्षमता वाले ऑथेंटिकेटर्स के साथ अन्य चुनौतियों को जन्म दे सकता है, ऊपर देखें)।

यदि कोई यूज़र अपनी सिक्योरिटी की (जैसे YubiKey) पर स्टोरेज सीमा तक पहुँच जाता है, तो उन्हें त्रुटियों का सामना करना पड़ सकता है या वे नए क्रेडेंशियल्स रजिस्टर करने में असमर्थ हो सकते हैं। इससे भ्रम और निराशा हो सकती है।

समाधान:

• शिष्ट त्रुटि हैंडलिंग: स्पष्ट त्रुटि संदेश लागू करें जो यूज़र को सूचित करें जब उनकी सिक्योरिटी की (जैसे YubiKey) भर जाती है और इस मुद्दे को हल करने के तरीके पर मार्गदर्शन प्रदान करें।
• निर्देशित वर्कफ़्लो: यूज़र्स अपनी रेजिडेंट कीज़ को कैसे प्रबंधित कर सकते हैं, इस पर चरण-दर-चरण गाइड या ट्यूटोरियल प्रदान करें, यह सुनिश्चित करते हुए कि वे स्वतंत्र रूप से मुद्दों को हल कर सकते हैं।

9. डेवलपर्स और उत्पाद प्रबंधकों के लिए सर्वोत्तम अभ्यास

जैसा कि आपने ऊपर देखा है, आपके द्वारा चुनी गई WebAuthn सर्वर सेटिंग्स आपके ऑथेंटिकेशन प्रक्रिया के यूज़र अनुभव और सुरक्षा को महत्वपूर्ण रूप से प्रभावित कर सकती हैं। सूचित निर्णय लेने के लिए इन सेटिंग्स की बारीकियों को समझना आवश्यक है।

रेजिडेंट बनाम नॉन-रेजिडेंट कीज़: यदि आपके अधिकांश यूज़र्स मुख्य रूप से व्यक्तिगत उपकरणों जैसे स्मार्टफोन या लैपटॉप से आपकी सेवा का उपयोग करते हैं, तो रेजिडेंट कीज़ एक उपयुक्त विकल्प हैं। रेजिडेंट कीज़ डिवाइस पर ही संग्रहीत होती हैं और उन यूज़र्स के लिए एक सहज ऑथेंटिकेशन अनुभव प्रदान करती हैं जो अक्सर एक ही डिवाइस का उपयोग करते हैं। हालाँकि, उन यूज़र्स के लिए जो सिक्योरिटी कीज़ (जैसे YubiKeys) का उपयोग करते हैं, जो नॉन-रेजिडेंट कीज़ हैं, अधिक उपयुक्त हो सकती हैं।

यूज़र वेरिफिकेशन (UV) सेटिंग्स: आप जिस सुरक्षा स्तर को प्राप्त करना चाहते हैं, उसके आधार पर आप यह तय कर सकते हैं कि यूज़र वेरिफिकेशन प्रक्रिया कितनी सख्त होनी चाहिए। यदि आप उच्च सुरक्षा का लक्ष्य रख रहे हैं, तो एक पिन, फिंगरप्रिंट, या चेहरे की पहचान (userVerification: preferred या userVerification: required) की आवश्यकता की सलाह दी जाती है।

अटेस्टेशन और विश्वसनीयता: अटेस्टेशन आपको ऑथेंटिकेटर की उत्पत्ति और अखंडता को वेरिफाई करने की अनुमति देता है। तय करें कि क्या आप सभी ऑथेंटिकेटर्स पर भरोसा करना चाहते हैं या केवल विशिष्ट निर्माताओं के ऑथेंटिकेटर्स पर। यह महत्वपूर्ण हो सकता है यदि आप संवेदनशील डेटा के साथ काम कर रहे हैं और यह सुनिश्चित करना चाहते हैं कि केवल उच्च-गुणवत्ता वाले, विश्वसनीय ऑथेंटिकेटर्स का उपयोग किया जाए।

फ़ॉलबैक तंत्र: हमेशा एक फ़ॉलबैक तंत्र रखें। यदि कोई यूज़र अपना ऑथेंटिकेटर खो देता है या यदि यह खराब हो जाता है, तो उनके पास अपने खाते तक पहुँचने का एक वैकल्पिक तरीका होना चाहिए। यह बैकअप कोड, SMS वेरिफिकेशन, ईमेल मैजिक लिंक या अन्य मल्टी-फैक्टर ऑथेंटिकेशन विधियों के माध्यम से हो सकता है।

निरंतर शिक्षा: पासकीज़ और WebAuthn का परिदृश्य लगातार विकसित हो रहा है। नवीनतम विकास, कमजोरियों, और पैच के साथ अपडेट रहें। अपनी विकास टीम को पासकीज़ और WebAuthn से संबंधित कार्यशालाओं, वेबिनार और सम्मेलनों में भाग लेने के लिए प्रोत्साहित करें।

यूज़र ऑनबोर्डिंग और शिक्षा: पासकी ऑथेंटिकेशन का परिचय देते समय, सुनिश्चित करें कि आपके यूज़र्स इसके लाभों और यह कैसे काम करता है, को समझते हैं। साइन-अप प्रक्रिया के दौरान स्पष्ट निर्देश प्रदान करें और यूज़र्स को पासकीज़ सेट अप करने और उपयोग करने में सहायता के लिए संसाधन (जैसे FAQs या वीडियो ट्यूटोरियल) प्रदान करें।

इन सर्वोत्तम प्रथाओं का पालन करके, डेवलपर्स और उत्पाद प्रबंधक यह सुनिश्चित कर सकते हैं कि वे पासकी ऑथेंटिकेशन को प्रभावी ढंग से लागू करें, सुरक्षा और यूज़र अनुभव दोनों को संतुलित करते हुए।

यदि आप अपनी वेबसाइट या ऐप में मुख्यधारा में अपनाने के लिए पासकीज़ लागू करना चाहते हैं और सिक्योरिटी कीज़ (जैसे YubiKeys) का समर्थन करने की आवश्यकता नहीं है, क्योंकि आपके अधिकांश यूज़र्स बस अपने स्मार्टफोन या लैपटॉप का उपयोग करेंगे, तो हम निम्नलिखित सेटिंग्स की सलाह देते हैं।

• authenticator: platform
• residentKey: required
• userVerification: required

लाभ:

• चूंकि सभी बनाई गई कीज़ रेजिडेंट कीज़ हैं, इसलिए सेटअप कंडीशनल UI की अनुमति देता है जो आपके यूज़र्स के लिए आपके लॉगिन को और भी सहज बनाता है क्योंकि उन्हें यूज़रनेम याद रखने की आवश्यकता नहीं है।
• Apple, Google और Microsoft के सभी आधुनिक डिवाइस समर्थित हैं और पासकीज़ का उपयोग करते हैं।

WebAuthn का सर्वर सेटिंग्स, जटिल होने के बावजूद, ऑथेंटिकेशन के लिए एक मजबूत और लचीला ढाँचा प्रदान करती हैं। इन सेटिंग्स में महारत हासिल करना महत्वपूर्ण है, क्योंकि यह केवल एक नए मानक को लागू करने के बारे में नहीं है; यह यूज़र ऑथेंटिकेशन की सुरक्षा और दक्षता में मौलिक रूप से सुधार करने के बारे में है।

संक्षेप में, WebAuthn का सर्वर सेटिंग्स को समझना अधिक सुरक्षित, कुशल और भविष्य-उन्मुख एप्लिकेशन बनाने में एक निवेश है। जैसे-जैसे डिजिटल परिदृश्य विकसित होता है, ऐसी तकनीकों में पारंगत होना अनिवार्य होगा। अपडेट रहने के लिए, हमारी पासकीज़ कम्युनिटी में शामिल हों या नीचे हमारे न्यूज़लेटर की सदस्यता लें।

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Passkey Intelligence Platform है। हम आपको वह दिखाते हैं जो IDP logs और सामान्य analytics tools नहीं दिखा सकते: कौन-से devices, OS versions, browsers और credential managers passkeys को support करते हैं, क्यों enrollments login में नहीं बदलते, WebAuthn flow कहाँ fail होता है, और कब कोई OS या browser update चुपचाप login को तोड़ देता है — और यह सब Okta, Auth0, Ping, Cognito या आपके in-house IDP को बदले बिना। दो products: Corbado Observe जोड़ता है passkeys और किसी भी अन्य login method के लिए observability। Corbado Connect देता है analytics के साथ built-in managed passkeys (आपके IDP के साथ-साथ)। VicRoads, Corbado के साथ 5M+ users के लिए passkeys चला रहा है (+80% passkey activation)। Passkey विशेषज्ञ से बात करें →