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

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

Eiji Kitamura

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

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

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

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

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

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

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

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

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

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

यह किन सुविधाओं के साथ काम करती है

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

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

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

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

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

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

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

• ब्राउज़र पर PublicKeyCredenital.isConditionalMediationAvailable() के साथ WebAuthn condition यूज़र इंटरफ़ेस (यूआई) काम करता है.

// 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 के साथ ईसीएसडीए का इस्तेमाल किया जा सकता है. साथ ही, इनका इस्तेमाल करने से पूरी कवरेज मिलती है.

• 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: अरेबफ़र कोड में बदला गया प्रमाणित करने वाला ऑब्जेक्ट. इसमें अहम जानकारी होती है, जैसे कि आरपी आईडी, फ़्लैग, और सार्वजनिक पासकोड.
• authenticatorAttachment: इस क्रेडेंशियल को पासकी की सुविधा वाले डिवाइस पर बनाए जाने पर, "platform" दिखाता है.
• type: यह फ़ील्ड हमेशा "public-key" पर सेट होता है.

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

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

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

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

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

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

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

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

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

संसाधन

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