फ़ॉर्म को ऑटोमैटिक भरने की सुविधा की मदद से, पासकी से साइन इन करना

साइन इन करने का ऐसा अनुभव बनाएं जिसमें पासकी का इस्तेमाल किया जाता हो. साथ ही, पासवर्ड का इस्तेमाल करने वाले मौजूदा उपयोगकर्ताओं को भी शामिल किया जाता हो.

Eiji Kitamura

इस गाइड में, फ़ॉर्म अपने-आप भरने की सुविधा इस्तेमाल करने का तरीका बताया गया है. इससे उपयोगकर्ताओं को पासवर्ड के साथ-साथ पासकी की मदद से साइन इन करने की अनुमति दी जा सकती है. फ़ॉर्म में अपने-आप जानकारी भरने की सुविधा का इस्तेमाल करने से, साइन इन करने का एक जैसा अनुभव मिलता है. इससे पासवर्ड से ज़्यादा सुरक्षित और इस्तेमाल में आसान पासकी की पुष्टि करने के तरीके पर स्विच करना आसान हो जाता है.

अपने मौजूदा साइन-इन फ़ॉर्म में, पासकी और पासवर्ड, दोनों का इस्तेमाल करने वाले लोगों के लिए, WebAuthn के कंडिशनल यूज़र इंटरफ़ेस (यूआई) को लागू करने का तरीका जानें. इससे, उन्हें साइन-इन करने में कम से कम परेशानी होगी.

पासकी की मदद से साइन-इन करने के लिए, फ़ॉर्म में जानकारी ऑटोमैटिक तरीके से भरने की सुविधा का इस्तेमाल क्यों करना चाहिए?

पासकी की मदद से, उपयोगकर्ता वेबसाइटों पर साइन इन कर सकते हैं. इसके लिए, वे अपने फ़िंगरप्रिंट, चेहरे या डिवाइस के पिन का इस्तेमाल करते हैं.

अगर सभी उपयोगकर्ताओं के पास पासकी होती, तो पुष्टि करने की प्रोसेस में सिर्फ़ एक 'साइन इन करें' बटन होता. बटन पर टैप करने से, उपयोगकर्ता सीधे तौर पर स्क्रीन लॉक की मदद से खाते की पुष्टि कर पाएगा और साइन इन कर पाएगा.

हालांकि, पासवर्ड से पासकी पर स्विच करने में कुछ समस्याएं आती हैं. इस अवधि के दौरान, वेबसाइटों को पासवर्ड और पासकी, दोनों का इस्तेमाल करने वाले लोगों के लिए सहायता देनी होगी. उपयोगकर्ताओं से यह उम्मीद करना कि उन्हें याद रहे कि किन साइटों पर पासकी का इस्तेमाल किया जाता है और उनसे साइन-इन करने का तरीका चुनने के लिए कहना, उपयोगकर्ता अनुभव को खराब करता है.

पासकी भी एक नई टेक्नोलॉजी है. इसलिए, इसके बारे में साफ़ तौर पर बताना मुश्किल हो सकता है. ऑटोमैटिक भरने की सुविधा वाले जाने-पहचाने इंटरफ़ेस का इस्तेमाल करने से, ट्रांज़िशन से जुड़ी समस्या और उपयोगकर्ता की ज़रूरत को पूरा करने में मदद मिलती है.

शर्त के हिसाब से यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करना

पासकी और पासवर्ड, दोनों का इस्तेमाल करने वाले लोगों को बेहतर अनुभव देने के लिए, अपने फ़ॉर्म में अपने-आप भरने की सुविधा के सुझावों में पासकी शामिल करें. इस तरीके में, कंडीशनल यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल किया जाता है. यह WebAuthn स्टैंडर्ड की एक सुविधा है.

