इस पेज का अनुवाद Cloud Translation API से किया गया है.

Signal API की मदद से, अपने सर्वर पर क्रेडेंशियल के साथ पासकी को एक जैसा रखना

Eiji Kitamura

पब्लिश करने की तारीख: 12 नवंबर, 2024, पिछली बार अपडेट करने की तारीख: 29 नवंबर, 2024

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

इनके साथ काम करता है

Chrome, सभी डेस्कटॉप प्लैटफ़ॉर्म और Android पर Signal API के साथ काम करता है.

Safari के साथ काम करता है, लेकिन अभी लागू नहीं किया गया है. Firefox ने अब तक अपनी राय शेयर नहीं की है.

Google Password Manager, सिग्नल के हिसाब से पासकी को अपडेट कर सकता है. डेस्कटॉप पर, Chrome एक्सटेंशन के ज़रिए पासकी की सुविधा देने वाली कंपनियां यह तय करती हैं कि सिग्नल को दिखाना है या नहीं.

बैकग्राउंड

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

हालांकि, कुछ मामलों में पासकी उपलब्ध कराने वाली कंपनी की पासकी की सूची और सर्वर की क्रेडेंशियल सूची के बीच अंतर होने से भ्रम पैदा हो सकता है.

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

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

Signal API

Signal API, WebAuthn API है. यह पासकी की सुविधा देने वाली कंपनियों को बदलावों के बारे में सूचना देकर, इन गड़बड़ियों को ठीक करता है. इसके तीन तरीके हैं:

PublicKeyCredential.signalUnknownCredential: यह सिग्नल देता है कि क्रेडेंशियल मौजूद नहीं है
PublicKeyCredential.signalAllAcceptedCredentials: सेव किए गए क्रेडेंशियल की सूची का सिग्नल
PublicKeyCredential.signalCurrentUserDetails: Signal ने उपयोगकर्ता नाम और डिसप्ले नेम अपडेट किया है

यह सिग्नल देता है कि क्रेडेंशियल मौजूद नहीं है

const credential = await navigator.credentials.get({ ... });
const payload = credential.toJSON();

const result = await fetch('/login', { ... });

// Detect authentication failure due to lack of the credential
if (result.status === 404) {
  // Feature detection
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" // base64url encoded credential ID
    });
  } else {
    // Encourage the user to delete the passkey from the password manager nevertheless.
    ...
  }
}

आरपी आईडी और क्रेडेंशियल आईडी के साथ PublicKeyCredential.signalUnknownCredential() को कॉल करके, आरपी पासकी प्रोवाइडर को यह सूचना दे सकता है कि बताया गया क्रेडेंशियल हटा दिया गया है या मौजूद नहीं है. पासकी की सुविधा देने वाली कंपनी यह तय करती है कि इस सिग्नल को कैसे हैंडल किया जाए. हालांकि, इससे जुड़ी पासकी को हटा दिया जाना चाहिए, ताकि लोग ऐसी पासकी से साइन इन करने की कोशिश न करें जिससे जुड़ा क्रेडेंशियल मौजूद नहीं है.

Browser Support

Source

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

Chrome पर Google Password Manager से पासकी मिटाने पर दिखने वाला डायलॉग.

सेव किए गए क्रेडेंशियल की सूची का सिग्नल देना

// After a user deletes a passkey or a user is signed in.

// Feature detection
if (PublicKeyCredential.signalAllAcceptedCredentials) {
  await PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "M2YPl-KGnA8", // base64url encoded user ID
    allAcceptedCredentialIds: [ // A list of base64url encoded credential IDs
      "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA",
      ...
    ]
  });
}

उपयोगकर्ता के साइन इन करने या खाता सेटिंग मैनेज करने के बाद, PublicKeyCredential.signalAllAcceptedCredentials() का इस्तेमाल करें. उस उपयोगकर्ता के लिए, सभी मान्य क्रेडेंशियल आईडी की सूची दें. पासकी की सुविधा देने वाली कंपनी, इस सूची की तुलना उस भरोसेमंद पार्टी के लोकल स्टोरेज से करती है. पासकी की सुविधा देने वाली कंपनी, अपने स्टोरेज में मौजूद ऐसी पासकी को "छिपा हुआ" के तौर पर मार्क करती है जो allAcceptedCredentialIds सूची में शामिल नहीं है. सिस्टम, साइन-इन करने या अपने-आप भरने की सुविधा के लिए, छिपी हुई इन पासकी का सुझाव नहीं देता. हालांकि, इन्हें तुरंत हमेशा के लिए नहीं मिटाया जाता. इससे, ज़रूरत पड़ने पर इन्हें वापस लाया जा सकता है. इसके उलट, पासकी की सुविधा देने वाली कंपनी, allAcceptedCredentialIds में मौजूद उन पासकी को वापस लाती है जिन्हें "छिपाया गया" के तौर पर मार्क किया गया है. इससे आपकी वेबसाइट, गलती से छिपाई गई पासकी को वापस ला सकती है.

Browser Support

Source

इस एपीआई को तब कॉल करें, जब कोई उपयोगकर्ता आरपी पर पासकी मिटाता है और हर साइन-इन पर. इससे पासकी की सेवा देने वाली कंपनी, पासकी की सिंक्रनाइज़ की गई सूची को बनाए रख सकती है.

चेतावनी: इसे लागू करते समय सावधानी बरतें, क्योंकि मान्य पासकी शामिल न करने पर, लोग उनसे साइन इन नहीं कर पाएंगे. उदाहरण के लिए, खाली सूची पास करने पर, उपयोगकर्ता की सभी पासकी छिप सकती हैं. क्रेडेंशियल की सुविधा देने वाली कुछ कंपनियां, signalAllAcceptedCredentials को बाद में किए गए कॉल पर पासकी वापस लाने की सुविधा देती हैं. इसके लिए, वे पहले हटाए गए क्रेडेंशियल आईडी का इस्तेमाल करती हैं. पासकी छिपाने और उन्हें वापस लाने के बारे में जानने के लिए, यह जानकारी पढ़ें.

सिग्नल ने उपयोगकर्ता नाम और डिसप्ले नेम अपडेट किया

// After a user updated their username and/or display name
// or a user is signed in.

// Feature detection
if (PublicKeyCredential.signalCurrentUserDetails) {
  await PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "M2YPl-KGnA8", // base64url encoded user ID
    name: "a.new.email.address@example.com", // username
    displayName: "J. Doe"
  });
} else {
}

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

Browser Support

Source

इस एपीआई को उपयोगकर्ता के उपयोगकर्ता नाम या डिसप्ले नेम के अपडेट होने पर और हर बार साइन इन करने पर शुरू किया जा सकता है. इससे पासकी की सुविधा देने वाली कंपनी, इस जानकारी को सर्वर के साथ सिंक कर सकती है.

Chrome पर Google Password Manager में पासकी का मेटाडेटा अपडेट होने पर दिखने वाला डायलॉग.

खास जानकारी

Signal API की मदद से, पासकी का बेहतर अनुभव दिया जा सकता है. इससे साइन इन करने में आने वाली अनचाही समस्याओं को दूर किया जा सकता है. Signal API की मदद से, भरोसा करने वाली पार्टियां मौजूदा क्रेडेंशियल और उनके मेटाडेटा की सूची को सिग्नल कर सकती हैं. इससे वे पासकी सेवा देने वाली कंपनी के साथ पासकी को सिंक कर सकती हैं.

पासकी के बारे में ज़्यादा जानने के लिए, पासकी की मदद से बिना पासवर्ड के लॉगिन करना लेख पढ़ें.