Zoho ने पासकी और क्रेडेंशियल मैनेजर के इंटिग्रेशन की मदद से, लॉगिन की स्पीड को 6 गुना बढ़ाया

Android डेवलपर के तौर पर, आप सुरक्षा को बेहतर बनाने, उपयोगकर्ता अनुभव को बेहतर बनाने, और डेवलपमेंट को आसान बनाने के तरीके लगातार खोजते रहते हैं. Zoho, क्लाउड पर आधारित सॉफ़्टवेयर का एक ऐसा सुइट है जो सुरक्षा और बेहतर अनुभव देने पर फ़ोकस करता है. Zoho ने अपने OneAuth Android ऐप्लिकेशन में पासकी की सुविधा जोड़कर, काफ़ी सुधार किए हैं.

Zoho ने 2024 में पासकी को इंटिग्रेट किया. इसके बाद, Zoho ने लॉगिन की स्पीड को पिछले तरीकों की तुलना में 6 गुना बढ़ाया . साथ ही, पासकी को अपनाने की दर में हर महीने (एमओएम) 31% की बढ़ोतरी हुई.

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

पुष्टि करने से जुड़ी चुनौतियों से पार पाना

Zoho, उपयोगकर्ता खातों को सुरक्षित रखने के लिए, पुष्टि करने के कई तरीकों का इस्तेमाल करता है. इसमें, Zoho OneAuth भी शामिल है. यह, मल्टी-फ़ैक्टर ऑथेंटिकेशन (एमएफ़ए) का अपना सलूशन है. इसमें पुश नोटिफ़िकेशन, क्यूआर कोड, और समय के हिसाब से एक बार इस्तेमाल होने वाले पासवर्ड (टीओटीपी) का इस्तेमाल करके, पासवर्ड के साथ और पासवर्ड के बिना, दोनों तरीकों से पुष्टि की जा सकती है. Zoho, फ़ेडरेटेड लॉगिन की सुविधा भी देता है. इससे, Security Assertion Markup Language (एसएएमएल) और तीसरे पक्ष के अन्य आइडेंटिटी प्रोवाइडर की मदद से पुष्टि की जा सकती है.

चुनौतियां

Zoho, कई संगठनों की तरह, पुष्टि करने की सुरक्षा और उपयोगकर्ता अनुभव को बेहतर बनाना चाहता था. साथ ही, वह ऑपरेशनल बोझ को कम करना चाहता था. पासकी को अपनाने की मुख्य चुनौतियां ये थीं:

• सुरक्षा से जुड़ी कमज़ोरियां: पासवर्ड पर आधारित पुराने तरीकों की वजह से, उपयोगकर्ताओं के फ़िशिंग हमलों और पासवर्ड के गलत इस्तेमाल का शिकार होने का खतरा बना रहता था.
• उपयोगकर्ताओं को होने वाली परेशानी: पासवर्ड याद रखने में होने वाली मुश्किलों की वजह से, लोग पासवर्ड भूल जाते थे. इससे उन्हें परेशानी होती थी और वे पासवर्ड वापस पाने की मुश्किल प्रोसेस पर ज़्यादा निर्भर हो जाते थे.
• ऑपरेशनल कमियां: पासवर्ड रीसेट करने और एमएफ़ए से जुड़ी समस्याओं को हल करने में, सहायता देने में काफ़ी खर्च आता था.
• स्केलेबिलिटी से जुड़ी समस्याएं: उपयोगकर्ता आधार बढ़ने की वजह से, पुष्टि करने के लिए ज़्यादा सुरक्षित और बेहतर सलूशन की ज़रूरत थी.

पासकी का इस्तेमाल क्यों शुरू किया गया?

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

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

Android पर क्रेडेंशियल मैनेजर के साथ लागू करना

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

क्रेडेंशियल मैनेजर, एक ऐसा यूनीफ़ाइड एपीआई उपलब्ध कराता है जिससे पुष्टि करने के अलग-अलग तरीकों को आसानी से मैनेज किया जा सकता है. पासवर्ड, पासकी, और फ़ेडरेटेड लॉगिन (जैसे, Google से साइन इन करें) के लिए अलग-अलग एपीआई इस्तेमाल करने के बजाय, एक ही इंटरफ़ेस का इस्तेमाल किया जाता है.

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

पासकी बनाना

पासकी बनाने के लिए, ऐप्लिकेशन सबसे पहले Zoho के सर्वर से कॉन्फ़िगरेशन की जानकारी लेता है. इस प्रोसेस में, पुष्टि करने का एक यूनीक तरीका शामिल होता है. जैसे, फ़िंगरप्रिंट या चेहरे की पहचान. पुष्टि करने के इस डेटा को requestJson स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है. इसका इस्तेमाल, ऐप्लिकेशन CreatePublicKeyCredentialRequest बनाने के लिए करता है. इसके बाद, ऐप्लिकेशन credentialManager.createCredential तरीके को कॉल करता है. इससे उपयोगकर्ता को अपने डिवाइस के स्क्रीन लॉक (बायोमेट्रिक्स, फ़िंगरप्रिंट, पिन वगैरह) का इस्तेमाल करके पुष्टि करने के लिए कहा जाता है.

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

साइन-इन करें