जब उपयोगकर्ता, उपयोगकर्ता नाम डालने वाले फ़ील्ड पर फ़ोकस करता है, तो अपने-आप भरने वाला डायलॉग दिखता है. इसमें सेव किए गए पासवर्ड के साथ-साथ, सेव की गई पासकी के सुझाव भी दिखते हैं. उपयोगकर्ता के पास पासकी या पासवर्ड में से किसी एक को चुनने का विकल्प होता है. इसके बाद, वह साइन इन कर सकता है. अगर वह पासकी चुनता है, तो उसे डिवाइस के स्क्रीन लॉक का इस्तेमाल करना होगा.

इससे उपयोगकर्ता, आपकी वेबसाइट पर मौजूदा साइन-इन फ़ॉर्म से साइन इन कर पाते हैं. हालांकि, अगर उनके पास पासकी है, तो उन्हें पासकी की अतिरिक्त सुरक्षा का फ़ायदा मिलता है.

पासकी की मदद से पुष्टि करने की सुविधा कैसे काम करती है

पासकी की मदद से पुष्टि करने के लिए, WebAuthn API का इस्तेमाल किया जाता है.

पासकी की मदद से पुष्टि करने के फ़्लो में ये चार कॉम्पोनेंट शामिल होते हैं:

• बैकएंड: यह कुकी, उपयोगकर्ता खाते की जानकारी सेव करती है. इसमें सार्वजनिक कुंजी भी शामिल है.
• फ़्रंटएंड: यह ब्राउज़र से कम्यूनिकेट करता है और बैकएंड से ज़रूरी डेटा फ़ेच करता है.
• ब्राउज़र: यह आपकी JavaScript चलाता है और WebAuthn API के साथ इंटरैक्ट करता है.
• पासकी की सुविधा देने वाली कंपनी: यह पासकी बनाती है और उसे सेव करती है. आम तौर पर, यह Google Password Manager जैसे पासवर्ड मैनेजर या सुरक्षा कुंजी होती है.

पासकी की मदद से पुष्टि करने की प्रोसेस इस तरह काम करती है:

1. जब कोई व्यक्ति साइन-इन पेज पर जाता है, तब फ़्रंटएंड, बैकएंड से पुष्टि करने के लिए चुनौती का अनुरोध करता है.
2. बैकएंड, उपयोगकर्ता के खाते से जुड़ा WebAuthn चैलेंज जनरेट करता है और उसे वापस भेजता है.
3. फ़्रंटएंड, navigator.credentials.get() को चुनौती देता है, ताकि ब्राउज़र का इस्तेमाल करके पुष्टि की जा सके.
4. ब्राउज़र, पासकी की सुविधा देने वाली कंपनी के साथ इंटरैक्ट करता है. इसके बाद, वह उपयोगकर्ता को पासकी चुनने के लिए कहता है. ऐसा अक्सर, साइन-इन फ़ील्ड पर फ़ोकस करने से ट्रिगर होने वाले, ऑटोमैटिक तरीके से भरने की सुविधा वाले डायलॉग का इस्तेमाल करके किया जाता है. साथ ही, डिवाइस के स्क्रीन लॉक या बायोमेट्रिक डेटा का इस्तेमाल करके, उपयोगकर्ता की पहचान की पुष्टि की जाती है.
5. उपयोगकर्ता की पुष्टि हो जाने के बाद, पासकी की सुविधा देने वाली कंपनी चुनौती पर हस्ताक्षर करती है. इसके बाद, ब्राउज़र, फ़्रंटएंड को सार्वजनिक पासकोड क्रेडेंशियल (हस्ताक्षर के साथ) दिखाता है.
6. फ़्रंटएंड, इस क्रेडेंशियल को बैकएंड को भेजता है.
7. बैकएंड, क्रेडेंशियल के हस्ताक्षर की पुष्टि करता है. इसके लिए, वह उपयोगकर्ता की सेव की गई सार्वजनिक कुंजी का इस्तेमाल करता है. पुष्टि हो जाने पर, बैकएंड उपयोगकर्ता को साइन इन कर लेता है.

