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

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=&qu>ot;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 को मिलाकर, आरपी साइन-इन करने के ऐसे अनुभव दे सकते हैं जो:

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

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