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

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

Eiji Kitamura

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

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

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

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

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

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

कंडिशनल यूज़र इंटरफ़ेस (यूआई)

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

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

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

हो गया: जब कोई उपयोगकर्ता पासवर्ड से साइन इन करता है, तो उस सुविधा का इस्तेमाल करके, उसे पासकी बनाने का ऑफ़र दें.

स्पेस कैसे काम करता है

पासकी की मदद से पुष्टि करने के लिए, WebAuthn एपीआई का इस्तेमाल करें.

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

• बैकएंड: आपका बैकएंड सर्वर, जिसमें खातों का डेटाबेस होता है. इसमें सार्वजनिक पासकोड और पासकी के बारे में अन्य मेटाडेटा सेव होता है.
• फ़्रंटएंड: आपका फ़्रंटएंड, जो ब्राउज़र से संपर्क करता है और बैकएंड को अनुरोध भेजता है.
• ब्राउज़र: उपयोगकर्ता का ब्राउज़र, जिस पर आपकी JavaScript चल रही है.
• Authenticator: उपयोगकर्ता का ऑथेंटिकेटर, जो पासकी बनाता और सेव करता है. यह ब्राउज़र, दोनों (जैसे कि Windows Hello का इस्तेमाल करते समय) या फ़ोन जैसे किसी दूसरे डिवाइस, दोनों पर एक ही डिवाइस हो सकता है.

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

ज़रूरी शर्तें

कंडिशनल WebAuthn यूज़र इंटरफ़ेस (यूआई), iOS 16, iPadOS 16, और macOS Ventura पर Safari में सार्वजनिक रूप से काम करता है. यह सुविधा Android, macOS, और Windows 11 22H2 पर Chrome पर भी उपलब्ध है.

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

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

फ़ॉर्म इनपुट फ़ील्ड को एनोटेट करें

अगर ज़रूरी हो, तो उपयोगकर्ता नाम input फ़ील्ड में autocomplete एट्रिब्यूट जोड़ें. username और webauthn को इसके टोकन के तौर पर जोड़ें, ताकि यह पासकी के सुझाव दे सके.

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

सुविधा की पहचान

शर्तों के साथ WebAuthn API कॉल शुरू करने से पहले, देख लें कि:

• ब्राउज़र पर WebAuthn काम करता है.
• ब्राउज़र पर WebAuthn कंडिशनल यूज़र इंटरफ़ेस (यूआई) काम करता है.

// Availability of `window.PublicKeyCredential` means WebAuthn is usable.  
if (window.PublicKeyCredential &&  
    PublicKeyCredential.​​isConditionalMediationAvailable) {  
  // Check if conditional mediation is available.  
  const isCMA = await PublicKeyCredential.​​isConditionalMediationAvailable();  
  if (isCMA) {  
    // Call WebAuthn authentication  
  }  
}  

आरपी सर्वर से कोई चैलेंज फ़ेच करें

आरपी सर्वर से ऐसा चैलेंज फ़ेच करें जिसे कॉल करने के लिए ज़रूरी हो navigator.credentials.get():

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

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

  चेतावनी: "preferred" पर सेट userVerification वाले अनुरोधों के लिए, पुष्टि करने वाले लोग उपयोगकर्ता की पुष्टि की जांच को स्किप कर सकते हैं. उदाहरण के लिए, अगर डिवाइस में कोई बायोमेट्रिक सेंसर नहीं है, तो उपयोगकर्ता ने इसे सेट अप नहीं किया है (फ़िंगरप्रिंट रजिस्टर नहीं किया है) या सेंसर कुछ समय के लिए उपलब्ध न हो (लैपटॉप जिस पर डिसप्ले का लिड बंद हो).
  जवाब के पुष्टि करने वाले डेटा में मौजूद यूवी बिट से हमेशा यह पता चलता है कि उपयोगकर्ता की पुष्टि हुई है या नहीं. अगर आपको यह पक्का करना है कि यह दो तरीकों से पुष्टि है, तो यूवी बिट बंद होने पर दूसरा चरण (जैसे कि पासवर्ड) पूछें.
  इसके अलावा, userVerification को "required" पर सेट भी किया जा सकता है.