फ़ॉर्म में अपने-आप जानकारी भरने की सुविधा का इस्तेमाल करके, पासकी से पुष्टि करना

फ़ॉर्म में अपने-आप जानकारी भरने की सुविधा का इस्तेमाल करके पासकी की पुष्टि करने की प्रोसेस शुरू करने के लिए, साइन-इन पेज लोड होने पर WebAuthn get को शर्त के साथ कॉल करें. navigator.credentials.get() को किए गए इस कॉल में mediation: 'conditional' विकल्प शामिल है.
WebAuthn के navigator.credentials.get() एपीआई को किया गया शर्त के साथ अनुरोध, यूज़र इंटरफ़ेस (यूआई) को तुरंत नहीं दिखाता है. इसके बजाय, यह तब तक 'लंबित' स्थिति में रहता है, जब तक उपयोगकर्ता, उपयोगकर्ता नाम फ़ील्ड के अपने-आप भरने वाले प्रॉम्प्ट से इंटरैक्ट नहीं करता. अगर उपयोगकर्ता पासकी चुनता है, तो ब्राउज़र, उपयोगकर्ता को साइन इन करने के लिए क्रेडेंशियल के साथ, लंबित प्रॉमिस को पूरा करता है. इससे उपयोगकर्ता, फ़ॉर्म सबमिट करने के पारंपरिक तरीके को छोड़कर साइन इन कर पाता है. अगर उपयोगकर्ता पासवर्ड चुनता है, तो प्रॉमिस पूरा नहीं होता.इसके बाद, पासवर्ड से साइन इन करने का स्टैंडर्ड फ़्लो जारी रहता है. इसके बाद, उपयोगकर्ता को साइन इन करने की ज़िम्मेदारी पेज की होती है.

फ़ॉर्म के इनपुट फ़ील्ड की व्याख्या करना

पासकी को अपने-आप भरने की सुविधा चालू करने के लिए, अपने फ़ॉर्म के उपयोगकर्ता नाम input फ़ील्ड में autocomplete एट्रिब्यूट जोड़ें. username और webauthn, दोनों को स्पेस से अलग की गई वैल्यू के तौर पर शामिल करें.

<input type="text" name="username" autocomplete="username webauthn" autofocus>

इस फ़ील्ड में autofocus जोड़ने पर, पेज लोड होने पर ऑटोमैटिक तरीके से पासवर्ड भरने का प्रॉम्प्ट अपने-आप ट्रिगर हो जाता है. इससे उपलब्ध पासवर्ड और पासकी तुरंत दिखती हैं.

सुविधा का पता लगाना

WebAuthn API को कॉल करने से पहले, यह देखें कि:

• ब्राउज़र, PublicKeyCredential के साथ WebAuthn का इस्तेमाल कर सकता है.

• ब्राउज़र, PublicKeyCredential.getClientCapabilities() की मदद से सुविधा का पता लगाने की सुविधा देता है.

• ब्राउज़र, conditionalGet के साथ WebAuthn conditional UI के साथ काम करता हो.

यहां दिए गए स्निपेट में बताया गया है कि ब्राउज़र में इन सुविधाओं का इस्तेमाल किया जा सकता है या नहीं. इसके लिए, यह तरीका अपनाएं:

if (window.PublicKeyCredential && PublicKeyCredential.getClientCapabilities) {
  const capabilities = await PublicKeyCredential.getClientCapabilities();
  // Check if conditional mediation is available.  
  if (capabilities.conditionalGet === true) {
    // The browser supports conditional mediation.
  }
}

बैकएंड से जानकारी फ़ेच करना

navigator.credentials.get() कॉल शुरू करने के लिए, आपके बैकएंड को फ़्रंटएंड को कई विकल्प देने होंगे. आम तौर पर, इन विकल्पों को आपके सर्वर पर मौजूद एंडपॉइंट से JSON ऑब्जेक्ट के तौर पर फ़ेच किया जाता है.

