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

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

Eiji Kitamura

पब्लिश करने की तारीख: 12 अक्टूबर, 2022, पिछली बार अपडेट करने की तारीख: 09 अप्रैल, 2026

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

पासकी की सुविधा देने वाली कंपनियों, जैसे कि Google Password Manager और iCloud Keychain की मदद से, पासकी को सभी डिवाइसों पर सिंक किया जाता है.

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

पासकी बनाने की सुविधा कैसे काम करती है

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

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

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

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

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

• बैकएंड: यह कुकी, उपयोगकर्ता खाते की जानकारी सेव करती है. इसमें सार्वजनिक कुंजी भी शामिल है.
• फ़्रंटएंड: यह ब्राउज़र से कम्यूनिकेट करता है और बैकएंड से ज़रूरी डेटा फ़ेच करता है.
• ब्राउज़र: यह आपकी JavaScript चलाता है और WebAuthn API के साथ इंटरैक्ट करता है.
• पासकी की सुविधा देने वाली कंपनी: यह पासकी बनाती है और उसे सेव करती है. यह आम तौर पर, Google Password Manager जैसे पासवर्ड मैनेजर या सुरक्षा कुंजी होती है.

पासकी बनाने से पहले, पक्का करें कि सिस्टम में ये ज़रूरी शर्तें पूरी की गई हों:

• उपयोगकर्ता खाते की पुष्टि, सुरक्षित तरीके से की जाती है. जैसे, ईमेल, फ़ोन से पुष्टि करना या पहचान फ़ेडरेशन. यह पुष्टि, कम समय में की जाती है.

• फ़्रंटएंड और बैकएंड, क्रेडेंशियल डेटा को सुरक्षित तरीके से शेयर कर सकते हैं.

• ब्राउज़र पर WebAuthn और पासकी बनाने की सुविधा काम करती हो.

हम आपको यहां दिए गए सेक्शन में, इनमें से ज़्यादातर को देखने का तरीका बता सकते हैं.

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

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

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

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

ज़्यादातर ब्राउज़र में WebAuthn काम करता है. हालांकि, कुछ ब्राउज़र में यह सुविधा उपलब्ध नहीं है. ब्राउज़र और ओएस के साथ काम करने की सुविधा के बारे में जानने के लिए, passkeys.dev पर जाएं.

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

नई पासकी बनाने के लिए, फ़्रंटएंड को यह प्रोसेस अपनानी चाहिए:

1. देखें कि यह सुविधा किन डिवाइसों और ऐप्लिकेशन पर काम करती है.
2. बैकएंड से जानकारी फ़ेच करें.
3. पासकी बनाने के लिए, WebAuth API को कॉल करें.
4. वापस भेजी गई सार्वजनिक पासकोड को बैकएंड में भेजें.
5. क्रेडेंशियल सेव करें.

यहां दिए गए सेक्शन में, ऐसा करने का तरीका बताया गया है.

संगतता की जाँच करें

"नई पासकी बनाएं" बटन दिखाने से पहले, फ़्रंटएंड को यह जांच करनी चाहिए कि:

• ब्राउज़र, PublicKeyCredential के साथ WebAuthn का इस्तेमाल करने की सुविधा देता है.

• ब्राउज़र, PublicKeyCredential.getClientCapabilities() की मदद से सुविधा का पता लगाने की सुविधा देता है.

• ब्राउज़र, conditionalGet के साथ WebAuthn conditional UI के साथ काम करता हो.

• डिवाइस पर प्लैटफ़ॉर्म ऑथेंटिकेटर (डिवाइस पर पासकी बना सकता है और पुष्टि कर सकता है) के साथ passkeyPlatformAuthenticator काम करता है.

यहां दिए गए कोड स्निपेट में बताया गया है कि पासकी से जुड़े विकल्प दिखाने से पहले, यह कैसे पता लगाया जा सकता है कि वे काम करेंगे या नहीं.

if (window.PublicKeyCredential && PublicKeyCredential.getClientCapabilities) {
  const capabilities = await PublicKeyCredential.getClientCapabilities();
  if (capabilities.conditionalGet === true &&
      capabilities.passkeyPlatformAuthenticator === true) {
    // The browser supports passkeys and the conditional UI.
  }
}

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

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

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

इस कोड स्निपेट में, navigator.credentials.create() को कॉल करने के लिए ज़रूरी जानकारी वाला JSON ऑब्जेक्ट दिखाया गया है:

// Example `PublicKeyCredentialCreationOptions` contents
{
  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,
  }
}

ऑब्जेक्ट में मौजूद की-वैल्यू पेयर में यह जानकारी होती है:

• challenge: यह रजिस्ट्रेशन के लिए, सर्वर से जनरेट किया गया ArrayBuffer में मौजूद चैलेंज है.
• rp.id: आरपी आईडी (रिलाइंग पार्टी आईडी), डोमेन, और वेबसाइट, अपने डोमेन या रजिस्टर किए जा सकने वाले सफ़िक्स के बारे में बता सकती है. उदाहरण के लिए, अगर किसी आरपी का ऑरिजिन https://login.example.com:1337 है, तो आरपी आईडी login.example.com या example.com हो सकता है. अगर RP आईडी को example.com के तौर पर सेट किया गया है, तो उपयोगकर्ता login.example.com या example.com के किसी भी सबडोमेन पर पुष्टि कर सकता है. इस बारे में ज़्यादा जानने के लिए, मिलते-जुलते ऑरिजिन के अनुरोधों की मदद से, अपनी सभी साइटों पर पासकी का फिर से इस्तेमाल करने की अनुमति दें लेख पढ़ें.
• rp.name: आरपी (भरोसेमंद पार्टी) का नाम. WebAuthn L3 में इसे बंद कर दिया गया है. हालांकि, इसे इसलिए शामिल किया गया है, ताकि यह अन्य सिस्टम के साथ काम कर सके.
• user.id: खाता बनाने पर जनरेट किया गया ArrayBuffer में मौजूद यूनीक उपयोगकर्ता आईडी. यह हमेशा के लिए होना चाहिए. उपयोगकर्ता नाम की तरह, इसमें बदलाव नहीं किया जा सकता. User-ID से किसी खाते की पहचान होती है. हालांकि, इसमें व्यक्तिगत पहचान से जुड़ी कोई जानकारी (पीआईआई) शामिल नहीं होनी चाहिए. आपके सिस्टम में शायद पहले से ही कोई उपयोगकर्ता आईडी मौजूद हो. हालांकि, अगर ज़रूरत हो, तो पासकी के लिए एक नया उपयोगकर्ता आईडी बनाएं, ताकि इसमें कोई भी निजी पहचान से जुड़ी जानकारी न हो.
• user.name: यह खाते का यूनीक आइडेंटिफ़ायर होता है. उपयोगकर्ता इसे पहचान सकता है. जैसे, उसका ईमेल पता या उपयोगकर्ता नाम. यह खाता चुनने की सुविधा में दिखेगा.
• user.displayName: यह खाते का नाम है. इसे देना ज़रूरी है. यह नाम ऐसा होना चाहिए जिसे उपयोगकर्ता आसानी से समझ सकें. यह यूनीक होना ज़रूरी नहीं है. यह उपयोगकर्ता का चुना हुआ नाम हो सकता है. अगर आपकी साइट पर इस एट्रिब्यूट के लिए कोई सही वैल्यू मौजूद नहीं है, तो एक खाली स्ट्रिंग पास करें. यह जानकारी, ब्राउज़र के हिसाब से खाता चुनने वाले टूल पर दिख सकती है.
• pubKeyCredParams: इससे यह पता चलता है कि आरपी (भरोसेमंद पक्ष) के साथ काम करने वाले सार्वजनिक पासकोड से जुड़े एल्गोरिदम कौनसे हैं. हमारा सुझाव है कि इसे [{alg: -7, type: "public-key"},{alg: -257, type: "public-key"}] पर सेट करें. इससे P-256 के साथ ECDSA और RSA PKCS#1 के लिए सहायता मिलती है. साथ ही, इनकी मदद से पूरा कवरेज मिलता है.
• excludeCredentials: पहले से रजिस्टर किए गए क्रेडेंशियल आईडी की सूची. यह सुविधा, एक ही डिवाइस को दो बार रजिस्टर करने से रोकती है. इसके लिए, यह पहले से रजिस्टर किए गए क्रेडेंशियल आईडी की सूची उपलब्ध कराती है. अगर transports मेंबर दिया गया है, तो इसमें हर क्रेडेंशियल के रजिस्ट्रेशन के दौरान getTransports() को कॉल करने का नतीजा शामिल होना चाहिए.
• authenticatorSelection.authenticatorAttachment: अगर पासकी बनाने की यह सुविधा, पासवर्ड से अपग्रेड की गई है, तो इसे hint: ['client-device'] के साथ "platform" पर सेट करें. उदाहरण के लिए, साइन-इन करने के बाद प्रमोशन में. "platform" से पता चलता है कि आरपी को प्लैटफ़ॉर्म ऑथेंटिकेटर (प्लैटफ़ॉर्म डिवाइस में एम्बेड किया गया ऑथेंटिकेटर) चाहिए. यह ऑथेंटिकेटर, उदाहरण के लिए, यूएसबी सुरक्षा कुंजी डालने के लिए सूचना नहीं दिखाता है. उपयोगकर्ता के पास पासकी बनाने का आसान विकल्प होता है.
• authenticatorSelection.requireResidentKey: इसे बूलियन true पर सेट करें. खोजे जा सकने वाले क्रेडेंशियल (रेज़िडेंट की) पासकी में उपयोगकर्ता की जानकारी सेव करता है. साथ ही, पुष्टि होने पर उपयोगकर्ताओं को खाता चुनने की अनुमति देता है.

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

