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

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

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

पुष्टि करने से जुड़ी समस्याओं को हल करना

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

चुनौतियां

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

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

पासवर्ड की जगह पासकी का इस्तेमाल क्यों किया जा रहा है?

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

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

Android पर Credential Manager के साथ लागू करना

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

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

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

पासकी बनाना

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

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

साइन-इन करें

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

सर्वर-साइड इंटिग्रेशन

Zoho के बैकएंड सिस्टम पहले से ही FIDO WebAuthn के मुताबिक काम करते हैं. इसलिए, पासकी की सुविधा को लागू करने के दौरान, सर्वर-साइड पर होने वाली प्रोसेस को आसान बनाने में मदद मिली. हालांकि, पासकी की सुविधा को पूरी तरह से इंटिग्रेट करने के लिए, कुछ बदलाव अब भी ज़रूरी थे.

सबसे बड़ी चुनौती, क्रेडेंशियल स्टोरेज सिस्टम को अडैप्ट करने से जुड़ी थी. Zoho में पुष्टि करने के मौजूदा तरीकों में, मुख्य रूप से पासवर्ड और एफ़आईडीओ सुरक्षा कुंजियों का इस्तेमाल किया जाता है. इनमें बहु-कारकीय पुष्टि के लिए, पासकी की तुलना में अलग-अलग स्टोरेज के तरीकों की ज़रूरत होती है. पासकी, क्रिप्टोग्राफ़िक सार्वजनिक कुंजियों पर आधारित होती हैं. इस समस्या को हल करने के लिए, 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 के UX से जुड़े सुझावों के आधार पर, 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 की टीम ने, server.encode और server.decode फ़ंक्शन के ज़रिए 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 की वेबसाइट पर मौजूद accounts पेज.

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

डेवलपर की स्पीड और इंटिग्रेशन की परफ़ॉर्मेंस पर असर

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

Credential Manager के साथ पासकी लागू करने से, Zoho को हर क्षेत्र में काफ़ी सुधार देखने को मिले. इन सुधारों को मेज़र किया जा सकता है:

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

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

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

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

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

पासकी और Credential Manager का इस्तेमाल शुरू करना

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

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