Zoho ने पासकी और क्रेडेंशियल मैनेजर को इंटिग्रेट करके, लॉगिन करने की स्पीड को छह गुना बढ़ाया
10 मिनट में पढ़ें
Android डेवलपर के तौर पर, आप सुरक्षा को बेहतर बनाने, उपयोगकर्ता अनुभव को बेहतर बनाने, और डेवलपमेंट को आसान बनाने के तरीके लगातार खोजते रहते हैं. Zoho, क्लाउड पर आधारित सॉफ़्टवेयर का एक ऐसा सुइट है जो सुरक्षा और बेहतर अनुभव देने पर फ़ोकस करता है. Zoho ने अपने OneAuth Android ऐप्लिकेशन में पासकी की सुविधा जोड़कर, काफ़ी सुधार किए हैं.
Zoho ने 2024 में पासकी को इंटिग्रेट किया. इसके बाद, Zoho ने लॉगिन करने की स्पीड को पिछले तरीकों की तुलना में छह गुना बढ़ाया . साथ ही, पासकी को अपनाने की दर में हर महीने 31% की बढ़ोतरी हुई.
इस केस स्टडी में, पुष्टि करने में आने वाली मुश्किलों को दूर करने के लिए, Zoho के पासकी और Android के क्रेडेंशियल मैनेजर API को अपनाने के बारे में बताया गया है. इसमें, तकनीकी तौर पर लागू करने की प्रोसेस के बारे में जानकारी दी गई है. साथ ही, इसके असरदार नतीजों को हाइलाइट किया गया है.
पुष्टि करने में आने वाली मुश्किलों को दूर करना
Zoho, उपयोगकर्ता खातों को सुरक्षित रखने के लिए, पुष्टि करने के कई तरीकों का इस्तेमाल करता है. इसमें, Zoho OneAuth भी शामिल है. यह, मल्टी-फ़ैक्टर ऑथेंटिकेशन (एमएफ़ए) का अपना सलूशन है. इसमें पुश नोटिफ़िकेशन, क्यूआर कोड, और समय के हिसाब से जनरेट होने वाले एक बार इस्तेमाल किए जा सकने वाले पासवर्ड (टीओटीपी) का इस्तेमाल करके, पासवर्ड के साथ और पासवर्ड के बिना, दोनों तरह से पुष्टि की जा सकती है. Zoho, फ़ेडरेटेड लॉगिन की सुविधा भी देता है. इससे, Security Assertion Markup Language (एसएएमएल) और तीसरे पक्ष के अन्य आइडेंटिटी प्रोवाइडर की मदद से पुष्टि की जा सकती है.
चुनौतियां
Zoho का मकसद, कई अन्य संगठनों की तरह ही, पुष्टि करने की सुरक्षा और उपयोगकर्ता अनुभव को बेहतर बनाना था. साथ ही, ऑपरेशनल बोझ को कम करना था. पासकी को अपनाने की मुख्य वजहें ये थीं:
- सुरक्षा से जुड़ी कमज़ोरियां: पासवर्ड के आधार पर पुष्टि करने के पुराने तरीकों की वजह से, उपयोगकर्ताओं के फ़िशिंग हमलों और पासवर्ड के गलत इस्तेमाल का शिकार होने की आशंका बनी रहती थी.
- उपयोगकर्ता की परेशानी: पासवर्ड याद रखने में होने वाली मुश्किलों की वजह से, लोग पासवर्ड भूल जाते थे. इससे उन्हें परेशानी होती थी और वे पासवर्ड वापस पाने की मुश्किल प्रोसेस पर ज़्यादा निर्भर रहते थे.
- ऑपरेशनल कमियां: पासवर्ड रीसेट करने और एमएफ़ए से जुड़ी समस्याओं को हल करने में, सहायता देने में काफ़ी समय और संसाधन खर्च होते थे.
- स्केलेबिलिटी से जुड़ी समस्याएं: उपयोगकर्ता आधार बढ़ने की वजह से, पुष्टि करने के लिए ज़्यादा सुरक्षित और बेहतर सलूशन की ज़रूरत थी.
पासकी का इस्तेमाल क्यों शुरू किया गया?
Zoho के ऐप्लिकेशन में पासकी की सुविधा इसलिए लागू की गई, ताकि पुष्टि करने में आने वाली मुश्किलों को दूर किया जा सके. इसके लिए, पासवर्ड के बिना पुष्टि करने का तरीका अपनाया गया. इससे सुरक्षा और उपयोगकर्ता अनुभव, दोनों को बेहतर बनाया जा सका. इस सलूशन में, फ़िशिंग से सुरक्षित पुष्टि करने की सुविधा, अलग-अलग डिवाइसों पर आसानी से ऐक्सेस करने के लिए क्लाउड में सिंक किए गए क्रेडेंशियल, और सुरक्षित लॉगिन के लिए बायोमेट्रिक्स (जैसे, फ़िंगरप्रिंट या चेहरे की पहचान), पिन या पैटर्न का इस्तेमाल किया जाता है. इससे, पासवर्ड के पुराने तरीकों से जुड़ी कमज़ोरियां और परेशानियां कम हो जाती हैं.
क्रेडेंशियल मैनेजर के साथ पासकी को अपनाने से, Zoho ने लॉगिन करने में लगने वाले समय को छह गुना तक कम किया. साथ ही, पासवर्ड से जुड़ी सहायता के खर्च में कटौती की और उपयोगकर्ताओं की दिलचस्पी देखी गई. चार महीनों में पासकी से साइन इन करने की दर दोगुनी हो गई. साथ ही, हर महीने 31% की बढ़ोतरी हुई. Zoho के उपयोगकर्ता अब तेज़ और आसान लॉगिन के साथ-साथ, फ़िशिंग से सुरक्षित सुरक्षा का फ़ायदा उठा सकते हैं.
Android पर क्रेडेंशियल मैनेजर के साथ लागू करना
तो, Zoho ने ये नतीजे कैसे हासिल किए? उन्होंने Android के क्रेडेंशियल मैनेजर API का इस्तेमाल किया. यह, Android पर पुष्टि करने की सुविधा लागू करने के लिए, Jetpack लाइब्रेरी का सुझाव दिया गया तरीका है.
क्रेडेंशियल मैनेजर, एक ऐसा यूनीफ़ाइड एपीआई है जो पुष्टि करने के अलग-अलग तरीकों को मैनेज करने की प्रोसेस को आसान बनाता है. पासवर्ड, पासकी, और फ़ेडरेटेड लॉगिन (जैसे, Google से साइन इन करें) के लिए अलग-अलग एपीआई इस्तेमाल करने के बजाय, एक ही इंटरफ़ेस का इस्तेमाल किया जाता है.
Zoho में पासकी की सुविधा लागू करने के लिए, क्लाइंट-साइड और सर्वर-साइड, दोनों में बदलाव करने पड़े. यहां, पासकी बनाने, साइन इन करने, और सर्वर-साइड पर लागू करने की प्रोसेस के बारे में ज़्यादा जानकारी दी गई है.
पासकी बनाना
पासकी बनाने के लिए, ऐप्लिकेशन सबसे पहले Zoho के सर्वर से कॉन्फ़िगरेशन की जानकारी लेता है. इस प्रोसेस में, पुष्टि करने का एक यूनीक तरीका शामिल होता है. जैसे, फ़िंगरप्रिंट या चेहरे की पहचान. पुष्टि करने के इस डेटा को requestJson स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है. इसका इस्तेमाल, ऐप्लिकेशन CreatePublicKeyCredentialRequest बनाने के लिए करता है. इसके बाद, ऐप्लिकेशन credentialManager.createCredential तरीके को कॉल करता है. इससे उपयोगकर्ता को अपने डिवाइस के स्क्रीन लॉक (बायोमेट्रिक्स, फ़िंगरप्रिंट, पिन वगैरह) का इस्तेमाल करके पुष्टि करने के लिए कहा जाता है.
उपयोगकर्ता की पुष्टि हो जाने के बाद, ऐप्लिकेशन को नई पासकी क्रेडेंशियल का डेटा मिलता है. यह डेटा, पुष्टि के लिए Zoho के सर्वर पर वापस भेजा जाता है. इसके बाद, सर्वर पासकी की जानकारी को उपयोगकर्ता के खाते से लिंक करके सेव कर लेता है. इस प्रोसेस के दौरान, गड़बड़ियां होने या उपयोगकर्ता के रद्द करने पर, ऐप्लिकेशन उन्हें पकड़कर मैनेज करता है.
साइन-इन करें
Zoho Android ऐप्लिकेशन, पासकी से साइन इन करने की प्रोसेस शुरू करने के लिए, Zoho के बैकएंड सर्वर से साइन इन करने के विकल्पों का अनुरोध करता है. इनमें, एक यूनीक challenge भी शामिल होता है. इसके बाद, ऐप्लिकेशन इस डेटा का इस्तेमाल करके, GetCredentialRequest बनाता है. इससे पता चलता है कि पासकी की मदद से पुष्टि की जाएगी. इसके बाद, यह इस अनुरोध के साथ, Android CredentialManager.getCredential() API को कॉल करता है. इस कार्रवाई से, Android सिस्टम का एक स्टैंडर्ड इंटरफ़ेस ट्रिगर होता है. इसमें उपयोगकर्ता को अपना Zoho खाता चुनने के लिए कहा जाता है. अगर एक से ज़्यादा पासकी मौजूद हैं, तो उपयोगकर्ता को अपने डिवाइस के कॉन्फ़िगर किए गए स्क्रीन लॉक (फ़िंगरप्रिंट, फ़ेस स्कैन या पिन) का इस्तेमाल करके पुष्टि करनी होती है. पुष्टि हो जाने के बाद, क्रेडेंशियल मैनेजर, Zoho ऐप्लिकेशन को साइन किया गया दावा (लॉगिन का सबूत) दिखाता है. ऐप्लिकेशन इस दावे को Zoho के सर्वर पर फ़ॉरवर्ड करता है. सर्वर, उपयोगकर्ता की सेव की गई सार्वजनिक पासकोड के हिसाब से हस्ताक्षर की पुष्टि करता है और चुनौती की पुष्टि करता है. इससे, सुरक्षित तरीके से साइन इन करने की प्रोसेस पूरी हो जाती है.
सर्वर-साइड पर लागू करना
Zoho के बैकएंड सिस्टम, पहले से ही FIDO WebAuthn के मुताबिक थे. इसलिए, पासकी की सुविधा लागू करने में Zoho को फ़ायदा मिला. इससे, सर्वर-साइड पर लागू करने की प्रोसेस आसान हो गई. हालांकि, पासकी की सुविधा को पूरी तरह से इंटिग्रेट करने के लिए, कुछ खास बदलाव अब भी ज़रूरी थे.
सबसे बड़ी चुनौती, क्रेडेंशियल स्टोरेज सिस्टम में बदलाव करना था. Zoho के पुष्टि करने के मौजूदा तरीकों में, मुख्य तौर पर पासवर्ड और FIDO सुरक्षा कुंजियों का इस्तेमाल किया जाता था. इसके लिए, पासकी की तुलना में अलग स्टोरेज के तरीकों की ज़रूरत थी. पासकी, क्रिप्टोग्राफ़िक सार्वजनिक पासकोड पर आधारित होती हैं. इसे ठीक करने के लिए, Zoho ने एक नया डेटाबेस स्कीमा लागू किया. इसे खास तौर पर, WebAuthn प्रोटोकॉल के मुताबिक, पासकी के सार्वजनिक पासकोड और उससे जुड़े डेटा को सुरक्षित तरीके से सेव करने के लिए डिज़ाइन किया गया था. इस नए सिस्टम को, उपयोगकर्ता और डिवाइस की जानकारी के आधार पर क्रेडेंशियल की पुष्टि करने और उन्हें वापस पाने के लिए, लुकअप मैकेनिज़्म के साथ बनाया गया था. इससे, पुष्टि करने के पुराने तरीकों के साथ बैकवर्ड कंपैटिबिलिटी पक्का की गई.
सर्वर-साइड पर किए गए एक और बदलाव में, Android डिवाइसों से मिलने वाले अनुरोधों को मैनेज करने की सुविधा लागू करना शामिल था. Android ऐप्लिकेशन से मिलने वाले पासकी के अनुरोध, एक यूनीक ऑरिजिन फ़ॉर्मैट (android:apk-key-hash:example) का इस्तेमाल करते हैं. यह, यूआरआई पर आधारित फ़ॉर्मैट (https://example.com/app) का इस्तेमाल करने वाले स्टैंडर्ड वेब ऑरिजिन से अलग होता है. इस फ़ॉर्मैट को सही तरीके से पार्स करने, ऐप्लिकेशन के साइनिंग सर्टिफ़िकेट के SHA-256 फ़िंगरप्रिंट हैश को निकालने, और पहले से रजिस्टर की गई सूची के हिसाब से उसकी पुष्टि करने के लिए, सर्वर लॉजिक को अपडेट करना पड़ा. पुष्टि करने के इस चरण से यह पक्का होता है कि पुष्टि करने के अनुरोध, असल में Zoho के Android ऐप्लिकेशन से मिले हैं. साथ ही, फ़िशिंग हमलों से सुरक्षा मिलती है.
कोड स्निपेट का यह हिस्सा दिखाता है कि सर्वर, Android के लिए खास ऑरिजिन फ़ॉर्मैट की जांच कैसे करता है और सर्टिफ़िकेट हैश की पुष्टि कैसे करता है:
val origin: String = clientData.getString("origin")
if (origin.startsWith("android:apk-key-hash:")) {
val originSplit: List<String> = origin.split(":")
if (originSplit.size > 3) {
val androidOriginHashDecoded: ByteArray = Base64.getDecoder().decode(originSplit[3])
if (!androidOriginHashDecoded.contentEquals(oneAuthSha256FingerPrint)) {
throw IAMException(IAMErrorCode.WEBAUTH003)
}
} else {
// Optional: Handle the case where the origin string is malformed }
}गड़बड़ी ठीक करना
Zoho ने, उपयोगकर्ताओं और डेवलपर को दिखने वाली गड़बड़ियों को मैनेज करने के लिए, गड़बड़ी ठीक करने के मज़बूत मैकेनिज़्म लागू किए. CreateCredentialCancellationException नाम की एक सामान्य गड़बड़ी तब दिखती थी, जब उपयोगकर्ता पासकी का सेटअप मैन्युअल तरीके से रद्द कर देते थे. Zoho ने इस गड़बड़ी की फ़्रीक्वेंसी को ट्रैक किया, ताकि यूएक्स में संभावित सुधारों का आकलन किया जा सके. Android के यूएक्स से जुड़े सुझावों के आधार पर, Zoho ने अपने उपयोगकर्ताओं को पासकी के बारे में बेहतर तरीके से जानकारी देने के लिए कदम उठाए. साथ ही, यह पक्का किया कि उपयोगकर्ताओं को पासकी की उपलब्धता के बारे में पता हो. इसके अलावा, बाद में साइन इन करने की कोशिशों के दौरान, पासकी को अपनाने के लिए बढ़ावा दिया.
कोड का यह उदाहरण, Zoho के उस तरीके को दिखाता है जिससे वे पासकी बनाने में होने वाली सबसे सामान्य गड़बड़ियों को मैनेज करते थे:
private fun handleFailure(e: CreateCredentialException) {
val msg = when (e) {
is CreateCredentialCancellationException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_CANCELLED", GROUP_NAME)
Analytics.addNonFatalException(e)
"The operation was canceled by the user."
}
is CreateCredentialInterruptedException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_INTERRUPTED", GROUP_NAME)
Analytics.addNonFatalException(e)
"Passkey setup was interrupted. Please try again."
}
is CreateCredentialProviderConfigurationException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_PROVIDER_MISCONFIGURED", GROUP_NAME)
Analytics.addNonFatalException(e)
"Credential provider misconfigured. Contact support."
}
is CreateCredentialUnknownException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_UNKNOWN_ERROR", GROUP_NAME)
Analytics.addNonFatalException(e)
"An unknown error occurred during Passkey setup."
}
is CreatePublicKeyCredentialDomException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_WEB_AUTHN_ERROR", GROUP_NAME)
Analytics.addNonFatalException(e)
"Passkey creation failed: ${e.domError}"
}
else -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_FAILED", GROUP_NAME)
Analytics.addNonFatalException(e)
"An unexpected error occurred. Please try again."
}
}
}इंट्रानेट एनवायरमेंट में पासकी की टेस्टिंग
Zoho को, बंद इंट्रानेट एनवायरमेंट में पासकी की टेस्टिंग करने में शुरुआती चुनौती का सामना करना पड़ा. पासकी के लिए, Google Password Manager की पुष्टि करने की प्रोसेस में, आरपी (रिलाइंग पार्टी) डोमेन की पुष्टि करने के लिए, सार्वजनिक डोमेन ऐक्सेस की ज़रूरत होती है. हालांकि, Zoho के इंटरनल टेस्टिंग एनवायरमेंट में, सार्वजनिक इंटरनेट ऐक्सेस नहीं था. इस वजह से, पुष्टि करने की प्रोसेस पूरी नहीं हो पाई और पासकी की पुष्टि करने की टेस्टिंग सफल नहीं हो पाई. इसे ठीक करने के लिए, Zoho ने सार्वजनिक तौर पर ऐक्सेस किया जा सकने वाला एक टेस्टिंग एनवायरमेंट बनाया. इसमें, एसेट लिंक फ़ाइल और डोमेन की पुष्टि के साथ, एक अस्थायी सर्वर होस्ट करना शामिल था.
Zoho के सार्वजनिक टेस्टिंग एनवायरमेंट में इस्तेमाल की गई assetlinks.json फ़ाइल का यह उदाहरण दिखाता है कि पासकी की पुष्टि के लिए, रिलाइंग पार्टी डोमेन को बताए गए Android ऐप्लिकेशन से कैसे जोड़ा जाए.
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.zoho.accounts.oneauth",
"sha256_cert_fingerprints": [
"SHA_HEX_VALUE"
]
}
}
]मौजूदा FIDO सर्वर के साथ इंटिग्रेट करना
Android का पासकी सिस्टम, FIDO2 WebAuthn के आधुनिक स्टैंडर्ड का इस्तेमाल करता है. इस स्टैंडर्ड के लिए, खास JSON फ़ॉर्मैट में अनुरोधों की ज़रूरत होती है. इससे, नेटिव ऐप्लिकेशन और वेब प्लैटफ़ॉर्म के बीच एकरूपता बनाए रखने में मदद मिलती है. Android पर पासकी की सुविधा चालू करने के लिए, Zoho ने कंपैटिबिलिटी और स्ट्रक्चर में मामूली बदलाव किए, ताकि FIDO2 JSON स्ट्रक्चर के मुताबिक अनुरोध सही तरीके से जनरेट और प्रोसेस किए जा सकें.
सर्वर के इस अपडेट में, कई खास तकनीकी बदलाव शामिल थे:
1. कोडिंग में बदलाव: सर्वर, काम का डेटा सेव करने से पहले, Base64 यूआरएल कोडिंग (आम तौर पर WebAuthn में, क्रेडेंशियल आईडी जैसे फ़ील्ड के लिए इस्तेमाल की जाती है) को स्टैंडर्ड Base64 कोडिंग में बदलता है. नीचे दिए गए स्निपेट में दिखाया गया है कि rawId को स्टैंडर्ड Base64 में कैसे कोड किया जा सकता है:
// Convert rawId bytes to a standard Base64 encoded string for storage val base64RawId: String = Base64.getEncoder().encodeToString(rawId.toByteArray())
2. ट्रांसपोर्ट लिस्ट फ़ॉर्मैट: डेटा की प्रोसेसिंग में एकरूपता बनाए रखने के लिए, सर्वर लॉजिक, ट्रांसपोर्ट मैकेनिज़्म की सूचियों (जैसे, यूएसबी, एनएफ़सी, और ब्लूटूथ, जिनसे यह तय होता है कि ऑथेंटिकेटर ने कैसे कम्यूनिकेट किया) को JSON कलेक्शन के तौर पर मैनेज करता है.
3. क्लाइंट डेटा अलाइनमेंट: Zoho की टीम ने, सर्वर के clientDataJson फ़ील्ड को कोड और डिकोड करने के तरीके में बदलाव किया. इससे यह पक्का होता है कि डेटा स्ट्रक्चर, Zoho के मौजूदा इंटरनल एपीआई की उम्मीदों के मुताबिक हो. नीचे दिए गए उदाहरण में, सर्वर के डेटा को प्रोसेस करने से पहले, क्लाइंट डेटा पर लागू किए गए कन्वर्ज़न लॉजिक का हिस्सा दिखाया गया है:
private fun convertForServer(type: String): String {
val clientDataBytes = BaseEncoding.base64().decode(type)
val clientDataJson = JSONObject(String(clientDataBytes, StandardCharsets.UTF_8))
val clientJson = JSONObject()
val challengeFromJson = clientDataJson.getString("challenge")
// 'challenge' is a technical identifier/token, not localizable text.
clientJson.put("challenge", BaseEncoding.base64Url()
.encode(challengeFromJson.toByteArray(StandardCharsets.UTF_8)))
clientJson.put("origin", clientDataJson.getString("origin"))
clientJson.put("type", clientDataJson.getString("type"))
clientJson.put("androidPackageName", clientDataJson.getString("androidPackageName"))
return BaseEncoding.base64().encode(clientJson.toString().toByteArray())
}उपयोगकर्ता के लिए निर्देश और पुष्टि करने की प्राथमिकताएं
Zoho की पासकी की रणनीति का मुख्य हिस्सा, उपयोगकर्ताओं को पासकी अपनाने के लिए बढ़ावा देना था. साथ ही, अलग-अलग संगठनों की ज़रूरतों के हिसाब से फ़्लेक्सिबिलिटी देना था. यह, यूज़र इंटरफ़ेस (यूआई) को ध्यान से डिज़ाइन करके और नीति कंट्रोल की मदद से हासिल किया गया.
Zoho को पता था कि संगठनों की सुरक्षा से जुड़ी ज़रूरतें अलग-अलग होती हैं. इसे ध्यान में रखते हुए, Zoho ने ये सुविधाएं लागू कीं:
- एडमिन की ओर से लागू करना: Zoho Directory के एडमिन पैनल के ज़रिए, एडमिन पासकी को अपने पूरे संगठन के लिए, पुष्टि करने का ज़रूरी और डिफ़ॉल्ट तरीका बना सकते हैं. जब यह नीति चालू होती है, तो कर्मचारियों को अगली बार लॉगिन करने पर पासकी सेट अप करनी होती है और आगे भी इसका इस्तेमाल करना होता है.
- उपयोगकर्ता के लिए विकल्प: अगर कोई संगठन, किसी खास नीति को लागू नहीं करता है, तो उपयोगकर्ताओं के पास कंट्रोल रहता है. वे लॉगिन के दौरान, पुष्टि करने का अपना पसंदीदा तरीका चुन सकते हैं. इसके लिए, वे अपनी पुष्टि करने की सेटिंग में जाकर, पासकी या कॉन्फ़िगर किए गए अन्य विकल्पों में से कोई एक चुन सकते हैं.
Zoho ने, पासकी को एंड-यूज़र के लिए आकर्षक और आसान बनाने के लिए, ये सुविधाएं लागू कीं:
- आसान सेटअप: Zoho ने पासकी सेटअप को सीधे Zoho OneAuth मोबाइल ऐप्लिकेशन (Android और iOS, दोनों के लिए उपलब्ध) में इंटिग्रेट किया. उपयोगकर्ता, ऐप्लिकेशन में किसी भी समय अपनी पासकी को आसानी से कॉन्फ़िगर कर सकते हैं. इससे, पासकी पर स्विच करना आसान हो जाता है.
- लगातार ऐक्सेस: पासकी की सुविधा, उपयोगकर्ता के अहम टचपॉइंट पर लागू की गई थी. इससे यह पक्का किया गया कि उपयोगकर्ता, पासकी का इस्तेमाल करके रजिस्टर और पुष्टि कर सकें. इसके लिए, ये तरीके अपनाए जा सकते हैं:
- Zoho OneAuth मोबाइल ऐप्लिकेशन (Android और iOS);
- Zoho के वेब खातों का पेज.
इस तरीके से यह पक्का किया गया कि पासकी सेट अप करने और इस्तेमाल करने की प्रोसेस, उन प्लैटफ़ॉर्म में इंटिग्रेट की गई हो जिनका इस्तेमाल उपयोगकर्ता पहले से करते हैं. साथ ही, यह प्रोसेस सभी के लिए उपलब्ध हो. भले ही, इसे एडमिन ने ज़रूरी बनाया हो या उपयोगकर्ता ने चुना हो. पासकी की मदद से पुष्टि करने के लिए, उपयोगकर्ता के लिए आसान फ़्लो बनाने के तरीके के बारे में ज़्यादा जानने के लिए, पासकी के उपयोगकर्ता अनुभव से जुड़ी हमारी पूरी गाइड देखें.
डेवलपर की स्पीड और इंटिग्रेशन की क्षमता पर असर
क्रेडेंशियल मैनेजर, एक यूनीफ़ाइड एपीआई होने की वजह से, साइन इन करने के पुराने फ़्लो की तुलना में, डेवलपर की प्रॉडक्टिविटी को बेहतर बनाने में भी मददगार साबित हुआ. इससे, पुष्टि करने के कई तरीकों और एपीआई को अलग-अलग मैनेज करने की मुश्किल कम हुई. इससे, इंटिग्रेशन की प्रोसेस महीनों के बजाय हफ़्तों में पूरी हुई और लागू करने में कम गड़बड़ियां हुईं. इन सभी वजहों से, साइन इन करने की प्रोसेस आसान हुई और पूरी विश्वसनीयता बेहतर हुई.
क्रेडेंशियल मैनेजर के साथ पासकी की सुविधा लागू करके, Zoho ने हर मामले में, काफ़ी और मेज़र किए जा सकने वाले सुधार किए:
- स्पीड में ज़बरदस्त सुधार
- पासवर्ड के आधार पर पुष्टि करने के परंपरागत तरीके की तुलना में, दो गुना तेज़ी से लॉगिन करना.
- ईमेल या एसएमएस पर ओटीपी की मदद से, उपयोगकर्ता नाम या मोबाइल नंबर से पुष्टि करने की तुलना में, चार गुना तेज़ी से लॉगिन करना.
- उपयोगकर्ता नाम, पासवर्ड, और एसएमएस या ऑथेंटिकेटर ओटीपी की मदद से पुष्टि करने की तुलना में, छह गुना तेज़ी से लॉगिन करना.
- सहायता के खर्च में कमी
- पासवर्ड से जुड़े सहायता के अनुरोधों में कमी, खास तौर पर पासवर्ड भूल जाने के मामलों में.
- एसएमएस पर आधारित दो चरणों में पुष्टि (2FA) से जुड़े खर्च में कमी, क्योंकि मौजूदा उपयोगकर्ता सीधे पासकी की मदद से ऑनबोर्ड हो सकते हैं.
- उपयोगकर्ताओं की दिलचस्पी और सुरक्षा में बढ़ोतरी:
- सिर्फ़ चार महीनों में, पासकी से साइन इन करने की दर दोगुनी हो गई. इससे पता चलता है कि उपयोगकर्ताओं ने पासकी को काफ़ी पसंद किया है.
- पासकी पर माइग्रेट करने वाले उपयोगकर्ताओं को, फ़िशिंग और पासवर्ड के गलत इस्तेमाल के सामान्य खतरों से पूरी सुरक्षा मिलती है.
- हर महीने 31% की बढ़ोतरी के साथ, ज़्यादा उपयोगकर्ता हर दिन, फ़िशिंग और सिम स्वैप जैसी कमज़ोरियों से सुरक्षा के बेहतर फ़ायदों का अनुभव कर रहे हैं.
सबसे सही तरीके और सुझाव
Android पर पासकी की सुविधा को सफलतापूर्वक लागू करने के लिए, डेवलपर को इन सबसे सही तरीकों को अपनाना चाहिए:
- Android के क्रेडेंशियल मैनेजर API का इस्तेमाल करना:
- क्रेडेंशियल मैनेजर, क्रेडेंशियल वापस पाने की प्रोसेस को आसान बनाता है. इससे डेवलपर की मेहनत कम होती है और पुष्टि करने का एक जैसा अनुभव मिलता है.
- यह, पासवर्ड, पासकी, और फ़ेडरेटेड लॉगिन के फ़्लो को एक ही इंटरफ़ेस में मैनेज करता है.
- FIDO के अन्य सलूशन से माइग्रेट करते समय, डेटा कोडिंग में एकरूपता बनाए रखना:
- FIDO के अन्य सलूशन, जैसे कि FIDO सुरक्षा कुंजियों से माइग्रेट करते समय, पक्का करें कि सभी इनपुट/आउटपुट के लिए एक जैसा फ़ॉर्मैट इस्तेमाल किया जाए.
- गड़बड़ी ठीक करने और लॉगिंग की प्रोसेस को ऑप्टिमाइज़ करना:
- उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, गड़बड़ी ठीक करने के मज़बूत मैकेनिज़्म लागू करें.
- स्थानीय भाषा में गड़बड़ी के मैसेज दें. साथ ही, गड़बड़ियों को डीबग करने और अनचाही गड़बड़ियों को ठीक करने के लिए, विस्तृत लॉग का इस्तेमाल करें.
- उपयोगकर्ताओं को पासकी वापस पाने के विकल्पों के बारे में जानकारी देना:
- उपयोगकर्ताओं को पासकी वापस पाने के विकल्पों के बारे में पहले से जानकारी देकर, लॉकआउट की स्थितियों से बचें.
- पासकी अपनाने से जुड़ी मेट्रिक और उपयोगकर्ता के सुझाव या राय पर नज़र रखना:
- उपयोगकर्ताओं की दिलचस्पी, पासकी अपनाने की दर, और लॉगिन की सफलता दर को ट्रैक करें, ताकि उपयोगकर्ता अनुभव को ऑप्टिमाइज़ किया जा सके.
- कन्वर्ज़न और उपयोगकर्ता को अपने साथ जोड़े रखने की दर को बेहतर बनाने के लिए, पुष्टि करने के अलग-अलग फ़्लो पर A/B टेस्टिंग करें.
पासकी और Android के क्रेडेंशियल मैनेजर API, पुष्टि करने का एक मज़बूत और यूनीफ़ाइड सलूशन है. इससे सुरक्षा बेहतर होती है और उपयोगकर्ता अनुभव आसान होता है. पासकी की मदद से, फ़िशिंग के जोखिम, क्रेडेंशियल की चोरी, और बिना अनुमति के ऐक्सेस को काफ़ी हद तक कम किया जा सकता है. हम डेवलपर को सुझाव देते हैं कि वे अपने ऐप्लिकेशन में पासकी की सुविधा आज़माएं और अपने उपयोगकर्ताओं को पुष्टि करने का सबसे सुरक्षित तरीका उपलब्ध कराएं.
पासकी और क्रेडेंशियल मैनेजर का इस्तेमाल शुरू करना
हमारे सार्वजनिक सैंपल कोड का इस्तेमाल करके, Android पर पासकी और क्रेडेंशियल मैनेजर को आज़माएं.
अगर आपका कोई सवाल है या आपको कोई समस्या आ रही है, तो Android क्रेडेंशियल की समस्याओं को ट्रैक करने वाले टूल के ज़रिए हमसे संपर्क करें.
-
केस स्टडीUber ने नए डिवाइस से साइन इन करने की प्रोसेस को आसान बनाने के लिए, Android के क्रेडेंशियल वापस पाने के एपीआई का इस्तेमाल किया. इससे, हर साल मैन्युअल तरीके से होने वाले 40 लाख लॉगिन कम होने का अनुमान है. साथ ही, उपयोगकर्ता को अपने साथ जोड़े रखने की दर में बढ़ोतरी हुई है.
Niharika Arora, Tracy Agyemang • 5 मिनट में पढ़ें -
केस स्टडीX, एक सोशल मीडिया ऐप्लिकेशन है. यह दुनिया भर के करीब 50 करोड़ उपयोगकर्ताओं को, ताज़ा खबरों और मनोरंजन से लेकर खेल और राजनीति तक की पूरी जानकारी, लाइव कमेंट्री के साथ उपलब्ध कराता है.
Niharika Arora, Tracy Agyemang • 3 मिनट में पढ़ें -
केस स्टडीपरफ़ॉर्मेंस रिग्रेशन को दोबारा बनाना मुश्किल होता है. इसलिए, यह मोबाइल डेवलपर के लिए एक बड़ा बॉटलनेक होता है.
Alice Yuan, Arti Arutiunov, Nikita Ogorodnikov • 4 मिनट में पढ़ें
Android डेवलपमेंट से जुड़ी नई जानकारी, हर हफ़्ते अपने ईमेल में पाएं