इस दस्तावेज़ में बताया गया है कि WebAuthn में userVerification क्या है. साथ ही, पासकी बनाने या पुष्टि करने के दौरान userVerification का इस्तेमाल करने पर, ब्राउज़र के व्यवहार के बारे में भी बताया गया है.
WebAuthn में "उपयोगकर्ता की पुष्टि" क्या है?
पासकी, सार्वजनिक पासकोड क्रिप्टोग्राफ़ी पर आधारित होती हैं. पासकी बनाने पर, एक सार्वजनिक-निजी पासकोड जनरेट हो जाता है और पासकी की सेवा देने वाली कंपनी, निजी पासकोड सेव करती है. साथ ही, सार्वजनिक पासकोड को भरोसेमंद पक्ष (आरपी) के सर्वर को स्टोर करने के लिए वापस कर दिया जाता है. सर्वर, जोड़े गए सार्वजनिक पासकोड का इस्तेमाल करके, उसी पासकी से साइन किए गए हस्ताक्षर की पुष्टि करके उपयोगकर्ता की पुष्टि कर सकता है. सार्वजनिक कुंजी वाले क्रेडेंशियल पर "उपयोगकर्ता मौजूद है" (UP) फ़्लैग से पता चलता है कि पुष्टि के दौरान किसी व्यक्ति ने डिवाइस से इंटरैक्ट किया था.
उपयोगकर्ता की पुष्टि, सुरक्षा की एक वैकल्पिक लेयर है. इससे यह पक्का करने में मदद मिलती है कि पुष्टि के दौरान सही व्यक्ति मौजूद था, न कि सिर्फ़ कोई व्यक्ति, जैसा कि उपयोगकर्ता की मौजूदगी का दावा करता है. स्मार्टफ़ोन पर, आम तौर पर स्क्रीन लॉक की सुविधा का इस्तेमाल करके ऐसा किया जाता है. फिर चाहे वह बायोमेट्रिक हो या पिन या पासवर्ड. उपयोगकर्ता की पुष्टि की गई है या नहीं, इसकी जानकारी "यूवी" फ़्लैग में दी गई है. यह जानकारी, पासकी रजिस्ट्रेशन और पुष्टि करने के दौरान, पुष्टि करने वाले डेटा में दिखती है
सर्वर पर यूपी और यूवी की पुष्टि कैसे की जाती है
उपयोगकर्ता की मौजूदगी (UP) और उपयोगकर्ता की पुष्टि की गई (UV) बूलियन फ़्लैग, पुष्टि करने वाले टूल के डेटा फ़ील्ड में सर्वर को भेजे जाते हैं. पुष्टि करने के दौरान, स्टोर की गई सार्वजनिक कुंजी का इस्तेमाल करके हस्ताक्षर की पुष्टि करके, पुष्टि करने वाले डेटा फ़ील्ड के कॉन्टेंट की पुष्टि की जा सकती है. जब तक हस्ताक्षर मान्य है, तब तक सर्वर फ़्लैग को मान्य मान सकता है.
पासकी के रजिस्ट्रेशन और पुष्टि के दौरान, सर्वर को यह जांच करनी चाहिए कि UP फ़्लैग true है या नहीं. साथ ही, ज़रूरत के हिसाब से यह भी देखना चाहिए कि UV फ़्लैग 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 पर Touch ID की सुविधा उपलब्ध न होने पर, उपयोगकर्ता से सिस्टम का पासवर्ड डालने के लिए कहा जाता है. ऐसा तब होता है, जब डिवाइस पर Touch ID की सुविधा काम न करती हो, उसे बंद कर दिया गया हो या डिवाइस क्लैमशेल मोड में हो. इससे उपयोगकर्ता को परेशानी होती है और वह पुष्टि करने की प्रोसेस को पूरी तरह छोड़ सकता है. अगर आपके लिए फ़्रीक्शन को खत्म करना ज़्यादा ज़रूरी है, तो userVerification='preferred' का इस्तेमाल करें.
userVerification='preferred' के साथ, अगर उपयोगकर्ता की पुष्टि हो जाती है, तो यूवी फ़्लैग true होता है. अगर उपयोगकर्ता की पुष्टि नहीं की जाती है, तो यूवी फ़्लैग false होता है. उदाहरण के लिए, macOS पर Touch ID की सुविधा उपलब्ध नहीं है. ऐसे में, उपयोगकर्ता की पुष्टि को छोड़ने के लिए, उपयोगकर्ता से किसी बटन पर क्लिक करने के लिए कहा जाता है. साथ ही, सार्वजनिक कुंजी क्रेडेंशियल में false यूवी फ़्लैग शामिल होता है.
इसके बाद, यूवी फ़्लैग आपके जोखिम के विश्लेषण में एक सिग्नल हो सकता है. अगर दूसरी वजहों से साइन-इन करने की कोशिश जोखिम भरी लगती है, तो हो सकता है कि आप उपयोगकर्ता को साइन-इन करने के लिए कुछ और चुनौतियां देना चाहें. ऐसा तब करें, जब उपयोगकर्ता की पहचान की पुष्टि न की गई हो.
userVerification='required' का इस्तेमाल कब करना चाहिए
अगर आपको लगता है कि UP और UV, दोनों प्रॉपर्टी की वैल्यू देना ज़रूरी है, तो userVerification='required' का इस्तेमाल करें.
इस विकल्प का एक नुकसान यह है कि उपयोगकर्ता को साइन इन करते समय ज़्यादा परेशानी हो सकती है. उदाहरण के लिए, macOS पर Touch ID की सुविधा उपलब्ध न होने पर, उपयोगकर्ता से उसके सिस्टम का पासवर्ड डालने के लिए कहा जाता है.
userVerification='required' की मदद से, यह पक्का किया जा सकता है कि उपयोगकर्ता की पुष्टि डिवाइस पर की गई है. पक्का करें कि सर्वर इस बात की पुष्टि करता हो कि यूवी फ़्लैग true है.
नतीजा
उपयोगकर्ता की पुष्टि का फ़ायदा उठाकर, पासकी पर भरोसा करने वाली पार्टियां यह अनुमान लगा सकती हैं कि डिवाइस के मालिक ने साइन इन किया है या नहीं. यह उनकी पसंद है कि वे उपयोगकर्ता की पुष्टि करना ज़रूरी बनाएं या इसे वैकल्पिक बनाएं. यह इस बात पर निर्भर करता है कि फ़ॉलबैक साइन-इन का तरीका, उपयोगकर्ता फ़्लो पर कितना असर डालता है. पक्का करें कि सर्वर, पासकी की मदद से उपयोगकर्ता की पुष्टि करने के लिए, UP फ़्लैग और UV फ़्लैग की जांच करता हो.