options ऑब्जेक्ट में मौजूद मुख्य प्रॉपर्टी में ये शामिल हैं:

• challenge: यह सर्वर से जनरेट किया गया एक चैलेंज है. यह ArrayBuffer में होता है. आम तौर पर, इसे JSON ट्रांसपोर्ट के लिए Base64URL के तौर पर कोड किया जाता है. रीप्ले अटैक को रोकने के लिए यह ज़रूरी है. आपके सर्वर को, साइन-इन करने की हर कोशिश के लिए एक नया चैलेंज जनरेट करना होगा. साथ ही, इसे कुछ समय बाद या कोशिश के पूरा न होने पर अमान्य कर देना चाहिए.
• allowCredentials: क्रेडेंशियल डिस्क्रिप्टर का कलेक्शन. खाली कलेक्शन पास करें. इससे ब्राउज़र को, तय किए गए rpId के लिए सभी क्रेडेंशियल दिखाने का अनुरोध मिलता है.

• userVerification: इससे उपयोगकर्ता की पुष्टि करने के लिए आपकी पसंद के बारे में पता चलता है. जैसे, डिवाइस के स्क्रीन लॉक की ज़रूरत होना. डिफ़ॉल्ट और सुझाई गई वैल्यू "preferred" है. इन वैल्यू का इस्तेमाल किया जा सकता है:

  • "required": उपयोगकर्ता की पुष्टि, ऑथेंटिकेटर (जैसे कि पिन या बायोमेट्रिक) के ज़रिए की जानी चाहिए. अगर पुष्टि नहीं की जा सकती, तो यह कार्रवाई पूरी नहीं होगी.
  • "preferred": पुष्टि करने वाला व्यक्ति, उपयोगकर्ता की पुष्टि करने की कोशिश करता है. हालांकि, इसके बिना भी कार्रवाई पूरी की जा सकती है.
  • "discouraged": अगर हो सके, तो पुष्टि करने वाले को उपयोगकर्ता की पुष्टि करने से बचना चाहिए.

• rpId: यह आपका रिलाइंग पार्टी आईडी होता है. आम तौर पर, यह आपकी वेबसाइट का डोमेन होता है. जैसे, example.com. यह वैल्यू, पासकी क्रेडेंशियल बनाते समय इस्तेमाल किए गए rp.id से पूरी तरह मेल खानी चाहिए.

आपके सर्वर को इस विकल्प ऑब्जेक्ट को बनाना चाहिए. ArrayBuffer वैल्यू (जैसे कि challenge) को JSON ट्रांसपोर्ट के लिए, Base64URL फ़ॉर्मैट में कोड में बदला जाना चाहिए. फ़्रंटएंड पर, JSON को पार्स करने के बाद, PublicKeyCredential.parseRequestOptionsFromJSON() का इस्तेमाल करके ऑब्जेक्ट को navigator.credentials.get() के फ़ॉर्मैट में बदलें. इसमें Base64URL स्ट्रिंग को डिकोड करना भी शामिल है.

यहां दिए गए कोड स्निपेट में, पासकी की मदद से पुष्टि करने के लिए ज़रूरी जानकारी को फ़ेच और डिकोड करने का तरीका बताया गया है.

// Fetch an encoded PubicKeyCredentialRequestOptions from the server.
const _options = await fetch('/webauthn/signinRequest');

// Deserialize and decode the PublicKeyCredentialRequestOptions.
const decoded_options = JSON.parse(_options);
const options = PublicKeyCredential.parseRequestOptionsFromJSON(decoded_options);
...

उपयोगकर्ता की पुष्टि करने के लिए, conditional फ़्लैग के साथ WebAuthn API को कॉल करें

publicKeyCredentialRequestOptions ऑब्जेक्ट तैयार होने के बाद, navigator.credentials.get() को कॉल करें, ताकि शर्तों के साथ पासकी की पुष्टि करने की प्रोसेस शुरू की जा सके. publicKeyCredentialRequestOptions ऑब्जेक्ट को यहां दिए गए उदाहरण कोड में options के तौर पर दिखाया गया है.