ध्यान दें: सर्वर से ट्रांसफ़र की गई ArrayBuffer की वैल्यू, जैसे कि challenge, user.id, और excludeCredentials के लिए id क्रेडेंशियल, ट्रांसमिशन के दौरान कोड में बदले जाने चाहिए. WebAuthn API कॉल में वैल्यू को पास करने से पहले, RP फ़्रंटएंड पर उन्हें डिकोड करना न भूलें. हमारा सुझाव है कि Base64URL एन्कोडिंग का इस्तेमाल करें.

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

उपयोगकर्ता की पुष्टि होने का इंतज़ार करने के लिए, navigator.credentials.get() पर कॉल करें.

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

const publicKeyCredentialRequestOptions = {
  // Server generated challenge
  challenge: ****,
  // The same RP ID as used during registration
  rpId: 'example.com',
};

const credential = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions,
  signal: abortController.signal,
  // Specify 'conditional' to activate conditional UI
  mediation: 'conditional'
});

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

अनुरोध को शर्तों के साथ सेट करने के लिए, mediation: 'conditional' बताना न भूलें.

ध्यान दें: यहां WebAuthn कॉल की प्रोसेस पूरी नहीं होगी. साथ ही, प्रॉमिस तब तक पूरा नहीं होगा, जब तक उपयोगकर्ता, ऑटोमैटिक भरने वाले इनपुट एलिमेंट से इंटरैक्ट करके पुष्टि करने की प्रक्रिया पूरी नहीं कर लेता. आरपी फ़्रंटएंड, WebAuthn कॉल को रद्द करने के लिए AbortController का इस्तेमाल कर सकता है.

लौटाए गए सार्वजनिक पासकोड का क्रेडेंशियल, आरपी सर्वर को भेजें

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

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

• NotAllowedError: उपयोगकर्ता ने कार्रवाई रद्द कर दी है.
• अन्य अपवाद: कोई गड़बड़ी हुई. ब्राउज़र, उपयोगकर्ता को गड़बड़ी वाला डायलॉग दिखाता है.

सार्वजनिक पासकोड के क्रेडेंशियल वाले ऑब्जेक्ट में ये प्रॉपर्टी शामिल हैं:

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

अगर आरपी सर्वर पर सार्वजनिक पासकोड क्रेडेंशियल ऑब्जेक्ट को मैनेज करने के लिए किसी लाइब्रेरी का इस्तेमाल किया जाता है, तो हमारा सुझाव है कि आप पूरे ऑब्जेक्ट को base64url की मदद से कोड में बदलने के बाद, सर्वर पर भेजें.

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

जब आपको सर्वर पर सार्वजनिक पासकोड का क्रेडेंशियल मिलता है, तो ऑब्जेक्ट को प्रोसेस करने के लिए, इसे FIDO लाइब्रेरी को पास करें.

id प्रॉपर्टी से मेल खाने वाला क्रेडेंशियल आईडी खोजें (अगर आपको उपयोगकर्ता खाता तय करना है, तो उस userHandle प्रॉपर्टी का इस्तेमाल करें जो आपने क्रेडेंशियल बनाते समय तय की है).user.id देखें कि सेव किए गए सार्वजनिक पासकोड से क्रेडेंशियल के signature की पुष्टि की जा सकती है या नहीं. ऐसा करने के लिए, हमारा सुझाव है कि आप अपना कोड लिखने के बजाय, सर्वर साइड लाइब्रेरी या किसी समाधान का इस्तेमाल करें. आपको शानदार webauth GitHub रेपो में, ओपन सोर्स लाइब्रेरी मिल सकती हैं.

क्रेडेंशियल की पुष्टि किसी सार्वजनिक कुंजी से हो जाने पर, उपयोगकर्ता को साइन इन करें.

संसाधन

• बिना पासवर्ड के लॉगिन के लिए पासकी बनाना
• पासकी
• Apple दस्तावेज़: वेब सेवा के ज़रिए उपयोगकर्ता की पुष्टि करना
• Google दस्तावेज़: पासकी की मदद से बिना पासवर्ड के लॉगिन करना