उपयोगकर्ताओं को पासवर्ड से पासकी पर माइग्रेट करने के दौरान, संगठनों और डेवलपर को काफ़ी मुश्किलों का सामना करना पड़ता है. पासकी से सुरक्षा को बेहतर बनाया जा सकता है. हालांकि, पासकी को मैन्युअल तरीके से बनाने में अक्सर परेशानी होती है. ई-कॉमर्स के ऐसे प्लैटफ़ॉर्म जहां बहुत ज़्यादा ट्रांज़ैक्शन होते हैं वहां हर सेकंड अहम होता है. ऐसा इसलिए, क्योंकि किसी भी तरह की देरी से खरीदारी का प्रोसेस रुक सकता है और लोग कार्ट में सामान छोड़कर जा सकते हैं. इसके अलावा, सर्वर और उपयोगकर्ता के डिवाइस के बीच क्रेडेंशियल की स्थितियों को सिंक रखना ज़रूरी है. इससे साइन-इन करने में आने वाली गड़बड़ियों और उपयोगकर्ता की निराशा को रोका जा सकता है.
adidas को भी इन्हीं चुनौतियों का सामना करना पड़ा. उनका मुख्य मकसद, साइन-इन करने की प्रोसेस को आसान बनाना था. साथ ही, वेब और ऐप्लिकेशन प्लैटफ़ॉर्म के साथ-साथ डिवाइसों पर उपयोगकर्ता अनुभव को बेहतर बनाना था. सुरक्षा को प्राथमिकता देते हुए, प्रॉडक्ट टीम ने पासकी की मदद से साइन-अप और साइन-इन करने की प्रोसेस को आसान बनाने पर फ़ोकस किया है.
इन चुनौतियों से निपटने के लिए, adidas ने Conditional Create को लागू किया. इससे पासवर्ड का इस्तेमाल करने वाले उपयोगकर्ताओं को पासकी पर अपने-आप अपग्रेड किया जा सकेगा. साथ ही, क्रेडेंशियल को एक जैसा रखने के लिए Signal API को लागू किया. इसके अलावा, उन्होंने एक ही मूल सर्वर से किए गए अनुरोधों को लागू किया, ताकि ज़रूरत पड़ने पर, अलग-अलग डोमेन पर इनका इस्तेमाल किया जा सके.
नतीजे
पासकी बनाने की प्रोसेस को अपने-आप होने वाली प्रोसेस में बदलने और क्रेडेंशियल की सुरक्षा को बनाए रखने की adidas की रणनीति से, पासकी को अपनाने और साइन-इन करने की प्रोसेस को भरोसेमंद बनाने के मामले में, तुरंत और मेज़र किए जा सकने वाले नतीजे मिले:
- पासकी का इस्तेमाल करने वालों की संख्या में बढ़ोतरी: पासकी से साइन इन करने की प्रोसेस लॉन्च करने के बाद, adidas ने पासकी बनाने की दर में 47% की बढ़ोतरी हासिल की है. इसमें, अपने-आप चालू होने वाली 'शर्त के साथ खाता बनाएं' सुविधा और साइन-अप या साइन-इन फ़्लो के दौरान प्रॉम्प्ट मिलने पर, उपयोगकर्ता की ओर से ऑप्ट-इन किए गए विकल्प, दोनों शामिल हैं. मोबाइल डिवाइसों पर इस सुविधा को अपनाने की दर सबसे ज़्यादा थी. यहां कन्वर्ज़न रेट 52% था, जबकि डेस्कटॉप पर यह 34% था.
- शर्त के आधार पर खाता बनाने की सुविधा का इस्तेमाल करके, अपग्रेड की प्रोसेस को तेज़ करना: adidas ने साफ़ तौर पर दिए गए प्रॉम्प्ट के अलावा, पासकी बनाने की सुविधा को आसानी से अपग्रेड करके, पासकी बनाने की संख्या में 8% की बढ़ोतरी हासिल की. ऐसा, पासवर्ड का इस्तेमाल करने वाले मौजूदा उपयोगकर्ताओं के लिए बैकग्राउंड में किया गया. इसके लिए, उपयोगकर्ता को मैन्युअल तरीके से कोई कार्रवाई करने की ज़रूरत नहीं पड़ी.
- साइन इन करने की सुविधा लगभग पूरी तरह से भरोसेमंद है: साइन इन करने की प्रोसेस शुरू होने के बाद, पासकी से 99% से ज़्यादा बार साइन इन किया जा सका. यह सुरक्षा के मामले में एक बड़ा अपग्रेड है. adidas के लिए, पासवर्ड का इस्तेमाल करके लॉग इन करने की दर पहले 70% थी. हालांकि, टाइपिंग में हुई गड़बड़ियों या क्रेडेंशियल भूल जाने जैसी मानवीय भूलों की वजह से, यह दर अक्सर कम हो जाती थी.
- कम से कम रुकावटें और गड़बड़ियां: डिवाइस और सर्वर क्रेडेंशियल को अपने-आप सिंक करने के लिए, adidas ने Signal API को डिप्लॉय किया. इससे, साइन इन करने की कोशिशों में
PASSKEY_NOT_FOUNDगड़बड़ियों की संख्या को 0.3% से कम रखने में मदद मिली. इससे, अनाथ पासकी की वजह से उपयोगकर्ताओं को होने वाली परेशानी को काफ़ी हद तक कम किया जा सका.
47 %
पासकी बनाने की दर
8 %
शर्त के साथ पासकी बनाने की सुविधा का इस्तेमाल करके, पासकी बनाने की संख्या में बढ़ोतरी
>99 %
पासकी से साइन-इन करने की प्रोसेस शुरू होने के बाद, उसके पूरा होने की दर
<0.3 %
अनाथ पासकी की गड़बड़ी की दर
adidas ने इस समस्या को कैसे हल किया
यहां बताया गया है कि adidas ने इन चुनौतियों का सामना कैसे किया:
1. कंडिशनल क्रिएट की मदद से, आसानी से नई टेक्नोलॉजी का इस्तेमाल करना
उपयोगकर्ताओं को पासकी का इस्तेमाल करने में आसानी हो, इसके लिए adidas ने शर्त के साथ पासकी बनाने की सुविधा लागू की है. इस सुविधा की मदद से, कोई वेबसाइट अपने-आप पासकी बना सकती है. ऐसा तब होता है, जब कोई उपयोगकर्ता अपने पासवर्ड मैनेजर में सेव किए गए पासवर्ड से साइन इन करता है. ज़्यादा से ज़्यादा लोगों को साइन इन करने में मदद करने के लिए, सिस्टम साइन इन करने के तुरंत बाद एपीआई को कॉल करता है. इससे सिस्टम को पता चलता है कि पासवर्ड का इस्तेमाल हाल ही में किया गया है.
const cred = await navigator.credentials.create({
publicKey: options,
mediation: 'conditional' // Enables automatic passkey creation
});
adidas ने इस सुविधा को कस्टम लॉजिक के साथ इंटिग्रेट किया है. यह लॉजिक, सबसे पहले उपयोगकर्ता के एनवायरमेंट की पुष्टि करता है. खास तौर पर, सिस्टम यह देखता है कि ब्राउज़र में कंडीशनल क्रिएट की सुविधा काम करती है या नहीं. सिस्टम, उपयोगकर्ता की प्राथमिकताओं का भी ध्यान रखता है. अगर उपयोगकर्ता ने पिछले छह महीनों में तीन बार पासकी बनाने का प्रॉम्प्ट पहले ही स्किप कर दिया है, तो सिस्टम उस प्रॉम्प्ट को नहीं दिखाएगा.
अगर एनवायरमेंट पासकी बनाने के लिए सही है, तो सिस्टम उपयोगकर्ता की पुष्टि होने के तुरंत बाद, बैकग्राउंड में पासकी बनाने की कोशिश करता है. इस समय पर ऐसा करने से, ज़रूरी शर्तें पूरी होने की संभावना बढ़ जाती है. खास तौर पर, यह लागू करने का तरीका, WebAuthn से जुड़ी समस्याओं को "fail-open" सिद्धांत के साथ हल करता है, ताकि उपयोगकर्ता के ऐक्सेस को हमेशा प्राथमिकता दी जा सके. अगर ब्राउज़र InvalidStateError की जानकारी देता है, तो इसका मतलब है कि पासकी पहले से मौजूद है. ऐसे में, सिस्टम बैकग्राउंड में पासकी बनाने की प्रोसेस को रोक देता है और उपयोगकर्ता को तुरंत साइन इन कर देता है. इसके उलट, अगर NotAllowedError होता है, तो इसका मतलब है कि पासकी अपने-आप बनने की खास शर्तें पूरी नहीं हुई हैं. ऐसे में, सिस्टम इस स्थिति का पता लगाता है और उपयोगकर्ता को "पासकी कलेक्टर" स्क्रीन पर ले जाता है, ताकि उसे मैन्युअल तरीके से सेटअप करने की प्रोसेस के बारे में बताया जा सके. adidas, तकनीकी सीमाओं और उपयोगकर्ता के व्यवहार के बीच अंतर करके यह पक्का करता है कि पासकी अपग्रेड करने से साइन-इन करने का अनुभव बेहतर हो, न कि उसमें रुकावट आए.
2. Signal API की मदद से, भरोसेमंद तरीके से काम करना
उपयोगकर्ता अलग-अलग डिवाइसों पर अपने क्रेडेंशियल मैनेज करते हैं. इसलिए, उनमें अंतर हो सकता है. उदाहरण के लिए, हो सकता है कि पासकी को सर्वर से मिटा दिया गया हो, लेकिन वह उपयोगकर्ता के डिवाइस पर मौजूद हो. इन "फ़ैंटम" क्रेडेंशियल की वजह से साइन इन करने में होने वाली समस्याओं को रोकने के लिए, adidas ने Signal API लागू किया. इस एपीआई की मदद से, सर्वर पासकी देने वाली कंपनी को क्रेडेंशियल की स्थिति के बारे में सूचना दे सकता है.
adidas, इस एकरूपता को बनाए रखने के लिए, Signal API के उपलब्ध सभी तीन तरीकों का इस्तेमाल करता है. adidas, यह अनुमान लगाने के बजाय कि कौनसे क्रेडेंशियल हटाने हैं, उपयोगकर्ता के लाइफ़साइकल के खास इवेंट को सही एपीआई कॉल पर मैप करता है:
- रजिस्ट्रेशन पूरा न होने पर: जब क्लाइंट पर पासकी बनाई जाती है, लेकिन बैकएंड पर रजिस्टर नहीं हो पाती है, तो adidas,
signalUnknownCredentialका इस्तेमाल करके तुरंत अनाथ क्रेडेंशियल को हटा देता है. - अमान्य साइन-इन: अगर कोई उपयोगकर्ता रद्द की गई या पुरानी पासकी से साइन इन करने की कोशिश करता है, तो
signalUnknownCredential, सेवा देने वाली कंपनी को इसे छिपाने का सिग्नल भेजता है. - उपयोगकर्ता का मैनेजमेंट: जब कोई उपयोगकर्ता अपने खाते की सेटिंग में जाकर, पासकी को साफ़ तौर पर हटाता है, तो
signalAllAcceptedCredentialsअनुमति वाली सूची को सिंक करता है. इससे यह पक्का होता है कि मिटाई गई पासकी का इस्तेमाल करने का विकल्प अब नहीं दिखेगा. - खाते से जुड़े अपडेट: जब कोई उपयोगकर्ता अपना ईमेल पता या उपयोगकर्ता नाम बदलता है, तो
signalCurrentUserDetailsडिवाइस पर मौजूद मेटाडेटा को अपडेट करता है, ताकि वह सर्वर से मेल खाए.
// Detect authentication failure due to lack of the credential
if (result.status === 404) {
if (PublicKeyCredential.signalUnknownCredential) {
await PublicKeyCredential.signalUnknownCredential({
rpId: "adidas.com",
credentialId: "..." // base64url encoded credential ID
});
}
}
3. मिलते-जुलते ऑरिजिन के अनुरोधों और डिजिटल ऐसेट लिंक की मदद से, ऐक्सेस को एक जैसा बनाएं
adidas ने एक से ज़्यादा मार्केट के आर्किटेक्चर को बेहतर बनाने के लिए, Related Origin Requests लागू किए. ज़्यादातर उपयोगकर्ता अपनी स्थानीय मार्केट (उदाहरण के लिए, adidas.nl) पर ही बने रहते हैं. हालांकि, इस कॉन्फ़िगरेशन की मदद से, अलग-अलग देशों/इलाकों के बीच स्विच करने वाले उपयोगकर्ता, अनुमति वाले डोमेन पर पासकी का फिर से इस्तेमाल कर सकते हैं. इसके लिए, उन्हें एक रिलाइंग पार्टी आईडी (adidas.com) को टारगेट करना होगा.
इसे चालू करने के लिए, adidas अपने मुख्य Relying Party ID (RP ID) डोमेन पर webauthn कॉन्फ़िगरेशन फ़ाइल होस्ट करता है. इस फ़ाइल में, उन ऑरिजिन की अनुमति वाली सूची होती है जिन्हें पासकी रजिस्टर करने और पुष्टि करने के लिए, adidas.com का इस्तेमाल करने की अनुमति है. इन संबंधों को तय करके, ब्राउज़र यह पुष्टि कर सकता है कि किसी एक देश/इलाके की साइट पर बनाई गई पासकी, दूसरे देश/इलाके की साइट पर इस्तेमाल की जा सकती है. इससे दुनिया भर के उपयोगकर्ताओं को बिना किसी रुकावट के पासकी इस्तेमाल करने का अनुभव मिलता है.
// https://www.adidas.com/.well-known/webauthn
{
"origins": [
"https://www.adidas.fi",
"https://www.adidas.nl",
// ... abridged (the full file lists 50+ regional domains)
]
}
अहम बात यह है कि adidas ने डिजिटल ऐसेट लिंक का इस्तेमाल करके, अपने Android मोबाइल ऐप्लिकेशन में पासकी की सुविधा को आसानी से उपलब्ध कराया है. ऐप्लिकेशन, पुष्टि करने के लिए idp.adidas.com पर होस्ट किए गए वेबव्यू का इस्तेमाल करते हैं. इसलिए, Android ऐप्लिकेशन और Relying Party ID (adidas.com) के बीच भरोसेमंद संबंध बनाने के लिए, डिजिटल ऐसेट लिंक ज़रूरी थे. इस पुष्टि से ऐप्लिकेशन को, वेब पर इस्तेमाल की गई पासकी को ऐक्सेस करने की अनुमति मिलती है. इससे, अलग-अलग प्लैटफ़ॉर्म पर एक जैसा और आसान साइन-इन अनुभव मिलता है.
इसके लिए, adidas अपने वेब डोमेन पर डिजिटल ऐसेट लिंक (assetlinks.json) फ़ाइल होस्ट करता है. यह फ़ाइल, Android ऐप्लिकेशन के साथ क्रिप्टोग्राफ़िक असोसिएशन के बारे में सार्वजनिक तौर पर जानकारी देती है. इसी तरह, adidas अपने iOS इकोसिस्टम के लिए एसोसिएटेड डोमेन का इस्तेमाल करता है.
apple-app-site-association फ़ाइल को होस्ट करके, वे एक सुरक्षित कनेक्शन बनाते हैं. इससे उनका iOS ऐप्लिकेशन, वेब व्यू में पासकी का सुरक्षित तरीके से इस्तेमाल कर पाता है.
// https://www.adidas.fi/.well-known/assetlinks.json
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.adidas.app",
"sha256_cert_fingerprints": [
"B2:55:43:78:89:F6:F6:FD:BB:16:5C:43:EE:66:14:18:D4:E8:33:6D:3A:1F:68:86:C3:A8:7C:89:2B:51:45:96",
"..."
]
}
},
// ... abridged
]
adidas के लिए आगे क्या है?
adidas.fi और adidas.nl पर, क्रेडेंशियल को अपने-आप अपग्रेड होने और सिंक होने की सुविधा उपलब्ध है. adidas, इस सुविधा को अप्रैल 2026 के आखिर तक दुनिया के अन्य सभी देशों में लॉन्च कर देगा. इसके अलावा, adidas बिना किसी रुकावट के साइन-इन करने की सुविधा को और बेहतर बनाने के लिए, इमीडिएट मीडिएशन ओरिजिन ट्रायल को टेस्ट कर रहा है. आने वाले समय में, उपयोगकर्ताओं को सीधे तौर पर पासकी से खाते बनाने की सुविधा दी जाएगी. इससे, किसी दूसरे तरीके से साइन अप करने की मौजूदा ज़रूरी शर्त हट जाती है. टीम "स्मार्ट ट्रिगरिंग" की भी जांच कर रही है, ताकि साइन-इन करने के दूसरे चरण में सिस्टम पासकी डायलॉग को सीधे तौर पर चालू किया जा सके. इससे, जब यह पक्का हो जाता है कि उपयोगकर्ता के पास मौजूदा डिवाइस पर पासकी उपलब्ध है, तो उसे एक और क्लिक करने की ज़रूरत नहीं पड़ती.
यह जानकारी आपके लिए क्यों ज़रूरी है
पासवर्ड के बिना पुष्टि करने की सुविधा को तब सफलतापूर्वक लागू किया जा सकता है, जब उपयोगकर्ता अनुभव बेहतर बना रहे. शर्त के हिसाब से खाता बनाने की सुविधा लागू करके, उपयोगकर्ताओं को बिना किसी रुकावट के पासवर्ड से दूर किया जा सकता है. 'मिलते-जुलते ऑरिजिन के अनुरोध' सुविधा का इस्तेमाल करके, अपने सभी डोमेन पर पासकी शेयर की जा सकती हैं. इससे उपयोगकर्ता, एक ही पासकी से आपके पूरे नेटवर्क को आसानी से ऐक्सेस कर पाते हैं. आखिर में, इसे Signal API के साथ पेयर करने से यह पक्का होता है कि बिना पासवर्ड के लॉगिन करने की सुविधा, भरोसेमंद और बिना किसी गड़बड़ी के काम करती रहे.