इस दस्तावेज़ में बताया गया है कि WebAuthn में userVerification क्या है. साथ ही, यह भी बताया गया है कि पासकी बनाने या पुष्टि करने के दौरान userVerification तय करने पर, ब्राउज़र पर क्या होता है.
WebAuthn में "उपयोगकर्ता की पुष्टि" क्या है?
पासकी, सार्वजनिक पासकोड क्रिप्टोग्राफ़ी पर बनाई जाती हैं. पासकी बनाने पर, सार्वजनिक और निजी पासकोड का जोड़ा जनरेट होता है. पासकी की सुविधा देने वाली कंपनी, निजी पासकोड को सेव करती है और सार्वजनिक पासकोड को भरोसेमंद पक्ष (आरपी) के सर्वर पर स्टोर कर देती है. सर्वर, जोड़ी गई सार्वजनिक कुंजी का इस्तेमाल करके, उसी पासकी से साइन किए गए हस्ताक्षर की पुष्टि करके उपयोगकर्ता की पुष्टि कर सकता है. सार्वजनिक पासकोड के क्रेडेंशियल पर "उपयोगकर्ता मौजूद" (अप) फ़्लैग से यह पता चलता है कि पुष्टि करने के दौरान, किसी ने डिवाइस से इंटरैक्ट किया था.
उपयोगकर्ता की पहचान की पुष्टि करना, सुरक्षा की एक वैकल्पिक लेयर है. इसकी मदद से यह पक्का किया जाता है कि पुष्टि के दौरान सही व्यक्ति मौजूद था, न कि सिर्फ़ कुछ लोग, जैसा कि उपयोगकर्ता की मौजूदगी का दावा करता है. स्मार्टफ़ोन पर ऐसा करने के लिए आम तौर पर स्क्रीन लॉक करने वाली तकनीक का इस्तेमाल किया जाता है. भले ही, वह बायोमेट्रिक्स हो या पिन या पासवर्ड. "यूवी" फ़्लैग में उपयोगकर्ता की पुष्टि की गई है या नहीं, इसकी शिकायत की गई है या नहीं यह जानकारी, पासकी रजिस्ट्रेशन और पुष्टि करने के दौरान, पुष्टि करने वाले डेटा में दिखता है
सर्वर पर यूपी और यूवी की पुष्टि करने का तरीका
उपयोगकर्ता की मौजूदगी (UP) और उपयोगकर्ता की पुष्टि किए गए (यूवी) बूलियन फ़्लैग, सर्वर को पुष्टि करने वाले डेटा फ़ील्ड में दिखाए जाते हैं. पुष्टि करने के दौरान, सेव की गई सार्वजनिक कुंजी का इस्तेमाल करके हस्ताक्षर की पुष्टि करके, Authenticator के डेटा फ़ील्ड के कॉन्टेंट की पुष्टि की जा सकती है. जब तक सिग्नेचर मान्य है, तब तक सर्वर फ़्लैग को असली मान सकता है.
पासकी के रजिस्ट्रेशन और पुष्टि करने के दौरान, सर्वर को इसकी ज़रूरत के हिसाब से यह जांच करनी चाहिए कि यूपी फ़्लैग true है और यूवी फ़्लैग true है या false.
userVerification पैरामीटर तय करना
WebAuthn स्पेसिफ़िकेशन के मुताबिक, आरपी, क्रेडेंशियल बनाने और दावे, दोनों पर userVerification पैरामीटर के साथ उपयोगकर्ता की पुष्टि का अनुरोध कर सकती है. यह 'preferred', 'required' या 'discouraged' को स्वीकार करता है, जिसका मतलब है:
'preferred'(डिफ़ॉल्ट): डिवाइस पर, उपयोगकर्ता की पहचान की पुष्टि करने के तरीके का इस्तेमाल करना प्राथमिकता दी जाती है. हालांकि, डिवाइस के उपलब्ध न होने पर इसे स्किप किया जा सकता है. अगर उपयोगकर्ता की पुष्टि की गई थी, तो रिस्पॉन्स क्रेडेंशियल में यूवी फ़्लैग की वैल्यूtrueहोती है. अगर यूवी फ़्लैग की वैल्यू नहीं दी जाती है, तो इसमेंfalseकी वैल्यू शामिल होती है.'required': डिवाइस पर, उपयोगकर्ता की पहचान की पुष्टि करने का उपलब्ध तरीका चालू करना ज़रूरी है. अगर कोई अनुरोध उपलब्ध नहीं है, तो अनुरोध स्थानीय तौर पर काम नहीं कर पाएगा. इसका मतलब है कि रिस्पॉन्स क्रेडेंशियल हमेशाtrueपर सेट किए गए यूवी फ़्लैग के साथ दिखता है.'discouraged': उपयोगकर्ता की पुष्टि करने के किसी तरीके का इस्तेमाल करने की सलाह नहीं दी जाती है. हालांकि, डिवाइस के आधार पर, फिर भी उपयोगकर्ता की पुष्टि की जा सकती है. साथ ही, यूवी फ़्लैग मेंtrueयाfalseहो सकता है.
पासकी बनाने के लिए सैंपल कोड:
const publicKeyCredentialCreationOptions = {
// ...
authenticatorSelection: {
authenticatorAttachment: 'platform',
residentKey: 'required',
requireResidentKey: true,
userVerification: 'preferred'
}
};
const credential = await navigator.credentials.create({
publicKey: publicKeyCredentialCreationOptions
});
पासकी की पुष्टि करने के लिए सैंपल कोड:
const publicKeyCredentialRequestOptions = {
challenge: /* Omitted challenge data... */,
rpId: 'example.com',
userVerification: 'preferred'
};
const credential = await navigator.credentials.get({
publicKey: publicKeyCredentialRequestOptions
});
आपको userVerification के लिए कौनसा विकल्प चुनना चाहिए?
आपको userVerification की जिस वैल्यू का इस्तेमाल करना चाहिए वह ऐप्लिकेशन की ज़रूरी शर्तों के साथ-साथ, उपयोगकर्ता अनुभव पर भी निर्भर करता है.
userVerification='preferred' का इस्तेमाल कब करना चाहिए
अगर आपको उपयोगकर्ता अनुभव को सुरक्षा के बजाय प्राथमिकता देनी है, तो userVerification='preferred' का इस्तेमाल करें.
कुछ ऐसे परिवेश भी हैं जहां उपयोगकर्ता की पुष्टि करना, सुरक्षा से ज़्यादा मुश्किल होता है. उदाहरण के लिए, अगर macOS पर टच आईडी उपलब्ध नहीं है, तो उपयोगकर्ता से सिस्टम पासवर्ड डालने के लिए कहा जाता है. ऐसा इसलिए होता है, क्योंकि डिवाइस पर यह काम नहीं करता, वह बंद होता है या डिवाइस क्लैमशेल मोड में होता है. इसकी वजह से रुकावट आती है और उपयोगकर्ता पुष्टि करने की प्रोसेस को पूरी तरह से छोड़ सकता है. अगर रुकावट को खत्म करना आपके लिए ज़्यादा ज़रूरी है, तो userVerification='preferred' का इस्तेमाल करें.
userVerification='preferred' के साथ, अगर उपयोगकर्ता की पहचान की पुष्टि हो जाती है, तो यूवी फ़्लैग true होता है. वहीं, अगर उपयोगकर्ता की पहचान की पुष्टि नहीं की जाती है, तो यूवी फ़्लैग को false दिखाया जाता है. उदाहरण के लिए, macOS पर टच आईडी उपलब्ध न होने पर, यह उपयोगकर्ता को एक बटन पर क्लिक करने के लिए कहता है, ताकि उपयोगकर्ता की पुष्टि न की जा सके. साथ ही, सार्वजनिक कुंजी के क्रेडेंशियल में false का यूवी फ़्लैग शामिल होता है.
ऐसे में, यूवी फ़्लैग की मदद से आपके जोखिम के विश्लेषण में मदद मिल सकती है. अगर दूसरी वजहों से साइन इन करने की कोशिश जोखिम भरी लगती है, तो हो सकता है कि उपयोगकर्ता की पुष्टि नहीं की गई हो. ऐसे में, हो सकता है कि आप उपयोगकर्ता को साइन इन करने के लिए अतिरिक्त चुनौतियां देना चाहें.
userVerification='required' का इस्तेमाल कब करना चाहिए
अगर आपको लगता है कि यूपी और यूवी, दोनों ही बहुत ज़रूरी हैं, तो userVerification='required' का इस्तेमाल करें.
इस विकल्प का एक नकारात्मक पहलू यह है कि साइन इन करते समय उपयोगकर्ता को ज़्यादा समस्याएं आ सकती हैं. उदाहरण के लिए, macOS पर जहां टच आईडी उपलब्ध नहीं है, वहां उपयोगकर्ता से सिस्टम पासवर्ड डालने के लिए कहा जाता है.
userVerification='required' से, यह पक्का किया जा सकता है कि डिवाइस पर उपयोगकर्ता की पुष्टि की प्रक्रिया पूरी हो गई है. पक्का करें कि सर्वर इस बात की पुष्टि करता हो कि यूवी फ़्लैग true है.
नतीजा
उपयोगकर्ता की पुष्टि की सुविधा का इस्तेमाल करके, पासकी का इस्तेमाल करने वाली कंपनियां, डिवाइस के मालिक के साइन इन करने की संभावना का आकलन कर सकती हैं. उपयोगकर्ता की पुष्टि करने की ज़रूरत हो या नहीं, यह उन पर निर्भर करता है कि फ़ॉलबैक में साइन-इन करने का तरीका, यूज़र फ़्लो पर कितना ज़रूरी असर डालता है. पासकी से उपयोगकर्ता की पुष्टि करने के लिए, पक्का करें कि सर्वर यूपी फ़्लैग और यूवी फ़्लैग की जांच करे.