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

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 पर सेट करें. अगर ऐसा नहीं है, तो इसे false पर सेट करें.

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 के कॉम्बिनेशन की मदद से, आरपी को साइन-इन करने का ऐसा अनुभव मिल सकता है:

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

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