// To abort a WebAuthn call, instantiate an AbortController.
const abortController = new AbortController();

// Invoke WebAuthn to authenticate with a passkey.
const credential = await navigator.credentials.get({
  publicKey: options,
  signal: abortController.signal,
  // Specify 'conditional' to activate conditional UI
  mediation: 'conditional'
});

इस कॉल के मुख्य पैरामीटर:

• publicKey: यह publicKeyCredentialRequestOptions ऑब्जेक्ट होना चाहिए. उदाहरण में इसका नाम options है. इसे आपने अपने सर्वर से फ़ेच किया है और पिछले चरण में प्रोसेस किया है.
• signal: AbortController का सिग्नल (जैसे, abortController.signal) पास करने पर, get() के अनुरोध को प्रोग्राम के हिसाब से रद्द किया जा सकता है. यह तब काम आता है, जब आपको कोई दूसरा WebAuthn कॉल शुरू करना हो.
• mediation: 'conditional': यह ज़रूरी फ़्लैग है. इसकी वजह से, WebAuthn कॉल को शर्तों के साथ किया जाता है. यह ब्राउज़र को बताता है कि उसे तुरंत कोई मोडल डायलॉग दिखाने के बजाय, ऑटोमैटिक तरीके से भरने की सुविधा वाले प्रॉम्प्ट के साथ उपयोगकर्ता के इंटरैक्शन का इंतज़ार करना चाहिए.

वापस मिले सार्वजनिक पासकोड क्रेडेंशियल को आरपी सर्वर पर भेजें

Aअगर उपयोगकर्ता कोई पासकी चुनता है और अपनी पहचान की पुष्टि कर लेता है (उदाहरण के लिए, अपने डिवाइस के स्क्रीन लॉक का इस्तेमाल करके), तो navigator.credentials.get() प्रॉमिस पूरा हो जाता है. इससे आपको अपने फ़्रंटएंड पर PublicKeyCredential ऑब्जेक्ट मिलता है.

प्रॉमिस को कई वजहों से अस्वीकार किया जा सकता है. आपको अपने कोड में इन गड़बड़ियों को ठीक करना चाहिए. इसके लिए, Error ऑब्जेक्ट की name प्रॉपर्टी की जांच करें:

• NotAllowedError: उपयोगकर्ता ने कार्रवाई रद्द कर दी है या कोई पासकी नहीं चुनी गई है.
• AbortError: ऑपरेशन को बंद कर दिया गया है. ऐसा हो सकता है कि आपके कोड ने AbortController का इस्तेमाल करके ऐसा किया हो.
• अन्य अपवाद: कोई ऐसी गड़बड़ी हुई जिसकी उम्मीद नहीं थी. आम तौर पर, ब्राउज़र उपयोगकर्ता को गड़बड़ी वाला डायलॉग दिखाता है.

PublicKeyCredential ऑब्जेक्ट में कई प्रॉपर्टी होती हैं. पुष्टि करने के लिए ज़रूरी मुख्य प्रॉपर्टी में ये शामिल हैं:

