बिना पासवर्ड के लॉगिन करने के लिए पासकी बनाएं

पासकी से उपयोगकर्ता के खाते ज़्यादा सुरक्षित और आसानी से इस्तेमाल किए जा सकते हैं.

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

उपयोगकर्ता खाते से जुड़ी पासकी बनाई जानी चाहिए. साथ ही, उपयोगकर्ता उससे साइन इन कर सके, इसके लिए उसकी सार्वजनिक कुंजी को आपके सर्वर पर सेव किया जाना चाहिए.

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

उपयोगकर्ता से इनमें से किसी स्थिति में पासकी बनाने के लिए कहा जा सकता है:

• जब कोई उपयोगकर्ता पासवर्ड का इस्तेमाल करके साइन इन करता है.
• जब कोई उपयोगकर्ता किसी दूसरे डिवाइस से पासकी का इस्तेमाल करके साइन इन करता है, तो authenticatorAttachment cross-platform होता है.
• एक खास पेज पर, जहां उपयोगकर्ता अपनी पासकी मैनेज कर सकते हैं.

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

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

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

किसी मौजूदा उपयोगकर्ता खाते में नई पासकी जोड़ने का तरीका यहां बताया गया है:

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

साथ काम करने वाले वर्शन

ज़्यादातर ब्राउज़र में WebAuthn काम करता है, लेकिन इसमें कुछ अंतर हैं. डिवाइस सहायता - passkeys.dev पर जाएं और जानें कि किन ब्राउज़र और ऑपरेटिंग सिस्टम के कॉम्बिनेशन पर पासकी बनाई जा सकती है.

नई पासकी बनाना

नई पासकी बनाने के अनुरोध पर, फ़्रंटएंड को कैसे काम करना चाहिए, यह यहां बताया गया है.

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

"नई पासकी बनाएं" बटन दिखाने से पहले, देखें कि:

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

• डिवाइस पर PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() के साथ, प्लैटफ़ॉर्म Authenticator की सुविधा काम करती हो. यह सुविधा, पासकी बनाने और पासकी की मदद से पुष्टि करने की सुविधा देती है.

• ब्राउज़र पर PublicKeyCredenital.isConditionalMediationAvailable() के साथ, WebAuthn के लिए शर्तों के हिसाब से यूज़र इंटरफ़ेस (यूआई) काम करता हो.

// Availability of `window.PublicKeyCredential` means WebAuthn is usable.  
// `isUserVerifyingPlatformAuthenticatorAvailable` means the feature detection is usable.  
// `​​isConditionalMediationAvailable` means the feature detection is usable.  
if (window.PublicKeyCredential &&  
    PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable &&  
    PublicKeyCredential.​​isConditionalMediationAvailable) {  
  // Check if user verifying platform authenticator is available.  
  Promise.all([  
    PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable(),  
    PublicKeyCredential.​​isConditionalMediationAvailable(),  
  ]).then(results => {  
    if (results.every(r => r === true)) {  
      // Display "Create a new passkey" button  
    }  
  });  
}  

जब तक सभी शर्तें पूरी नहीं हो जातीं, तब तक इस ब्राउज़र पर पासकी काम नहीं करेंगी. तब तक, "नई पासकी बनाएं" बटन नहीं दिखना चाहिए.

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

जब उपयोगकर्ता बटन पर क्लिक करता है, तो बैकएंड से navigator.credentials.create() को कॉल करने के लिए ज़रूरी जानकारी फ़ेच करें:

• challenge: इस रजिस्ट्रेशन के लिए, सर्वर से जनरेट किया गया ArrayBuffer में मौजूद चैलेंज. यह जानकारी ज़रूरी है, लेकिन रजिस्ट्रेशन के दौरान इसका इस्तेमाल नहीं किया जाता. हालांकि, पुष्टि के दौरान इसका इस्तेमाल किया जाता है. यह एक ऐसा ऐडवांस विषय है जिसके बारे में यहां नहीं बताया गया है.
• user.id: उपयोगकर्ता का यूनीक आईडी. यह वैल्यू एक ArrayBuffer होनी चाहिए, जिसमें व्यक्तिगत पहचान से जुड़ी जानकारी शामिल न हो. उदाहरण के लिए, ईमेल पते या उपयोगकर्ता नाम. हर खाते के लिए, 16-बाइट की कोई भी वैल्यू जनरेट की जा सकती है.
• user.name: इस फ़ील्ड में, उस खाते का यूनीक आइडेंटिफ़ायर होना चाहिए जिसे उपयोगकर्ता पहचान पाए. जैसे, उसका ईमेल पता या उपयोगकर्ता नाम. यह नाम, खाता चुनने वाले टूल में दिखेगा. (अगर उपयोगकर्ता नाम का इस्तेमाल किया जा रहा है, तो पासवर्ड की पुष्टि करने के लिए इस्तेमाल की गई वैल्यू का ही इस्तेमाल करें.)
• user.displayName: यह फ़ील्ड ज़रूरी है. इसमें खाते का ऐसा नाम डालें जो उपयोगकर्ता के लिए आसान हो. यह ज़रूरी नहीं है कि यह नाम यूनीक हो. यह उपयोगकर्ता का चुना गया नाम हो सकता है. अगर आपकी साइट में यहां शामिल करने के लिए कोई सही वैल्यू नहीं है, तो खाली स्ट्रिंग पास करें. यह ब्राउज़र के आधार पर, खाता चुनने वाले टूल पर दिख सकता है.
• excludeCredentials: पहले से रजिस्टर किए गए क्रेडेंशियल आईडी की सूची देकर, एक ही डिवाइस को रजिस्टर करने से रोकता है. अगर transports सदस्य की जानकारी दी गई है, तो हर क्रेडेंशियल के रजिस्ट्रेशन के दौरान, getTransports() को कॉल करने का नतीजा दिखना चाहिए.

