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

Eiji Kitamura

Maud Nalpas

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

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

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

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

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

ध्यान दें: Android के लिए Google Password Manager पर, खोजे जा सकने वाले क्रेडेंशियल सभी डिवाइसों पर सिंक किए जाते हैं. फ़िलहाल, अगर आरपी को डिवाइस से जुड़े क्रेडेंशियल बनाने हैं, तो वे साफ़ तौर पर ऐसे क्रेडेंशियल के लिए अनुरोध कर सकते हैं जिन्हें डिस्कवर नहीं किया जा सकता.

ध्यान दें: iCloud का इस्तेमाल करके बनाए गए सभी WebAuthn क्रेडेंशियल Keychain (macOS, iOS या iPadOS) सिंक की गई पासकी होती हैं. आरपी, iCloud Keychain की मदद से, ऐसे WebAuthn क्रेडेंशियल या डिवाइस से जुड़ी पासकी नहीं बना सकते जिन्हें खोजा नहीं जा सकता.

requireResidentKey और residentKey

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

ध्यान दें: पहले, खोजे जा सकने वाले क्रेडेंशियल को स्थानीय कुंजी कहा जाता था. इस लेगसी टर्म का इस्तेमाल अब भी WebAuthn API में किया जा रहा है.

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 पर सेट होने पर, 'discouraged' और requireResidentKey को false पर सेट किया गया है या यह मौजूद नहीं है, तो इसकी वैल्यू 'required' है.

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' बताएं. साथ ही, autocomplete="username webauthn" या autocomplete="password webauthn" के साथ password इनपुट फ़ील्ड के साथ एचटीएमएल username इनपुट फ़ील्ड के बारे में बताएं.

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 पैरामीटर में क्रेडेंशियल आईडी की सूची पास करनी होगी.

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

ध्यान दें: यह WebAuthn का इस्तेमाल पुराने तरीकों की सुरक्षा कुंजियों के लिए किया जाता है. साथ ही, यह ऐसे क्रेडेंशियल के लिए भी काम करेगा जिन्हें खोजा जा सकता है और जिनका पता नहीं लगाया जा सकता.

उपयोगकर्ता को यह अनुभव देने के लिए, साइन इन करने वाले उपयोगकर्ता के क्रेडेंशियल आईडी की सूची दें. आरपी के पास उनसे क्वेरी करने का विकल्प होना चाहिए, क्योंकि उपयोगकर्ता पहले से जाना-पहचाना है. 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 के कॉम्बिनेशन की मदद से, आरपी को साइन-इन करने का ऐसा अनुभव मिल सकता है:

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

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