• id: यह पुष्टि किए गए पासकी क्रेडेंशियल का base64url एन्कोड किया गया आईडी होता है.
• rawId: यह क्रेडेंशियल आईडी का ArrayBuffer वर्शन है.
• response.clientDataJSON: क्लाइंट डेटा का ArrayBuffer. इस फ़ील्ड में, चुनौती और उस ऑरिजिन के बारे में जानकारी होती है जिसकी पुष्टि आपके सर्वर को करनी होती है.
• response.authenticatorData: यह पुष्टि करने वाले व्यक्ति के डेटा का ArrayBuffer होता है. इस फ़ील्ड में आरपी आईडी जैसी जानकारी शामिल होती है.
• response.signature: हस्ताक्षर वाला ArrayBuffer. यह वैल्यू, क्रेडेंशियल का मुख्य हिस्सा होती है. आपके सर्वर को इस हस्ताक्षर की पुष्टि करनी होगी. इसके लिए, उसे क्रेडेंशियल के लिए सेव की गई सार्वजनिक कुंजी का इस्तेमाल करना होगा.
• response.userHandle: यह एक ArrayBuffer है. इसमें पासकी रजिस्टर करते समय दिया गया यूज़र आईडी होता है.
• authenticatorAttachment: इससे पता चलता है कि पुष्टि करने वाला ऐप्लिकेशन, क्लाइंट डिवाइस (platform) का हिस्सा है या बाहरी (cross-platform). cross-platform अटैचमेंट तब हो सकता है, जब उपयोगकर्ता ने फ़ोन से साइन इन किया हो. ऐसे मामलों में, उन्हें पासकी बनाने के लिए कहें, ताकि वे आने वाले समय में आसानी से साइन इन कर सकें.
• type: यह फ़ील्ड हमेशा "public-key" पर सेट होता है.

इस PublicKeyCredential ऑब्जेक्ट को अपने बैकएंड में भेजने के लिए, सबसे पहले .toJSON() तरीके को कॉल करें. इस तरीके से, क्रेडेंशियल का JSON-सीरियलाइज़ेबल वर्शन बनाया जाता है. यह ArrayBuffer प्रॉपर्टी (जैसे कि rawId, clientDataJSON, authenticatorData, signature, और userHandle) को Base64URL एन्कोड की गई स्ट्रिंग में सही तरीके से बदलता है. इसके बाद, इस ऑब्जेक्ट को स्ट्रिंग में बदलने के लिए JSON.stringify() का इस्तेमाल करें और इसे सर्वर को भेजे जाने वाले अनुरोध की बॉडी में भेजें.

...
// Encode and serialize the PublicKeyCredential.
const _result = credential.toJSON();
const result = JSON.stringify(_result);

// Encode and send the credential to the server for verification.  
const response = await fetch('/webauthn/signinResponse', {
  method: 'post',
  credentials: 'same-origin',
  body: result
});

हस्ताक्षर की पुष्टि करना

जब आपके बैकएंड सर्वर को सार्वजनिक कुंजी क्रेडेंशियल मिलता है, तो उसे इसकी पुष्टि करनी होती है कि यह असली है. इसमें ये चीज़ें शामिल हैं:

1. क्रेडेंशियल डेटा को पार्स किया जा रहा है.
2. क्रेडेंशियल के id से जुड़ी सेव की गई सार्वजनिक पासकोड की जानकारी ढूंढना.
3. स्टोर की गई सार्वजनिक कुंजी के हिसाब से, मिले हुए signature की पुष्टि करना.
4. अन्य डेटा की पुष्टि करना. जैसे, चैलेंज और ऑरिजिन.

हमारा सुझाव है कि इन क्रिप्टोग्राफ़िक कार्रवाइयों को सुरक्षित तरीके से मैनेज करने के लिए, सर्वर साइड FIDO/WebAuthn लाइब्रेरी का इस्तेमाल करें. आपको awesome-webauthn GitHub repo में ओपन सोर्स लाइब्रेरी मिल सकती हैं.

अगर हस्ताक्षर और अन्य सभी दावे मान्य हैं, तो सर्वर उपयोगकर्ता को साइन इन कर सकता है. सर्वर-साइड से होने वाली पुष्टि के बारे में ज़्यादा जानने के लिए, सर्वर-साइड से पासकी की पुष्टि करना लेख पढ़ें

अगर बैकएंड पर मैच करने वाले क्रेडेंशियल नहीं मिलते हैं, तो सिग्नल दें

