यह पेज अपने-आप अनुवादित किया गया है। मूल अंग्रेज़ी संस्करण पढ़ें यहाँ.

Passkeys चीटशीट. passkey कार्यक्रमों के लिए व्यावहारिक मार्गदर्शन, रोलआउट पैटर्न और KPIs।
पासकी का इस्तेमाल करते समय या पासकी इम्प्लीमेंटेशन के क्षेत्र में काम करते समय, एक कॉम्पोनेंट काफ़ी महत्वपूर्ण हो जाता है: पासकी प्रोवाइडर। हालांकि, पासकी इकोसिस्टम में एक महत्वपूर्ण हिस्सा होने के बावजूद, कई लोगों को पासकी प्रोवाइडर की केवल थोड़ी-बहुत ही समझ होती है या वे फ़र्स्ट-पार्टी पासकी प्रोवाइडर, थर्ड-पार्टी पासकी प्रोवाइडर और पासकी ऑथेंटिकेशन प्रोवाइडर के बीच का अंतर नहीं जानते हैं।
15 मिनट में मुफ्त passkey assessment पाएं.
इस ब्लॉग पोस्ट का उद्देश्य इस विषय पर रोशनी डालना है। चाहे आप सॉफ़्टवेयर डेवलपर हों, प्रोडक्ट मैनेजर हों, या वेब सिक्योरिटी की नई जानकारी जानने के लिए बस उत्सुक हों, पासकी प्रोवाइडर की भूमिका और प्रकारों को समझना ज़रूरी है। इस विषय को आसान बनाकर, हम लोगों को उस जानकारी से सशक्त बनाने का प्रयास करते हैं जिससे वे आत्मविश्वास के साथ पासकी को समझ सकें।
पासकी प्रोवाइडर पासकी-आधारित ऑथेंटिकेशन के इकोसिस्टम में एक बुनियादी भूमिका निभाता है, जो यूज़र्स के डिवाइस और रिलाइंग पार्टी (ऑनलाइन सर्विसेज़) तक सुरक्षित, आसान एक्सेस के बीच एक पुल के रूप में काम करता है। लेकिन पासकी प्रोवाइडर असल में क्या है, ख़ासकर जब इसकी कोई आधिकारिक परिभाषा नहीं है और आपको ऑनलाइन अलग-अलग तरह की व्याख्याएं मिलेंगी?
नीचे दी गई परिभाषा हमारी समझ को दर्शाती है और इसका दावा नहीं किया गया है कि यह एकमात्र सटीक परिभाषा है।
पासकी प्रोवाइडर असल में कोई भी ऐसी इकाई है जो पासकी बनाने, मैनेज करने और इस्तेमाल करने की सुविधा देती है। हमारी रिसर्च के ज़रिए, हमने दो मुख्य श्रेणियों की पहचान की है जिनके तहत पासकी प्रोवाइडर को बांटा जा सकता है: फ़र्स्ट- / थर्ड-पार्टी पासकी प्रोवाइडर और पासकी ऑथेंटिकेशन प्रोवाइडर।
इस श्रेणी में वे इकाइयां शामिल हैं जो क्लाइंट साइड (यूज़र के डिवाइस पर) पासकी जनरेट करने में सक्षम हैं। जब इन प्लेटफ़ॉर्म के ज़रिए कोई पासकी बनाई जाती है, तो उसे सुरक्षित रूप से मैनेज और स्टोर किया जाता है, अक्सर किसी ऑपरेटिंग सिस्टम निर्माता (जैसे, iCloud Keychain, Google Password Manager) के क्लाउड में या किसी थर्ड-पार्टी पासवर्ड मैनेजर (जैसे, KeePassXC, 1Password, Dashlane – नीचे और देखें) में।
ऑपरेटिंग सिस्टम जो नेटिव तौर पर पासकी बनाने और मैनेज करने की सुविधा देते हैं, उन्हें फ़र्स्ट-पार्टी पासकी प्रोवाइडर माना जाता है। इसके विपरीत, थर्ड-पार्टी पासवर्ड मैनेजर जो API के ज़रिए प्लेटफ़ॉर्म के साथ इंटीग्रेट होते हैं, उन्हें थर्ड-पार्टी पासकी प्रोवाइडर कहा जाता है।
एक फ़र्स्ट-पार्टी या थर्ड-पार्टी पासकी प्रोवाइडर के पास समान Authenticator Attestation Globally Unique Identifiers (AAGUID) होते हैं, जो यूज़र एक्सपीरियंस को बेहतर बनाने में मदद करते हैं (जैसे, अकाउंट सेटिंग में पासकी को आसानी से अलग करने के लिए)। कभी-कभी उनके पास कई AAGUID हो सकते हैं, जो सभी एक ही फ़र्स्ट- या थर्ड-पार्टी पासकी प्रोवाइडर के होते हैं।
iOS 17.4 डिवाइस पर पासकी प्रोवाइडर
Android 14 डिवाइस पर पासकी प्रोवाइडर
Android का Credential Manager API
दूसरी श्रेणी में ऑथेंटिकेशन प्रोवाइडर शामिल हैं जिन्हें डेवलपर पासकी मैनेजमेंट के सभी पहलुओं को संभालने के लिए अपने ऐप्लिकेशन में इंटीग्रेट कर सकते हैं। तो, ये वे प्रोवाइडर हैं जो मुख्य रूप से सर्वर-साइड (ऊपर दिए गए क्लाइंट-साइड के बजाय) पर काम करते हैं। इस परिभाषा में Corbado जैसे समाधान भी शामिल होंगे, जो वेबसाइटों और ऐप्स को पासकी पर केंद्रित ऑथेंटिकेशन समाधान देते हैं। नतीजतन, इन पासकी प्रोवाइडर को पासकी ऑथेंटिकेशन प्रोवाइडर के रूप में अधिक सटीक रूप से वर्णित किया जाना चाहिए, जो उन्हें ऊपर बताए गए फ़र्स्ट- और थर्ड-पार्टी पासकी प्रोवाइडर से अलग करता है।
इस ब्लॉग पोस्ट के अगले सेक्शन में, हम अपनी परिभाषा के अनुसार, फ़र्स्ट और थर्ड-पार्टी पासकी प्रोवाइडर को बताने के लिए "पासकी प्रोवाइडर" शब्द का इस्तेमाल करेंगे।
जैसे-जैसे यूज़र अलग-अलग रिलाइंग पार्टी के लिए पासकी अपनाना शुरू करते हैं, उन्हें प्रभावी ढंग से मैनेज करना एक बड़ी चुनौती के रूप में सामने आता है। यह उन यूज़र्स के लिए भी सही है जो एक ही अकाउंट के लिए कई पासकी का इस्तेमाल करते हैं, क्योंकि एडिट करने या डिलीट करने के उद्देश्यों के लिए इन पासकी में अंतर करना रिलाइंग पार्टी के लिए मुश्किल हो सकता है। पासकी जो सुविधा और सुरक्षा देते हैं, उसके बावजूद एक संभावित समस्या है कि अगर कोई यूज़र अपनी पासकी में से एक खो देता है। सौभाग्य से, वे अभी भी वैकल्पिक पासकी का इस्तेमाल करके रिलाइंग पार्टी पर अपने अकाउंट तक पहुंच सकते हैं। यूज़र्स को विशिष्ट पासकी पहचानने में मदद करने के लिए, कुछ संसाधन मेटाडेटा को अकाउंट सेटिंग में पासकी बनाने और अंतिम इस्तेमाल की तारीखों जैसे सुझाव देते हैं। इसके अलावा, पासकी बनाने पर अपने-आप नाम देने और उन्हें कैटेगराइज़ करने के लिए यूज़र एजेंट या क्लाइंट हिंट का इस्तेमाल करने का सुझाव दिया जाता है। हालांकि, नेटिव Android या iOS ऐप्स के साथ-साथ थर्ड-पार्टी पासकी प्रोवाइडर, यूज़र एजेंट का इस्तेमाल नहीं कर सकते हैं, या वे ऐसी जानकारी नहीं जोड़ते हैं जो यह बताती हो कि पासकी किसी थर्ड-पार्टी पासकी प्रोवाइडर द्वारा जनरेट की गई है। यह लिमिटेशन प्लेटफ़ॉर्म या प्रोवाइडर की परवाह किए बिना, यूज़र्स को अपनी पासकी को कुशलतापूर्वक मैनेज करने में मदद करने के लिए बेहतर तरीकों की ज़रूरत को उजागर करती है।
W3C's WebAuthn specification से लिया गया
इस पासकी मैनेजमेंट को आसान बनाने के लिए, डेवलपर Authenticator Attestation Globally Unique Identifier (AAGUID) का इस्तेमाल कर सकते हैं। AAGUID ऑथेंटिकेटर के मॉडल को दिया गया एक यूनीक आइडेंटिफ़ायर है, न कि इसके विशिष्ट इंस्टेंस को। यह पब्लिक की क्रेडेंशियल के ऑथेंटिकेटर डेटा के भीतर एम्बेडेड होता है, जो रिलाइंग पार्टी को पासकी प्रोवाइडर की पहचान करने का एक तरीका देता है। यह क्षमता यूज़र्स और रिलाइंग पार्टी को पासकी लैंडस्केप को नेविगेट करने में मदद करने में महत्वपूर्ण है, यह पक्का करते हुए कि हर पासकी को उसके निर्माण स्रोत से सटीक रूप से जोड़ा जा सकता है।
उदाहरण के लिए, अगर किसी Android डिवाइस पर Google Password Manager का इस्तेमाल करके कोई पासकी बनाई जाती है, तो रिलाइंग पार्टी Google Password Manager के लिए विशिष्ट AAGUID हासिल कर सकती है। इस AAGUID का संदर्भ देकर, रिलाइंग पार्टी फिर पासकी को उसी के अनुसार मार्क कर सकती है, जिससे यूज़र के लिए मैनेजमेंट और पहचान आसान हो जाती है। इसके अलावा, रिलाइंग पार्टी WebAuthn सर्वर विकल्प excludeCredentials का इस्तेमाल करके एक ही पासकी प्रोवाइडर के लिए कई पासकी बनाने से रोक सकती हैं। यह पासकी के UX को और बेहतर बनाता है क्योंकि हर पासकी प्रोवाइडर के पास केवल एक पासकी होगी, इस तरह यूज़र के कन्फ्यूज़न से बचा जा सकेगा।
{ "attestation": "none", "authenticatorSelection": { "residentKey": "preferred", "userVerification": "preferred" }, "challenge": "6V61d0VM5bNTPxWSsrv7YKz0o4awe0ryoDh1V44RPRn6-mBQwv98BTRws6nMrBhEggGn7-tk1bl3YNSwc0oZpA", "excludeCredentials": [ { "id": "1kBn2dmhv5JhuFxqeco1khCBCUBLlWYqZmFtdDujH5pM", "transports": ["internal"], "type": "public-key" } ], "extensions": { "credProps": true }, "pubKeyCredParams": [ { "alg": -7, "type": "public-key" }, { "alg": -257, "type": "public-key" } ], "rp": { "id": "Passkey Demo", "name": "passkeys.eu" }, "user": { "displayName": "Test Name", "id": "ZG1sdVkyVnxe3SFJsYzNR", "name": "Test Name" } }
AAGUID का इस्तेमाल करके पासकी प्रोवाइडर का निर्धारण करने के लिए, रिलाइंग पार्टी community-sourced repository of AAGUIDs का संदर्भ ले सकती हैं। यह रिपॉज़िटरी पासकी प्रोवाइडर को नाम से और संभवतः आइकन से पहचानने के लिए ज़रूरी मैपिंग देती है, जिससे पासकी मैनेजमेंट के लिए अधिक सहज यूज़र इंटरफ़ेस देने में मदद मिलती है। हालांकि, यह ध्यान रखना ज़रूरी है कि कुछ पासकी प्रोवाइडर जानबूझकर किसी अनजान या जेनरिक प्रोवाइडर को दर्शाते हुए, जेनरिक AAGUID ("00000000-0000-0000-0000-0000000000000") का इस्तेमाल कर सकते हैं।
ज्यादातर WebAuthn लाइब्रेरी के साथ AAGUID फिर से हासिल करना सीधा है। उदाहरण के लिए, जब सर्वर-साइड पर SimpleWebAuthn का इस्तेमाल किया जाता है, तो डेवलपर किसी ज्ञात प्रोवाइडर के साथ मिलान करने के लिए रजिस्ट्रेशन जानकारी से AAGUID निकाल सकते हैं, जिससे यूज़र की अपनी पासकी को अधिक आसानी से मैनेज करने की क्षमता बढ़ जाती है (Google के "Determine the passkey provider with AAGUID" से लिया गया)।
// Import a list of AAGUIDs from a JSON file import aaguids from "./aaguids.json" with { type: "json" }; // ... // Use SimpleWebAuthn handy function to verify the registration request. const { verified, registrationInfo } = await verifyRegistrationResponse({ response: credential, expectedChallenge, expectedOrigin, expectedRPID, requireUserVerification: false, }); // ... const { aaguid } = registrationInfo; const provider_name = aaguids[aaguid]?.name || "Unknown";
हालांकि AAGUID पासकी मैनेजमेंट के लिए एक शक्तिशाली टूल देते हैं, लेकिन इनका इस्तेमाल सावधानी से किया जाना चाहिए। किसी AAGUID की इंटिग्रिटी attestation प्रोसेस पर निर्भर करती है, जो पासकी प्रोवाइडर की प्रामाणिकता को मान्य करती है। एक वैध attestation सिग्नेचर के बिना, AAGUID को संभावित रूप से मैनिपुलेट किया जा सकता है। मार्च 2024 तक, यह ध्यान देने योग्य है कि कुछ प्लेटफ़ॉर्म पर पासकी attestation को सपोर्ट नहीं करती हैं, जो उनके इस्तेमाल में सावधानीपूर्वक विचार करने की ज़रूरत को उजागर करता है।
नीचे, आप Android ऐप्स, iOS ऐप्स और वेब ऐप्स के लिए बहुत ही सामान्य पासकी ऑपरेटिंग सिस्टम वर्शन और ब्राउज़र का इस्तेमाल करने वाले फ़र्स्ट- और थर्ड-पार्टी पासकी प्रोवाइडर की एक अधूरी लिस्ट पा सकते हैं:
नीचे, आप पासकी बनाने / सहेजने के लिए कुछ थर्ड-पार्टी पासकी प्रोवाइडर के पॉपअप पा सकते हैं:
पूरी 1Password एनालिसिस यहां देखें।
पूरी Dashlane एनालिसिस यहां देखें।
पूरी KeePassXC एनालिसिस यहां देखें।
पासकी की डिप्लॉयमेंट और मैनेजमेंट के केंद्र में पासकी प्रोवाइडर की भूमिका है, ऐसी इकाइयां जो न केवल पासकी बनाने और मैनेज करने की सुविधा देती हैं बल्कि अलग-अलग प्लेटफ़ॉर्म और डिवाइस पर उनके निर्बाध इंटीग्रेशन को भी पक्का करती हैं।
पासकी प्रोवाइडर क्या है, यह समझना, जिसमें फ़र्स्ट-पार्टी और थर्ड-पार्टी प्रोवाइडर के बीच का अंतर शामिल है, साथ ही Authenticator Attestation Globally Unique Identifier (AAGUID) की महत्वपूर्ण भूमिका, इस ब्लॉग पोस्ट का लक्ष्य था। AAGUID का इस्तेमाल, जैसा कि चर्चा की गई है, एक आशाजनक समाधान देता है, जिससे पासकी की अधिक सीधी पहचान और मैनेजमेंट संभव होता है।
इसके अलावा, हमने एनालिसिस की है कि Android, iOS और Windows के लिए वर्तमान में कौन से फ़र्स्ट- और थर्ड-पार्टी पासकी प्रोवाइडर मौजूद हैं, जो यूज़र्स को एक उपयुक्त थर्ड-पार्टी पासकी प्रोवाइडर या उनकी पसंद का डिवाइस खोजने में भी मदद करते हैं।
डेवलपर और प्रोडक्ट मैनेजर के लिए, पासकी प्रोवाइडर और उनके मैनेजमेंट की जानकारी न केवल पासकी ऑथेंटिकेशन के तकनीकी इम्प्लीमेंटेशन को गाइड करती है, बल्कि यूज़र एक्सपीरियंस और सिक्योरिटी को बढ़ाने के व्यापक लक्ष्य के साथ भी जुड़ती है।
Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Passkey Intelligence Platform है। हम आपको वह दिखाते हैं जो IDP logs और सामान्य analytics tools नहीं दिखा सकते: कौन-से devices, OS versions, browsers और credential managers passkeys को support करते हैं, क्यों enrollments login में नहीं बदलते, WebAuthn flow कहाँ fail होता है, और कब कोई OS या browser update चुपचाप login को तोड़ देता है — और यह सब Okta, Auth0, Ping, Cognito या आपके in-house IDP को बदले बिना। दो products: Corbado Observe जोड़ता है passkeys और किसी भी अन्य login method के लिए observability। Corbado Connect देता है analytics के साथ built-in managed passkeys (आपके IDP के साथ-साथ)। VicRoads, Corbado के साथ 5M+ users के लिए passkeys चला रहा है (+80% passkey activation)। Passkey विशेषज्ञ से बात करें →
संबंधित लेख
विषय सूची