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 क्रेडेंशियल की समस्याओं को ट्रैक करने वाले टूल की मदद से, हमसे संपर्क करें.