अगर साइन-इन के दौरान आपका बैकएंड सर्वर, मैचिंग आईडी वाला क्रेडेंशियल नहीं ढूंढ पाता है, तो हो सकता है कि उपयोगकर्ता ने पहले आपके सर्वर से इस पासकी को मिटा दिया हो, लेकिन पासकी की सुविधा देने वाली कंपनी से नहीं. अगर पासकी की सुविधा देने वाली कंपनी, ऐसी पासकी का सुझाव देती है जो आपकी साइट पर काम नहीं करती है, तो इस अंतर की वजह से उपयोगकर्ता को भ्रम हो सकता है. इसे बेहतर बनाने के लिए, आपको पासकी की सुविधा देने वाली कंपनी को अनाथ पासकी हटाने का सिग्नल देना चाहिए.

PublicKeyCredential.signalUnknownCredential() तरीके का इस्तेमाल किया जा सकता है. यह Webauthn Signal API का हिस्सा है. इसका इस्तेमाल, पासकी की सुविधा देने वाली कंपनी को यह बताने के लिए किया जा सकता है कि बताई गई क्रेडेंशियल हटा दी गई है या मौजूद नहीं है. अगर आपका सर्वर यह बताता है कि दिखाया गया क्रेडेंशियल आईडी मौजूद नहीं है (उदाहरण के लिए, किसी खास एचटीटीपी स्टेटस कोड, जैसे कि 404 के साथ), तो क्लाइंट-साइड पर इस स्टैटिक तरीके को कॉल करें. इस तरीके के लिए, आरपी आईडी और अनजान क्रेडेंशियल आईडी दें. अगर पासकी की सुविधा देने वाली कंपनी इस सिग्नल के साथ काम करती है, तो उसे पासकी हटा देनी चाहिए.

// Detect authentication failure due to lack of the credential
if (response.status === 404) {
  // Feature detection
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" // base64url encoded credential ID
    });
  } else {
    // Encourage the user to delete the passkey from the password manager nevertheless.
    ...
  }
}

पुष्टि हो जाने के बाद

उपयोगकर्ता ने जिस तरीके से साइन इन किया है उसके हिसाब से, हम उसे अलग-अलग फ़्लो फ़ॉलो करने का सुझाव देते हैं.

अगर उपयोगकर्ता ने पासकी के बिना साइन इन किया है

अगर उपयोगकर्ता ने पासकी के बिना आपकी वेबसाइट में साइन इन किया है, तो हो सकता है कि उसके पास उस खाते या मौजूदा डिवाइस के लिए कोई पासकी रजिस्टर न हो. पासकी बनाने के लिए यह सही समय है. इन तरीकों को आज़माएं:

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

उपयोगकर्ताओं को पासकी बनाने के लिए बढ़ावा देने और अन्य सबसे सही तरीकों के बारे में जानने के लिए, उपयोगकर्ताओं को पासकी के बारे में जानकारी देना लेख में दिए गए उदाहरण देखें.

अगर उपयोगकर्ता ने पासकी से साइन इन किया है

जब कोई उपयोगकर्ता पासकी की मदद से साइन इन कर लेता है, तो आपके पास उसके अनुभव को बेहतर बनाने और खाते को सुरक्षित रखने के कई मौके होते हैं.

किसी दूसरे डिवाइस से पुष्टि करने के बाद, नई पासकी बनाने के लिए बढ़ावा देना

अगर कोई व्यक्ति, क्रॉस-डिवाइस मेकेनिज़्म (उदाहरण के लिए, अपने फ़ोन से क्यूआर कोड स्कैन करना) का इस्तेमाल करके पासकी से साइन इन करता है, तो हो सकता है कि इस्तेमाल की गई पासकी, उस डिवाइस पर स्थानीय तौर पर सेव न हो जिस पर वह साइन इन कर रहा है. ऐसा तब हो सकता है जब:

• उनके पास पासकी है, लेकिन पासकी उपलब्ध कराने वाली ऐसी कंपनी की पासकी है जो साइन इन करने के लिए इस्तेमाल किए जा रहे ऑपरेटिंग सिस्टम या ब्राउज़र के साथ काम नहीं करती.
• उन्होंने साइन इन करने वाले डिवाइस पर, पासकी की सुविधा देने वाली कंपनी का ऐक्सेस खो दिया है. हालांकि, पासकी अब भी किसी दूसरे डिवाइस पर उपलब्ध है.

