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