पासकी बनाने के लिए, WebAuthn API को कॉल करना

नई पासकी बनाने के लिए, navigator.credentials.create() को कॉल करें. एपीआई, उपयोगकर्ता के इंटरैक्शन के इंतज़ार में, एक प्रॉमिस दिखाता है. यह इंटरैक्शन, मॉडल डायलॉग दिखाकर किया जाता है.

const publicKeyCredentialCreationOptions = {
  challenge: *****,
  rp: {
    name: "Example",
    id: "example.com",
  },
  user: {
    id: *****,
    name: "john78",
    displayName: "John",
  },
  pubKeyCredParams: [{alg: -7, type: "public-key"},{alg: -257, type: "public-key"}],
  excludeCredentials: [{
    id: *****,
    type: 'public-key',
    transports: ['internal'],
  }],
  authenticatorSelection: {
    authenticatorAttachment: "platform",
    requireResidentKey: true,
  }
};

const credential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions
});

// Encode and send the credential to the server for verification.  

ऊपर जिन पैरामीटर के बारे में नहीं बताया गया है वे ये हैं:

• rp.id: आरपी आईडी एक डोमेन होता है. वेबसाइट, अपने डोमेन या रजिस्टर किए जा सकने वाले सफ़िक्स में से किसी एक की जानकारी दे सकती है. उदाहरण के लिए, अगर किसी आरपी का ऑरिजिन https://login.example.com:1337 है, तो आरपी आईडी login.example.com या example.com हो सकता है. अगर आरपी आईडी के तौर पर example.com दिया गया है, तो उपयोगकर्ता login.example.com या example.com के किसी भी सबडोमेन पर पुष्टि कर सकता है.

• rp.name: आरपी का नाम.

• pubKeyCredParams: इस फ़ील्ड में, आरपी के साथ काम करने वाले सार्वजनिक-कुंजी एल्गोरिदम की जानकारी दी जाती है. हमारा सुझाव है कि आप इसे [{alg: -7, type: "public-key"},{alg: -257, type: "public-key"}] पर सेट करें. इससे पता चलता है कि P-256 और RSA PKCS#1 के साथ ECDSA काम करता है. इनका इस्तेमाल करने से, पूरी कवरेज मिलती है.

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

• authenticatorSelection.requireResidentKey: इसे बूलियन "true" पर सेट करें. डिस्कवर किया जा सकने वाला क्रेडेंशियल (रेज़िडेंट पासकी), पासकी में उपयोगकर्ता की जानकारी सेव करता है. साथ ही, पुष्टि करने के बाद उपयोगकर्ताओं को खाता चुनने की सुविधा देता है. ऐसे क्रेडेंशियल के बारे में ज़्यादा जानें जिन्हें ऐक्सेस किया जा सकता है

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

  लेख पढ़ें.

वापस मिले सार्वजनिक पासकोड क्रेडेंशियल को बैकएंड पर भेजना

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

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

• InvalidStateError: डिवाइस पर पहले से ही पासकी मौजूद है. उपयोगकर्ता को कोई गड़बड़ी वाला डायलॉग नहीं दिखेगा. साथ ही, साइट को इसे गड़बड़ी के तौर पर नहीं मानना चाहिए—उपयोगकर्ता ने स्थानीय डिवाइस को रजिस्टर करने के लिए कहा था और वह रजिस्टर हो गया है.
• NotAllowedError: उपयोगकर्ता ने कार्रवाई को रद्द कर दिया है.
• अन्य अपवाद: कोई गड़बड़ी हुई. ब्राउज़र, उपयोगकर्ता को गड़बड़ी का डायलॉग दिखाता है.

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

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

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

क्रेडेंशियल सेव करना

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

इसके बाद, क्रेडेंशियल से मिली जानकारी को डेटाबेस में सेव किया जा सकता है, ताकि आने वाले समय में उसका इस्तेमाल किया जा सके. यहां दी गई सूची में, सेव करने के लिए कुछ सामान्य प्रॉपर्टी शामिल हैं:

• क्रेडेंशियल आईडी (प्राइमरी कुंजी)
• User ID
• सार्वजनिक कुंजी

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

• बैकअप लेने की ज़रूरी शर्तों का पता लगाने वाला फ़्लैग: true अगर डिवाइस, पासकी सिंक करने की ज़रूरी शर्तें पूरी करता है.
• बैकअप की स्थिति का फ़्लैग: true अगर बनाई गई पासकी, सिंक करने के लिए सेट है.
• ट्रांसपोर्ट: डिवाइस पर काम करने वाले ट्रांसपोर्ट की सूची: "internal" का मतलब है कि डिवाइस पर पासकी काम करती है, "hybrid" का मतलब है कि यह किसी दूसरे डिवाइस पर पुष्टि करने की सुविधा भी देता है.

ज़्यादा जानकारी के लिए, सर्वर-साइड पासकी रजिस्टर करने के बारे में लेख पढ़ें

उपयोगकर्ता की पुष्टि करने के लिए, फ़ॉर्म में जानकारी अपने-आप भरने की सुविधा की मदद से, पासकी से साइन इन करना लेख पढ़ें.

संसाधन

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