पहने जाने वाले डिवाइसों पर पुष्टि करने की सुविधा: क्रेडेंशियल मैनेजर

Wear OS ऐप्लिकेशन, कंपैनियन ऐप्लिकेशन के बिना भी काम कर सकते हैं. इसका मतलब है कि इंटरनेट से डेटा ऐक्सेस करते समय, Wear OS ऐप्लिकेशन को पुष्टि करने की प्रोसेस खुद मैनेज करनी होगी. हालांकि, स्मार्टवॉच की छोटी स्क्रीन और इनपुट की कम सुविधाओं की वजह से, Wear OS ऐप्लिकेशन के लिए पुष्टि करने के विकल्पों की संख्या सीमित हो जाती है.

इस गाइड में, Wear OS ऐप्लिकेशन के लिए पुष्टि करने के सुझाए गए तरीके, Credential Manager के बारे में निर्देश दिए गए हैं.

साइन-इन करने का बेहतर अनुभव देने के लिए, साइन-इन करने से जुड़े यूज़र एक्सपीरियंस के दिशा-निर्देश देखें.

शुरुआती बातें

लागू करने की प्रोसेस शुरू करने से पहले, इन बातों का ध्यान रखें.

मेहमान मोड

सभी फ़ंक्शन के लिए पुष्टि करने की ज़रूरत नहीं है. इसके बजाय, उपयोगकर्ता को साइन इन करने के लिए कहे बिना, उसे ज़्यादा से ज़्यादा सुविधाएं दें.

ऐसा हो सकता है कि लोग, मोबाइल ऐप्लिकेशन का इस्तेमाल किए बिना ही आपके Wear ऐप्लिकेशन को ढूंढकर इंस्टॉल कर लें. इसलिए, उनके पास खाता नहीं होगा और उन्हें यह भी नहीं पता होगा कि इसमें कौनसी सुविधाएं मिलती हैं. पक्का करें कि मेहमान के तौर पर ऐप्लिकेशन इस्तेमाल करने की सुविधा से, आपके ऐप्लिकेशन की सुविधाओं के बारे में सटीक जानकारी मिलती हो.

ऐसा हो सकता है कि कुछ डिवाइस लंबे समय तक अनलॉक रहें

Wear OS 5 या इसके बाद के वर्शन पर काम करने वाले डिवाइसों पर, सिस्टम यह पता लगाता है कि उपयोगकर्ता ने डिवाइस को अपनी कलाई पर पहना है या नहीं. अगर उपयोगकर्ता, हाथ में डिवाइस होने का पता लगाने की सुविधा बंद कर देता है और फिर डिवाइस को अपने हाथ से हटा देता है, तो सिस्टम डिवाइस को ज़्यादा समय तक अनलॉक रखता है.

अगर आपके ऐप्लिकेशन को ज़्यादा सुरक्षा की ज़रूरत है, जैसे कि संभावित रूप से संवेदनशील या निजी डेटा दिखाते समय, तो पहले यह देखें कि कलाई का पता लगाने की सुविधा चालू है या नहीं:

