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

पासवर्ड की जगह पासकी जैसे 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 Level 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 का इस्तेमाल करके, आरपी ऐसे साइन-इन अनुभव दे सकते हैं जो:

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

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