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

एजी कितामुरा

हालांकि, पासकी जैसे 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 की मदद से, पुराने वर्शन के साथ काम करने के लिए बनाए रखा गया है. यह 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;
  
  // ...
}

पासकी फ़ॉर्म के अपने-आप भरने का विकल्प दिखाएं

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

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

यह उपयोगकर्ता अनुभव तब सबसे अच्छा रहता है, जब Google आरपी के माइग्रेशन के लिए, पासवर्ड और पासकी का अलग-अलग तरीके से इस्तेमाल किया जा रहा हो.

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

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

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