इस पेज का अनुवाद Cloud Translation API से किया गया है.

खोजे जा सकने वाले क्रेडेंशियल के बारे में पूरी जानकारी

Eiji Kitamura

Maud Nalpas

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

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

यह पक्का करने के लिए कि आपके क्रेडेंशियल, पासकी (ऐसे क्रेडेंशियल जिन्हें खोजा जा सकता है) के तौर पर बनाए गए हैं, क्रेडेंशियल बनाते समय residentKey और requireResidentKey डालें.

भरोसेमंद पक्ष (आरपी), पासकी की पुष्टि के दौरान allowCredentials को हटाकर, डिस्कवर किए जा सकने वाले क्रेडेंशियल का इस्तेमाल कर सकते हैं. इन मामलों में, ब्राउज़र या सिस्टम, उपयोगकर्ता को उपलब्ध पासकी की सूची दिखाता है. इन पासकी की पहचान, बनाने के समय सेट की गई user.name प्रॉपर्टी से की जाती है. अगर उपयोगकर्ता कोई एक विकल्प चुनता है, तो user.id वैल्यू को हस्ताक्षर में शामिल कर दिया जाएगा. इसके बाद, सर्वर उस आईडी या टाइप किए गए उपयोगकर्ता नाम के बजाय, खाता खोजने के लिए, क्रेडेंशियल आईडी का इस्तेमाल कर सकता है.

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

`requireResidentKey` और `residentKey`

पासकी बनाने के लिए, navigator.credentials.create() पर authenticatorSelection.residentKey और authenticatorSelection.requireResidentKey की वैल्यू डालें. वैल्यू इस तरह डालें जैसा कि यहां बताया गया है.

async function register () {
  // ...

  const publicKeyCredentialCreationOptions = {
    // ...
    authenticatorSelection: {
      authenticatorAttachment: 'platform',
      residentKey: 'required',
      requireResidentKey: true,
    }
  };

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

  // This does not run until the user selects a passkey.
  const credential = {};
  credential.id = cred.id;
  credential.rawId = cred.id; // Pass a Base64URL encoded ID string.
  credential.type = cred.type;

  // ...
}

residentKey:

'required': ऐसा क्रेडेंशियल बनाना ज़रूरी है जिसे सभी सदस्य देख सकें. अगर यह नहीं बन पाता है, तो NotSupportedError दिखाया जाता है.
'preferred': आरपी, सभी के लिए उपलब्ध क्रेडेंशियल बनाने का विकल्प चुनता है. हालांकि, वह ऐसा क्रेडेंशियल भी स्वीकार करता है जो सभी के लिए उपलब्ध नहीं होता.
'discouraged': आरपी, ऐसा क्रेडेंशियल बनाना चाहता है जिसे खोजा न जा सके. हालांकि, वह ऐसा क्रेडेंशियल भी स्वीकार करता है जिसे खोजा जा सकता है.

requireResidentKey:

इस प्रॉपर्टी को, WebAuthn लेवल 1 के साथ काम करने के लिए बनाए रखा गया है. यह स्पेसिफ़िकेशन का पुराना वर्शन है. अगर residentKey 'required' है, तो इसे true पर सेट करें. अगर residentKey 'required' नहीं है, तो इसे false पर सेट करें.

ध्यान दें: अगर residentKey के लिए कोई वैल्यू नहीं दी गई है, तो requireResidentKey को true पर सेट करने पर, असरदार वैल्यू 'required' होगी. अगर requireResidentKey को false पर सेट किया गया है या वैल्यू मौजूद नहीं है, तो असरदार वैल्यू 'discouraged' होगी.

`allowCredentials`

आरपी, पासकी की मदद से पुष्टि करने की सुविधा को कंट्रोल करने के लिए, navigator.credentials.get() पर allowCredentials का इस्तेमाल कर सकते हैं. आम तौर पर, पासकी की मदद से पुष्टि करने के तीन तरीके होते हैं:

खाता चुनने वाला मॉडल दिखाना
पासकी फ़ॉर्म को ऑटोमैटिक भरने की सुविधा दिखाना
फिर से पुष्टि करना

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

उपयोगकर्ता को यह अनुभव देने के लिए, navigator.credentials.get() में allowCredentials पैरामीटर को खाली छोड़ें या कोई खाली कलेक्शन पास करें.

async function authenticate() {
  // ...

  const publicKeyCredentialRequestOptions = {
    // Server generated challenge:
    challenge: ****,
    // The same RP ID as used during registration:
    rpId: 'example.com',
    // You can omit `allowCredentials` as well:
    allowCredentials: []
  };

  const credential = await navigator.credentials.get({
    publicKey: publicKeyCredentialRequestOptions,
    signal: abortController.signal
  });

  // This does not run until the user selects a passkey.
  const credential = {};
  credential.id = cred.id;
  credential.rawId = cred.id; // Pass a Base64URL encoded ID string.
  credential.type = cred.type;
  
  // ...
}

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

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

