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

Eiji Kitamura

Maud Nalpas

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

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

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

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

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

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

ध्यान दें: iCloud Keychain (macOS, iOS या iPadOS) का इस्तेमाल करके बनाए गए सभी WebAuthn क्रेडेंशियल, सिंक की गई पासकी होती हैं. आरपी, 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 'required' को true पर और 'discouraged' पर सेट किया जाता है. अगर requireResidentKey को 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 पैरामीटर में क्रेडेंशियल आईडी की सूची पास करनी होगी.

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

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

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

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