Zoho का Android ऐप्लिकेशन, पासकी से साइन-इन करने की प्रोसेस शुरू करने के लिए, Zoho के बैकएंड सर्वर से साइन-इन के विकल्पों का अनुरोध करता है. इसमें एक यूनीक challenge भी शामिल होता है. इसके बाद, ऐप्लिकेशन इस डेटा का इस्तेमाल करके, GetCredentialRequest बनाता है. इससे पता चलता है कि पासकी की मदद से पुष्टि की जाएगी. इसके बाद, यह इस अनुरोध के साथ, Android के CredentialManager.getCredential() एपीआई को कॉल करता है. इस कार्रवाई से, 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 ने सभी मामलों में, बेहतर नतीजे हासिल किए हैं. इन्हें मापा जा सकता है:

• लॉगिन की स्पीड में ज़बरदस्त बढ़ोतरी
  • पासवर्ड से पुष्टि करने के पुराने तरीके की तुलना में, लॉगिन की स्पीड दोगुनी हो गई.
  • ईमेल या एसएमएस पर ओटीपी से पुष्टि करने के साथ, उपयोगकर्ता नाम या मोबाइल नंबर की तुलना में, लॉगिन की स्पीड चार गुना हो गई.
  • उपयोगकर्ता नाम, पासवर्ड, और एसएमएस या ऑथेंटिकेटर ओटीपी से पुष्टि करने की तुलना में, लॉगिन की स्पीड छह गुना हो गई.
• सहायता के खर्च में कमी
  • पासवर्ड से जुड़े सहायता के अनुरोधों में कमी, खास तौर पर पासवर्ड भूल जाने के मामलों में.
  • एसएमएस पर आधारित दो चरणों में पुष्टि (2एफ़ए) से जुड़े खर्च में कमी, क्योंकि मौजूदा उपयोगकर्ता सीधे पासकी की मदद से ऑनबोर्ड हो सकते हैं.
• उपयोगकर्ताओं की दिलचस्पी और सुरक्षा में बढ़ोतरी:
  • सिर्फ़ चार महीनों में, पासकी से साइन-इन करने की दर दोगुनी हो गई. इससे पता चलता है कि उपयोगकर्ताओं ने पासकी को काफ़ी पसंद किया है.
  • पासकी पर माइग्रेट करने वाले उपयोगकर्ता, फ़िशिंग और पासवर्ड के गलत इस्तेमाल से जुड़े सामान्य खतरों से पूरी तरह सुरक्षित हैं.
  • हर महीने (एमओएम) 31% की बढ़ोतरी के साथ, ज़्यादा उपयोगकर्ता हर दिन, फ़िशिंग और सिम स्वैप जैसी कमज़ोरियों से सुरक्षा के बेहतर फ़ायदों का अनुभव कर रहे हैं.

सबसे सही तरीके और सुझाव

Android पर पासकी को सफलतापूर्वक लागू करने के लिए, डेवलपर को इन सबसे सही तरीकों को अपनाना चाहिए:

• Android के क्रेडेंशियल मैनेजर एपीआई का इस्तेमाल करना:
  • क्रेडेंशियल मैनेजर, क्रेडेंशियल वापस पाने की प्रोसेस को आसान बनाता है. इससे डेवलपर की मेहनत कम होती है और पुष्टि करने का एक जैसा अनुभव मिलता है.
  • यह, पासवर्ड, पासकी, और फ़ेडरेटेड लॉगिन के फ़्लो को एक ही इंटरफ़ेस में मैनेज करता है.
• FIDO के अन्य पुष्टि करने वाले सलूशन से माइग्रेट करते समय, डेटा कोडिंग में एकरूपता बनाए रखना:
  • FIDO के अन्य पुष्टि करने वाले सलूशन, जैसे कि FIDO सुरक्षा कुंजियों से माइग्रेट करते समय, पक्का करें कि सभी इनपुट/आउटपुट के लिए एक जैसा फ़ॉर्मैट इस्तेमाल किया जाए.
• गड़बड़ी ठीक करने और लॉगिंग की प्रोसेस को ऑप्टिमाइज़ करना:
  • उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, गड़बड़ी ठीक करने की मज़बूत सुविधा लागू करें.
  • गड़बड़ी के मैसेज को स्थानीय भाषा में उपलब्ध कराएं. साथ ही, गड़बड़ियों को डीबग करने और अनचाही गड़बड़ियों को ठीक करने के लिए, लॉग की पूरी जानकारी का इस्तेमाल करें.
• उपयोगकर्ताओं को पासकी वापस पाने के विकल्पों के बारे में जानकारी देना:
  • उपयोगकर्ताओं को पासकी वापस पाने के विकल्पों के बारे में पहले से जानकारी देकर, लॉकआउट की स्थितियों से बचाएं.
• पासकी अपनाने की मेट्रिक और उपयोगकर्ता के सुझाव या राय पर नज़र रखना:
  • उपयोगकर्ताओं की दिलचस्पी, पासकी अपनाने की दर, और लॉगिन की सफलता दर को ट्रैक करें, ताकि उपयोगकर्ता अनुभव को ऑप्टिमाइज़ किया जा सके.
  • कन्वर्ज़न और उपयोगकर्ता को अपने साथ जोड़े रखने की दर को बेहतर बनाने के लिए, पुष्टि करने के अलग-अलग फ़्लो पर A/B टेस्टिंग करें.

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

पासकी और क्रेडेंशियल मैनेजर का इस्तेमाल शुरू करना

हमारे सार्वजनिक सैंपल कोड का इस्तेमाल करके, Android पर पासकी और क्रेडेंशियल मैनेजर को आज़माएं.

अगर आपका कोई सवाल है या आपको कोई समस्या आ रही है, तो Android क्रेडेंशियल की समस्याओं को ट्रैक करने वाले टूल की मदद से, हमसे संपर्क करें.