इसके बजाय, पासकी को चुनने की सुविधा को, सेव किए गए उपयोगकर्ता नाम और पासवर्ड के साथ, साइन इन करने के लिए इस्तेमाल होने वाले फ़ॉर्म में, फ़ील्ड के लिए ऑटोमैटिक भरने के प्रॉम्प्ट में जोड़ा जा सकता है. इस तरह, पासकी का इस्तेमाल करने वाला उपयोगकर्ता, अपनी पासकी चुनकर साइन इन फ़ॉर्म को "भर सकता" है. सेव किए गए उपयोगकर्ता नाम/पासवर्ड का इस्तेमाल करने वाले उपयोगकर्ता, उन्हें चुन सकते हैं. जिनके पास इनमें से कोई भी नहीं है वे अब भी अपना उपयोगकर्ता नाम और पासवर्ड टाइप कर सकते हैं.

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

उपयोगकर्ता को यह अनुभव देने के लिए, allowCredentials प्रॉपर्टी में खाली कलेक्शन पास करें या पैरामीटर को हटाएं. इसके अलावा, navigator.credentials.get() पर mediation: 'conditional' डालें और एचटीएमएल username इनपुट फ़ील्ड पर autocomplete="username webauthn" या password इनपुट फ़ील्ड पर autocomplete="password webauthn" एनोटेट करें.

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

async function authenticate() {
  // ...

  const publicKeyCredentialRequestOptions = {
    // Server generated challenge:
    challenge: ****,
    // The same RP ID as used during registration:
    rpId: 'example.com',
    // You can omit `allowCredentials` as well:
    allowCredentials: []
  };

  const cred = await navigator.credentials.get({
    publicKey: publicKeyCredentialRequestOptions,
    signal: abortController.signal,
    // Specify 'conditional' to activate conditional UI
    mediation: 'conditional'
  });

  // This does not run until the user selects a passkey.
  const credential = {};
  credential.id = cred.id;
  credential.rawId = cred.id; // Pass a Base64URL encoded ID string.
  credential.type = cred.type;
  
  // ...
}

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

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

फिर से पुष्टि करना

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

ऐसे में, अगर नाम वाले क्रेडेंशियल में से कोई भी क्रेडेंशियल डिवाइस में सेव है, तो उपयोगकर्ता को तुरंत डिवाइस अनलॉक करने के लिए कहा जाएगा. अगर ऐसा नहीं है, तो उपयोगकर्ता को कोई दूसरा डिवाइस (फ़ोन या सुरक्षा कुंजी) दिखाने के लिए कहा जाता है, जिसमें मान्य क्रेडेंशियल मौजूद हों.

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

async function authenticate() {
  // ...

  const publicKeyCredentialRequestOptions = {
    // Server generated challenge:
    challenge: ****,
    // The same RP ID as used during registration:
    rpId: 'example.com',
    // Provide a list of PublicKeyCredentialDescriptors:
    allowCredentials: [{
      id: ****,
      type: 'public-key',
      transports: [
        'internal',
        'hybrid'
      ]
    }, {
      id: ****,
      type: 'public-key',
      transports: [
        'internal',
        'hybrid'
      ]
    }, ...]
  };

  const credential = await navigator.credentials.get({
    publicKey: publicKeyCredentialRequestOptions,
    signal: abortController.signal
  });

  // This does not run until the user selects a passkey.
  const credential = {};
  credential.id = cred.id;
  credential.rawId = cred.id; // Pass a Base64URL encoded ID string.
  credential.type = cred.type;
  
  // ...
}

PublicKeyCredentialDescriptor ऑब्जेक्ट में ये चीज़ें शामिल होती हैं:

id: सार्वजनिक पासकोड क्रेडेंशियल का आईडी, जो आरपी को पासकोड रजिस्ट्रेशन पर मिला है.
type: आम तौर पर, यह फ़ील्ड 'public-key' होता है.
transports: इस क्रेडेंशियल को होस्ट करने वाले डिवाइस पर काम करने वाले ट्रांसपोर्ट के बारे में जानकारी. ब्राउज़र इस जानकारी का इस्तेमाल, यूज़र इंटरफ़ेस (यूआई) को ऑप्टिमाइज़ करने के लिए करते हैं. यह यूआई, उपयोगकर्ता से कोई बाहरी डिवाइस दिखाने के लिए कहता है. अगर यह सूची दी गई है, तो इसमें हर क्रेडेंशियल के रजिस्ट्रेशन के दौरान getTransports() को कॉल करने का नतीजा शामिल होना चाहिए.

खास जानकारी

डिस्कवर किए जा सकने वाले क्रेडेंशियल की मदद से, पासकी से साइन इन करने का अनुभव ज़्यादा आसान हो जाता है. ऐसा इसलिए होता है, क्योंकि उपयोगकर्ता को उपयोगकर्ता नाम डालने की ज़रूरत नहीं पड़ती. residentKey, requireResidentKey, और allowCredentials के कॉम्बिनेशन की मदद से, आरपी को साइन-इन करने का ऐसा अनुभव मिल सकता है:

खाता चुनने वाला मॉडल दिखाएं.
पासकी फ़ॉर्म में ऑटोमैटिक भरने की सुविधा दिखाएं.
फिर से पुष्टि करना.

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