ऐसे में, उपयोगकर्ता को मौजूदा डिवाइस पर नई पासकी बनाने के लिए कहें. इससे उन्हें आने वाले समय में, अलग-अलग डिवाइसों पर साइन इन करने की प्रोसेस को दोहराने की ज़रूरत नहीं पड़ेगी. यह पता लगाने के लिए कि उपयोगकर्ता ने किसी दूसरे डिवाइस पर मौजूद पासकी का इस्तेमाल करके साइन इन किया है या नहीं, क्रेडेंशियल की authenticatorAttachment प्रॉपर्टी देखें. अगर इसकी वैल्यू "cross-platform" है, तो इसका मतलब है कि पुष्टि अलग-अलग डिवाइसों पर की गई है. अगर ऐसा है, तो उन्हें नई पासकी बनाने के फ़ायदे बताएं. साथ ही, पासकी बनाने की प्रोसेस के बारे में जानकारी दें.

सिग्नल का इस्तेमाल करके, सेवा देने वाली कंपनी के साथ पासकी की जानकारी सिंक करना

पासकी की सुविधा देने वाली कंपनी, WebAuthn Signals API का इस्तेमाल करके, क्रेडेंशियल और उपयोगकर्ता की जानकारी से जुड़े अपडेट, Relying Party (RP) को भेज सकती है. इससे, उपयोगकर्ताओं को बेहतर अनुभव मिलता है और उन्हें एक जैसा अनुभव मिलता है.

उदाहरण के लिए, किसी उपयोगकर्ता की पासकी की सूची को पासकी उपलब्ध कराने वाली कंपनी के पास अपडेट रखने के लिए, बैकएंड में क्रेडेंशियल को सिंक रखें. यह सूचना दी जा सकती है कि अब कोई पासकी मौजूद नहीं है, ताकि पासकी की सुविधा देने वाली कंपनियां गैर-ज़रूरी पासकी हटा सकें.

इसी तरह, यह सूचना दी जा सकती है कि किसी उपयोगकर्ता ने आपकी सेवा पर अपना उपयोगकर्ता नाम या डिसप्ले नेम अपडेट किया है. इससे पासकी की सुविधा देने वाली कंपनी को, उपयोगकर्ता की जानकारी को अप-टू-डेट रखने में मदद मिलती है. उदाहरण के लिए, खाता चुनने के डायलॉग में.

पासकी को एक जैसा बनाए रखने के सबसे सही तरीकों के बारे में ज़्यादा जानने के लिए, Signal API की मदद से, अपने सर्वर पर क्रेडेंशियल के साथ पासकी को एक जैसा बनाए रखें लेख पढ़ें.

दूसरे चरण की पुष्टि न मांगें

पासकी, फ़िशिंग जैसे आम खतरों से बचने के लिए मज़बूत सुरक्षा देती हैं. इसलिए, पुष्टि करने के दूसरे तरीके से सुरक्षा को ज़्यादा फ़ायदा नहीं मिलता. इसके बजाय, यह साइन-इन के दौरान उपयोगकर्ताओं के लिए एक ग़ैर-ज़रूरी चरण बनाता है.

चेकलिस्ट

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

संसाधन

• सर्वर-साइड पासकी ऑथेंटिकेशन
• पासवर्ड के बिना लॉग इन करने के लिए पासकी बनाना
• उपयोगकर्ताओं को पासकी को असरदार तरीके से मैनेज करने में मदद करना
• पासकी
• Apple का दस्तावेज़: वेब सेवा के ज़रिए किसी उपयोगकर्ता की पुष्टि करना
• Google दस्तावेज़: पासकी की मदद से बिना पासवर्ड के लॉगिन करना