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

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

Eiji Kitamura

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

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

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

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

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

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

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

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

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

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

यह कैसे काम करता है

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

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

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

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

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

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

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

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

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

फ़ीचर का पता लगाना

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

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

• ब्राउज़र पर PublicKeyCredential.isConditionalMediationAvailable() के साथ, 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  
  }  
}  

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

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

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

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

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

उपयोगकर्ता की पुष्टि होने का इंतज़ार शुरू करने के लिए, 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' की जानकारी देना न भूलें.

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

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

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

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

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

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

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

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

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

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

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

ज़्यादा जानकारी के लिए, सर्वर-साइड पासकी की पुष्टि पर जाएं

संसाधन

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