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

Zoho ने 2024 में पासकी को इंटिग्रेट किया. इसके बाद, उसने लॉगिन की स्पीड को पिछले तरीकों की तुलना में छह गुना बढ़ाया. साथ ही, पासकी को अपनाने की दर में हर महीने 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 के पुष्टि करने के मौजूदा तरीकों में, मुख्य तौर पर पासवर्ड और 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 क्रेडेंशियल की समस्याओं को ट्रैक करने वाले टूल की मदद से, हमसे संपर्क करें.