हमारा सुझाव है कि ऑब्जेक्ट को सर्वर पर बनाया जाए. साथ ही, ArrayBuffer को Base64URL के साथ कोड में बदला जाए और उसे फ़्रंटएंड से फ़ेच किया जाए. इस तरह, PublicKeyCredential.parseCreationOptionsFromJSON() का इस्तेमाल करके पेलोड को डिकोड किया जा सकता है. साथ ही, इसे सीधे navigator.credentials.create() को पास किया जा सकता है.

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

// Fetch an encoded `PubicKeyCredentialCreationOptions` from the server.
const _options = await fetch('/webauthn/registerRequest');

// Deserialize and decode the `PublicKeyCredentialCreationOptions`.
const decoded_options = JSON.parse(_options);
const options = PublicKeyCredential.parseCreationOptionsFromJSON(decoded_options);
...

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

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

// Invoke WebAuthn to create a passkey.
const credential = await navigator.credentials.create({
  publicKey: options
});

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

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

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

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

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

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

ऑब्जेक्ट को .toJSON() तरीके से एन्कोड करें, JSON.stringify() की मदद से उसे क्रम से लगाएं, और फिर उसे सर्वर पर भेजें.

...

// Encode and serialize the `PublicKeyCredential`.
const _result = credential.toJSON();
const result = JSON.stringify(_result);

// Encode and send the credential to the server for verification.  
const response = await fetch('/webauthn/registerResponse', {
  method: 'post',
  credentials: 'same-origin',
  body: result
});
...

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

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

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

यहां दी गई सूची में, सेव करने के लिए सुझाई गई प्रॉपर्टी शामिल हैं:

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

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

रजिस्ट्रेशन नहीं होने पर सूचना देना

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

इस तरह की स्थिति से बचने के लिए, Signal API का इस्तेमाल करके, पासकी की सेवा देने वाली कंपनी को किसी अनजान पासकी के बारे में सूचना दी जा सकती है. आरपी आईडी और क्रेडेंशियल आईडी के साथ PublicKeyCredential.signalUnknownCredential() को कॉल करके, आरपी पासकी प्रोवाइडर को यह सूचना दे सकता है कि बताया गया क्रेडेंशियल हटा दिया गया है या मौजूद नहीं है. पासकी की सुविधा देने वाली कंपनी यह तय करती है कि इस सिग्नल का इस्तेमाल कैसे किया जाए. हालांकि, अगर यह सुविधा उपलब्ध है, तो इससे जुड़ी पासकी को हटा दिया जाता है.

// Detect authentication failure due to lack of the credential
if (response.status === 404) {
  // Feature detection
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" // base64url encoded credential ID
    });
  } else {
    // Encourage the user to delete the passkey from the password manager nevertheless.
    ...
  }
}

Signal API के बारे में ज़्यादा जानने के लिए, Signal API की मदद से, अपने सर्वर पर क्रेडेंशियल के साथ पासकी को एक जैसा रखें लेख पढ़ें.

उपयोगकर्ता को सूचना भेजें

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

चेकलिस्ट

• उपयोगकर्ता को पासकी बनाने की अनुमति देने से पहले, उसकी पुष्टि करें. इसके लिए, ईमेल या किसी सुरक्षित तरीके का इस्तेमाल करें.
• excludeCredentials का इस्तेमाल करके, एक ही पासकी सेवा देने वाली कंपनी के लिए डुप्लीकेट पासकी बनाने से रोकें.
• इस कुकी का इस्तेमाल, पासकी प्रोवाइडर की पहचान करने और उपयोगकर्ता के क्रेडेंशियल का नाम रखने के लिए AAGUID को सेव करने के लिए किया जाता है.
• अगर PublicKeyCredential.signalUnknownCredential() के साथ पासकी रजिस्टर करने की कोशिश करने पर गड़बड़ी होती है, तो इसकी सूचना दें.
• उपयोगकर्ता के खाते के लिए पासकी बनाने और रजिस्टर करने के बाद, उसे सूचना भेजें.

संसाधन

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

अगला चरण: फ़ॉर्म में जानकारी अपने-आप भरने की सुविधा का इस्तेमाल करके, पासकी से साइन इन करना.