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

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

Eiji Kitamura

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

ध्यान दें: पासकी के बुनियादी सिद्धांत जानने के लिए, पासकी की मदद से बिना पासवर्ड के लॉगिन करने की सुविधा देखें.

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

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

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

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

पासकी बनाने के लिए, WebAuthn API का इस्तेमाल करें.

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

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

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

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

इस सुविधा के साथ काम करने वाले कैंपेन

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

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

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

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

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

• ब्राउज़र पर WebAuthn काम करता है.
• डिवाइस पर प्लैटफ़ॉर्म की पुष्टि करने वाला टूल काम करता हो (पासकी बना सकता है और पासकी की मदद से पुष्टि कर सकता है).
• ब्राउज़र पर 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() को कॉल करने का नतीजा दिया जाना चाहिए.

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

पासकी बनाने के लिए, 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 और आरएसए PKCS#1 के साथ ईसीडीएसए के लिए सहायता के बारे में पता चलता है. साथ ही, इनके साथ काम करने से पूरी कवरेज मिलती है.

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

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

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

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

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

ध्यान दें: कुछ ब्राउज़र में पासकी बनाने के लिए, authenticatorSelection पर किसी भी पैरामीटर की ज़रूरत नहीं होती. हालांकि, कुछ ब्राउज़र में ऐसा हो सकता है. हमारा सुझाव है कि आप उन पैरामीटर के बारे में साफ़ तौर पर बताएं.

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

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

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

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

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

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

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

ध्यान दें: इसके अलावा, क्रेडेंशियल के एलिमेंट को फिर से पाने के लिए, response सदस्य - AuthenticatorAttestationResponse — की मदद से, getTransports(), getPublicKey(), getAuthenticatorData(), और getPublicKeyAlgorithm() फ़ंक्शन के एलिमेंट वापस पाए जा सकते हैं.

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

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

ध्यान दें: हमारा सुझाव है कि आप सार्वजनिक पासकोड वाले क्रेडेंशियल को प्रोसेस करने के लिए, अपना कोड लिखने के बजाय सर्वर साइड लाइब्रेरी या किसी समाधान का इस्तेमाल करें. सार्वजनिक पासकोड के क्रेडेंशियल प्रोसेस करने के लिए, ओपन-सोर्स लाइब्रेरी देखें.

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

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

सार्वजनिक कुंजी वाले क्रेडेंशियल में यहां दी गई जानकारी भी शामिल होती है, जिसे आपको डेटाबेस में सेव करना पड़ सकता है:

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

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

संसाधन

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