fun isWristDetectionAutoLockingEnabled(context: Context): Boolean {
WristDetectionUtility.kt

अगर इस तरीके की दिखाई गई वैल्यू false है, तो उपयोगकर्ता को उससे जुड़ा कॉन्टेंट दिखाने से पहले, उसे अपने ऐप्लिकेशन में किसी खाते से साइन इन करने के लिए कहें.

Credential Manager

Wear OS पर पुष्टि करने के लिए, Credential Manager API इस्तेमाल करने का सुझाव दिया जाता है. इससे उपयोगकर्ताओं को Wear OS ऐप्लिकेशन में साइन इन करने के लिए ज़्यादा सुरक्षित प्लैटफ़ॉर्म मिलता है. इसके लिए, उन्हें किसी कनेक्ट किए गए फ़ोन की ज़रूरत नहीं होती. साथ ही, उन्हें अपना पासवर्ड याद रखने की भी ज़रूरत नहीं होती.

इस दस्तावेज़ में, डेवलपर को क्रेडेंशियल मैनेजर समाधान लागू करने के लिए ज़रूरी जानकारी दी गई है. साथ ही, इसमें पुष्टि करने के स्टैंडर्ड तरीके भी बताए गए हैं. ये तरीके हैं:

• पासकी
• पासवर्ड
• फ़ेडरेटेड आइडेंटिटी (जैसे, 'Google से साइन इन करें' सुविधा)

इस गाइड में, Credential Manager के बैकअप के तौर पर, Wear OS पर पुष्टि करने के अन्य तरीकों (डेटा लेयर टोकन शेयर करने की सुविधा और OAuth) को माइग्रेट करने के तरीके भी बताए गए हैं. साथ ही, इसमें Google से साइन इन करने के लिए इस्तेमाल किए जाने वाले बटन के स्टैंडअलोन वर्शन से, Credential Manager के एम्बेड किए गए वर्शन पर ट्रांज़िशन करने के बारे में खास निर्देश दिए गए हैं.

Wear OS की सीमाएं और अंतर

डेवलपर को Wear OS पर, इन सीमाओं और अंतरों के बारे में पता होना चाहिए:

• Credential Manager सिर्फ़ Wear OS 4 और इसके बाद के वर्शन पर उपलब्ध है.
• Wear OS पर क्रेडेंशियल नहीं बनाए जा सकते
• "क्रेडेंशियल वापस पाएं" और हाइब्रिड साइन-इन फ़्लो, दोनों काम नहीं करते.
• सिर्फ़ Wear OS इंटिग्रेशन वाले क्रेडेंशियल प्रोवाइडर को मोबाइल से फिर से इस्तेमाल किया जा सकता है.

Wear OS पर पासकी

डेवलपर को Wear OS के क्रेडेंशियल मैनेजर में पासकी लागू करने का सुझाव दिया जाता है. पासकी, असली उपयोगकर्ता की पुष्टि करने के लिए इंडस्ट्री का नया स्टैंडर्ड है. इससे उपयोगकर्ताओं को कई अहम फ़ायदे मिलते हैं.

पासकी का इस्तेमाल करना ज़्यादा आसान होता है

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

पासकी ज़्यादा सुरक्षित होती हैं

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

पासकी लागू करना

इसमें लागू करने के सभी तरीकों के लिए सेटअप और दिशा-निर्देश शामिल हैं.

सेटअप

1. अपने ऐप्लिकेशन मॉड्यूल की build.gradle फ़ाइल में, टारगेट एपीआई लेवल को 35 पर सेट करें:

   android {
       defaultConfig {
           targetSdkVersion(35)
       }
   }
   

2. अपने ऐप्लिकेशन या मॉड्यूल की build.gradle फ़ाइल में यहां दी गई लाइनें जोड़ें. इसके लिए, androidx.credentials रिलीज़ के रेफ़रंस से, सबसे नए स्टेबल वर्शन का इस्तेमाल करें.

   androidx.credentials:credentials:1.5.0
   androidx.credentials:credentials-play-services-auth:1.5.0
   

पुष्टि करने के लिए पहले से मौजूद तरीके

Credential Manager एक यूनिफ़ाइड एपीआई है. इसलिए, Wear OS के लिए इसे लागू करने का तरीका, किसी अन्य डिवाइस टाइप के लिए इसे लागू करने के तरीके जैसा ही है.

पासकी और पासवर्ड की सुविधा लागू करने के लिए, मोबाइल डिवाइस पर निर्देश का इस्तेमाल करें.

Credential Manager में 'Google से साइन इन करें' सुविधा जोड़ने का तरीका, मोबाइल डेवलपमेंट के लिए है. हालांकि, Wear OS पर भी यही तरीका इस्तेमाल किया जाता है.

ध्यान दें कि Wear OS पर क्रेडेंशियल नहीं बनाए जा सकते. इसलिए, आपको मोबाइल के निर्देशों में बताए गए क्रेडेंशियल बनाने के तरीकों को लागू करने की ज़रूरत नहीं है.

पुष्टि करने के बैकअप तरीके

Wear OS ऐप्लिकेशन के लिए, पुष्टि करने के दो अन्य तरीके भी इस्तेमाल किए जा सकते हैं: OAuth 2.0 (दोनों में से कोई भी वर्शन) और मोबाइल ऑथ टोकन डेटा लेयर शेयरिंग. इन तरीकों को Credential Manager API में इंटिग्रेट नहीं किया जा सकता. हालांकि, इन्हें Credential Manager के UX फ़्लो में फ़ॉलबैक के तौर पर शामिल किया जा सकता है. ऐसा तब किया जाता है, जब उपयोगकर्ता Credential Manager की स्क्रीन को खारिज कर देते हैं.

उपयोगकर्ता के क्रेडेंशियल मैनेजर स्क्रीन को खारिज करने की कार्रवाई को हैंडल करने के लिए, अपने GetCredential लॉजिक के हिस्से के तौर पर NoCredentialException को कैप्चर करें. इसके बाद, अपने कस्टम ऑथ यूज़र इंटरफ़ेस (यूआई) पर जाएं.

try {
    val getCredentialResponse: GetCredentialResponse =
        credentialManager.getCredential(activity, createGetCredentialRequest())
    return authenticate(getCredentialResponse.credential)
} catch (_: GetCredentialCancellationException) {
    navigateToSecondaryAuthentication()
}
CredentialManager.kt

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

डेटा लेयर टोकन शेयर करना

फ़ोन पर मौजूद साथी ऐप्लिकेशन, Wearable Data Layer API का इस्तेमाल करके, Wear OS ऐप्लिकेशन पर पुष्टि करने से जुड़ा डेटा सुरक्षित तरीके से ट्रांसफ़र कर सकता है. क्रेडेंशियल को मैसेज या डेटा आइटम के तौर पर ट्रांसफ़र करें.

इस तरह की पुष्टि के लिए, आम तौर पर उपयोगकर्ता को कुछ भी करने की ज़रूरत नहीं होती. हालांकि, उपयोगकर्ता को यह बताए बिना पुष्टि न करें कि उसे साइन इन किया जा रहा है. उपयोगकर्ता को खारिज की जा सकने वाली स्क्रीन का इस्तेमाल करके यह सूचना दी जा सकती है कि उसका खाता मोबाइल से ट्रांसफ़र किया जा रहा है.

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

मोबाइल ऐप्लिकेशन से डेटा लेयर का इस्तेमाल करके टोकन पास करें. इसके लिए, यहां दिया गया उदाहरण देखें:

val token = "..." // Auth token to transmit to the Wear OS device.
val putDataReq: PutDataRequest = PutDataMapRequest.create("/auth").run {
    dataMap.putString("token", token)
    asPutDataRequest()
}
val putDataTask: Task<DataItem> = Wearable.getDataClient(this).putDataItem(putDataReq)
DataLayerActivity.kt

Wear OS ऐप्लिकेशन पर डेटा में हुए बदलाव के इवेंट को मॉनिटर करने के लिए, यहां दिए गए उदाहरण का इस्तेमाल करें:

class AuthDataListenerService : WearableListenerService() {
    override fun onDataChanged(dataEvents: DataEventBuffer) {
        dataEvents.forEach { event ->
            if (event.type == DataEvent.TYPE_CHANGED) {
                val dataItemPath = event.dataItem.uri.path ?: ""

                if (dataItemPath.startsWith("/auth")) {
                    val token = DataMapItem.fromDataItem(event.dataItem)
                        .dataMap
                        .getString("token")
                    // Display an interstitial screen to notify the user that they're being signed
                    // in. Then, store the token and use it in network requests.
DataLayerService.kt

Wearable Data Layer का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, Wear OS पर डेटा भेजना और सिंक करना लेख पढ़ें.

OAuth 2.0 का इस्तेमाल करना

Wear OS, OAuth 2.0 पर आधारित दो फ़्लो के साथ काम करता है. इनके बारे में यहां बताया गया है:

• कोड एक्सचेंज के लिए पीकेसीई (प्रूफ़ की) के साथ ऑथराइज़ेशन कोड ग्रांट, जैसा कि आरएफ़सी 7636 में बताया गया है
• डिवाइस ऑथराइज़ेशन ग्रांट (डीएजी), जैसा कि आरएफ़सी 8628 में बताया गया है

कोड एक्सचेंज के लिए सबूत कुंजी (पीकेसीई)

PKCE का असरदार तरीके से इस्तेमाल करने के लिए, RemoteAuthClient का इस्तेमाल करें. इसके बाद, Wear OS ऐप्लिकेशन से OAuth सेवा देने वाली कंपनी को पुष्टि करने का अनुरोध करने के लिए, OAuthRequest ऑब्जेक्ट बनाएं. इस ऑब्जेक्ट में, टोकन पाने के लिए आपके OAuth एंडपॉइंट का यूआरएल और CodeChallenge ऑब्जेक्ट शामिल होता है.

नीचे दिए गए कोड में, पुष्टि करने का अनुरोध बनाने का उदाहरण दिखाया गया है:

val oauthRequest = OAuthRequest.Builder(context)
    .setAuthProviderUrl(uri)
    .setCodeChallenge(codeChallenge)
    .setClientId(CLIENT_ID)
    .build()
OAuthPKCE.kt

पुष्टि करने का अनुरोध बनाने के बाद, उसे sendAuthorizationRequest() तरीके का इस्तेमाल करके, साथी ऐप्लिकेशन को भेजें:

RemoteAuthClient.create(context).sendAuthorizationRequest(
    request = oauthRequest,
    executor = { command -> command?.run() },
    clientCallback = object : RemoteAuthClient.Callback() {
        override fun onAuthorizationResponse(
            request: OAuthRequest,
            response: OAuthResponse
        ) {
            // Extract the token from the response, store it, and use it in requests.
            continuation.resume(parseCodeFromResponse(response))
        }
        override fun onAuthorizationError(request: OAuthRequest, errorCode: Int) {
            // Handle Errors
            continuation.resume(Result.failure(IOException("Authorization failed")))
        }
    }
)
OAuthPKCE.kt

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

अनुमति मिलने या न मिलने के बाद, OAuth 2.0 सर्वर उस यूआरएल पर रीडायरेक्ट करता है जो अनुरोध में दिया गया है. अगर उपयोगकर्ता, ऐक्सेस के अनुरोध को स्वीकार करता है, तो जवाब में ऑथराइज़ेशन कोड शामिल होता है. अगर उपयोगकर्ता अनुरोध को स्वीकार नहीं करता है, तो जवाब में गड़बड़ी का मैसेज दिखता है.

जवाब, क्वेरी स्ट्रिंग के तौर पर होता है. यह इनमें से किसी एक उदाहरण की तरह दिखता है:

  https://wear.googleapis.com/3p_auth/com.your.package.name?code=xyz
  https://wear.googleapis-cn.com/3p_auth/com.your.package.name?code=xyz

इससे एक ऐसा पेज लोड होता है जो उपयोगकर्ता को कंपैनियन ऐप्लिकेशन पर ले जाता है. कंपैनियन ऐप्लिकेशन, जवाब वाले यूआरएल की पुष्टि करता है और onAuthorizationResponse एपीआई का इस्तेमाल करके, जवाब को आपके Wear OS ऐप्लिकेशन पर भेजता है.

इसके बाद, स्मार्टवॉच ऐप्लिकेशन, ऑथराइज़ेशन कोड को ऐक्सेस टोकन के लिए बदल सकता है.

डिवाइस को अनुमति देने की सुविधा

डिवाइस के लिए अनुमति देने की सुविधा का इस्तेमाल करते समय, उपयोगकर्ता किसी दूसरे डिवाइस पर पुष्टि करने वाला यूआरआई खोलता है. इसके बाद, ऑथराइज़ेशन सर्वर उनसे अनुरोध को स्वीकार या अस्वीकार करने के लिए कहता है.

इस प्रोसेस को आसान बनाने के लिए, RemoteActivityHelper का इस्तेमाल करके, उपयोगकर्ता के जोड़े गए मोबाइल डिवाइस पर वेब पेज खोलें. इसका तरीका यहां दिया गया है:

// Request access from the authorization server and receive Device Authorization Response.
private fun verifyDeviceAuthGrant(verificationUri: String) {
    RemoteActivityHelper(context).startRemoteActivity(
        Intent(Intent.ACTION_VIEW).apply {
            addCategory(Intent.CATEGORY_BROWSABLE)
            data = Uri.parse(verificationUri)
        },
        null
    )
}
OAuthDAG.kt

अगर आपके पास iOS ऐप्लिकेशन है, तो इस इंटेंट को अपने ऐप्लिकेशन में इंटरसेप्ट करने के लिए, यूनिवर्सल लिंक का इस्तेमाल करें. इसके बजाय, ब्राउज़र पर टोकन को अनुमति देने के लिए भरोसा न करें.