अपने उपयोगकर्ता को क्रेडेंशियल मैनेजर से साइन इन करें

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

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

इस पेज पर, पासकी के कॉन्सेप्ट के बारे में बताया गया है. साथ ही, Credential Manager API का इस्तेमाल करके, पासकी के साथ-साथ पुष्टि करने के अन्य समाधानों के लिए, क्लाइंट-साइड सपोर्ट लागू करने का तरीका बताया गया है. इसके अलावा, एक अलग अक्सर पूछे जाने वाले सवालों का पेज भी है. इस पेज पर, ज़्यादा जानकारी वाले और खास सवालों के जवाब दिए गए हैं.

पासकी की जानकारी

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

पासकी, WebAuthn (वेब ऑथेंटिकेशन) पर काम करती हैं. यह एक ऐसा स्टैंडर्ड है जिसे FIDO Alliance और World Wide Web Consortium (W3C) ने मिलकर बनाया है. WebAuthn, उपयोगकर्ता की पुष्टि करने के लिए सार्वजनिक पासकोड क्रिप्टोग्राफ़ी का इस्तेमाल करता है. जिस वेबसाइट या ऐप्लिकेशन में उपयोगकर्ता साइन इन कर रहा है वह सार्वजनिक पासकी को देख और सेव कर सकता है. हालांकि, वह निजी पासकी को कभी नहीं देख सकता. निजी कुंजी को गोपनीय और सुरक्षित रखा जाता है. पासकी यूनीक होती है और यह वेबसाइट या ऐप्लिकेशन से जुड़ी होती है. इसलिए, पासकी का इस्तेमाल करके फ़िशिंग नहीं की जा सकती. इससे सुरक्षा और बढ़ जाती है.

Credential Manager की मदद से, उपयोगकर्ता पासकी बना सकते हैं और उन्हें Google Password Manager में सेव कर सकते हैं.

क्रेडेंशियल मैनेजर की मदद से, पासकी की मदद से पुष्टि करने के फ़्लो को आसानी से लागू करने के बारे में जानने के लिए, पासकी की मदद से उपयोगकर्ता की पुष्टि करना लेख पढ़ें.

ज़रूरी शर्तें

Credential Manager का इस्तेमाल करने के लिए, इस सेक्शन में दिया गया तरीका अपनाएं.

प्लैटफ़ॉर्म के हाल ही के वर्शन का इस्तेमाल करना

Credential Manager, Android 4.4 (एपीआई लेवल 19) और इसके बाद के वर्शन पर काम करता है.

अपने ऐप्लिकेशन में डिपेंडेंसी जोड़ना

Credential Manager library के नए वर्शन का इस्तेमाल करने के लिए, अपने ऐप्लिकेशन मॉड्यूल की बिल्ड स्क्रिप्ट में ये डिपेंडेंसी जोड़ें:

Kotlin

dependencies {
    implementation("androidx.credentials:credentials:1.6.0-beta03")
    implementation("androidx.credentials:credentials-play-services-auth:1.6.0-beta03")
}

Groovy

dependencies {
    implementation "androidx.credentials:credentials:1.6.0-beta03"
    implementation "androidx.credentials:credentials-play-services-auth:1.6.0-beta03"
}

अपने ऐप्लिकेशन को छोटा करने, उसे अस्पष्ट करने, और ऑप्टिमाइज़ करने के बारे में ज़्यादा जानें.

डिजिटल ऐसेट लिंक के लिए सहायता जोड़ी गई

अपने Android ऐप्लिकेशन के लिए पासकी की सुविधा चालू करने के लिए, अपने ऐप्लिकेशन को उस वेबसाइट से जोड़ें जिसका मालिकाना हक आपके पास है. इस जुड़ाव के बारे में बताने के लिए, यह तरीका अपनाएं:

  1. डिजिटल ऐसेट लिंक की JSON फ़ाइल बनाएं. उदाहरण के लिए, यह एलान करने के लिए कि वेबसाइट https://signin.example.com और पैकेज के नाम com.example वाला Android ऐप्लिकेशन, साइन-इन क्रेडेंशियल शेयर कर सकते हैं, assetlinks.json नाम की एक फ़ाइल बनाएं. इसमें यह कॉन्टेंट शामिल करें:

    [
  {
    "relation" : [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target" : {
      "namespace" : "android_app",
      "package_name" : "com.example.android",
      "sha256_cert_fingerprints" : [
        SHA_HEX_VALUE
      ]
    }
  }
]

    relation फ़ील्ड, एक या उससे ज़्यादा स्ट्रिंग का कलेक्शन होता है. इसमें बताई गई स्ट्रिंग, एलान की गई रिलेशनशिप के बारे में जानकारी देती है. यह बताने के लिए कि ऐप्लिकेशन और साइटें, साइन-इन करने के क्रेडेंशियल शेयर करती हैं, उनके बीच के संबंध को delegate_permission/handle_all_urls और delegate_permission/common.get_login_creds के तौर पर तय करें.

    target फ़ील्ड एक ऑब्जेक्ट है. यह उस ऐसेट के बारे में बताता है जिस पर एलान लागू होता है. इन फ़ील्ड से किसी वेबसाइट की पहचान होती है:

    namespace web
    site

    वेबसाइट का यूआरएल, https://domain[:optional_port] फ़ॉर्मैट में होना चाहिए. उदाहरण के लिए, https://www.example.com.

    domain पूरी तरह से क्वालिफ़ाइड होना चाहिए. साथ ही, एचटीटीपीएस के लिए पोर्ट 443 का इस्तेमाल करते समय, optional_port को शामिल नहीं किया जाना चाहिए.

    site का टारगेट सिर्फ़ रूट डोमेन हो सकता है: किसी ऐप्लिकेशन को किसी खास सबडायरेक्ट्री से असोसिएट नहीं किया जा सकता. यूआरएल में पाथ शामिल न करें. जैसे, आखिर में स्लैश.

    सबडोमेन को मेल खाने वाला नहीं माना जाता. इसका मतलब है कि अगर आपने domain को www.example.com के तौर पर सेट किया है, तो डोमेन www.counter.example.com आपके ऐप्लिकेशन से नहीं जुड़ा होगा.

    इन फ़ील्ड से किसी Android ऐप्लिकेशन की पहचान होती है:

    namespace android_app
    package_name ऐप्लिकेशन के मेनिफ़ेस्ट में बताया गया पैकेज का नाम. उदाहरण के लिए, com.example.android
    sha256_cert_fingerprints आपके ऐप्लिकेशन के साइनिंग सर्टिफ़िकेट के SHA256 फ़िंगरप्रिंट.

  2. साइन-इन डोमेन पर, डिजिटल ऐसेट लिंक JSON फ़ाइल को यहां होस्ट करें:

    https://domain[:optional_port]/.well-known/assetlinks.json

    उदाहरण के लिए, अगर आपका साइन-इन डोमेन signin.example.com है, तो JSON फ़ाइल को https://signin.example.com/.well-known/assetlinks.json पर होस्ट करें.

    डिजिटल ऐसेट लिंक फ़ाइल का MIME टाइप JSON होना चाहिए. पुष्टि करें कि सर्वर, जवाब में Content-Type: application/json हेडर भेजता हो.

  3. पुष्टि करें कि आपका होस्ट, Google को डिजिटल ऐसेट लिंक फ़ाइल वापस पाने की अनुमति देता हो. अगर आपके पास robots.txt फ़ाइल है, तो Googlebot एजेंट को /.well-known/assetlinks.json फ़ेच करने की अनुमति होनी चाहिए. ज़्यादातर साइटें, किसी भी ऑटोमेटेड एजेंट को /.well-known/ पाथ में मौजूद फ़ाइलें वापस पाने की अनुमति दे सकती हैं. इससे अन्य सेवाएं, उन फ़ाइलों में मौजूद मेटाडेटा को ऐक्सेस कर सकती हैं:

    User-agent: *
Allow: /.well-known/

  4. <application> में जाकर, मेनिफ़ेस्ट फ़ाइल में यह लाइन जोड़ें:

    <meta-data android:name="asset_statements" android:resource="@string/asset_statements" />

  5. अगर क्रेडेंशियल मैनेजर के ज़रिए पासवर्ड से साइन-इन करने की सुविधा का इस्तेमाल किया जा रहा है, तो मेनिफ़ेस्ट में डिजिटल ऐसेट लिंकिंग को कॉन्फ़िगर करने के लिए, यह तरीका अपनाएं. अगर सिर्फ़ पासकी का इस्तेमाल किया जा रहा है, तो यह चरण ज़रूरी नहीं है.

    Android ऐप्लिकेशन में, असोसिएशन के बारे में बताएं. ऐसा ऑब्जेक्ट जोड़ें जो लोड की जाने वाली assetlinks.json फ़ाइलों के बारे में बताता हो. आपको स्ट्रिंग में इस्तेमाल किए गए सभी ऐपोस्ट्रॉफ़ी और उद्धरण चिह्नों को एस्केप करना होगा. उदाहरण के लिए:

    <string name="asset_statements" translatable="false">
[{
  \"include\": \"https://signin.example.com/.well-known/assetlinks.json\"
}]
</string>

    > GET /.well-known/assetlinks.json HTTP/1.1
> User-Agent: curl/7.35.0
> Host: signin.example.com

< HTTP/1.1 200 OK
< Content-Type: application/json

क्रेडेंशियल मैनेजर को कॉन्फ़िगर करना

CredentialManager ऑब्जेक्ट को कॉन्फ़िगर और शुरू करने के लिए, यहां दिए गए लॉजिक जैसा लॉजिक जोड़ें:

// Use your app or activity context to instantiate a client instance of
// CredentialManager.
private val credentialManager = CredentialManager.create(context)

क्रेडेंशियल फ़ील्ड के बारे में जानकारी देना

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

isCredential एट्रिब्यूट का इस्तेमाल करने के लिए, इसे काम के व्यू में जोड़ें:

<TextView
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:isCredential="true" />

उपयोगकर्ता के तौर पर साइन इन करना

उपयोगकर्ता के खाते से जुड़ी सभी पासकी और पासवर्ड के विकल्प वापस पाने के लिए, यह तरीका अपनाएं:

  1. पासवर्ड और पासकी की मदद से पुष्टि करने के विकल्पों को शुरू करें:

    // Get password logins from the credential provider on the user's device.
val getPasswordOption = GetPasswordOption()

// Get passkeys from the credential provider on the user's device.
val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
    requestJson = requestJson
)

  2. पिछले चरण से मिले विकल्पों का इस्तेमाल करके, साइन-इन करने का अनुरोध बनाएं.

    val credentialRequest = GetCredentialRequest(
    // Include all the sign-in options that your app supports.
    listOf(getPasswordOption, getPublicKeyCredentialOption),
    // Defines whether you prefer to use only immediately available
    // credentials or hybrid credentials.
    preferImmediatelyAvailableCredentials = preferImmediatelyAvailableCredentials
)

  3. साइन-इन फ़्लो लॉन्च करें:

    coroutineScope {
    try {
        result = credentialManager.getCredential(
            // Use an activity-based context to avoid undefined system UI
            // launching behavior.
            context = activityContext,
            request = credentialRequest
        )
        handleSignIn(result)
    } catch (e: GetCredentialException) {
        // Handle failure
    }
}
    
    fun handleSignIn(result: GetCredentialResponse) {
    // Handle the successfully returned credential.
    val credential = result.credential

    when (credential) {
        is PublicKeyCredential -> {
            val responseJson = credential.authenticationResponseJson
            // Share responseJson i.e. a GetCredentialResponse on your server to
            // validate and  authenticate
        }

        is PasswordCredential -> {
            val username = credential.id
            val password = credential.password
            // Use id and password to send to your server to validate
            // and authenticate
        }

        is CustomCredential -> {
            // If you are also using any external sign-in libraries, parse them
            // here with the utility functions provided.
            if (credential.type == ExampleCustomCredential.TYPE) {
                try {
                    val ExampleCustomCredential =
                        ExampleCustomCredential.createFrom(credential.data)
                    // Extract the required credentials and complete the authentication as per
                    // the federated sign in or any external sign in library flow
                } catch (e: ExampleCustomCredential.ExampleCustomCredentialParsingException) {
                    // Unlikely to happen. If it does, you likely need to update the dependency
                    // version of your external sign-in library.
                    Log.e(TAG, "Failed to parse an ExampleCustomCredential", e)
                }
            } else {
                // Catch any unrecognized custom credential type here.
                Log.e(TAG, "Unexpected type of credential")
            }
        }
        else -> {
            // Catch any unrecognized credential type here.
            Log.e(TAG, "Unexpected type of credential")
        }
    }
}

यहां दिए गए उदाहरण में, पासकी मिलने पर JSON अनुरोध को फ़ॉर्मैट करने का तरीका बताया गया है:

{
  "challenge": "T1xCsnxM2DNL2KdK5CLa6fMhD7OBqho6syzInk_n-Uo",
  "allowCredentials": [],
  "timeout": 1800000,
  "userVerification": "required",
  "rpId": "https://passkeys-codelab.glitch.me/"
}

नीचे दिए गए उदाहरण में दिखाया गया है कि सार्वजनिक पासकी मिलने के बाद, JSON रिस्पॉन्स कैसा दिख सकता है:

{
  "id": "<credential ID>",
  "type": "public-key",
  "rawId": "<raw credential ID>",
  "response": {
    "clientDataJSON": "<signed client data containing challenge>",
    "authenticatorData": "<authenticator metadata>",
    "signature": "<digital signature to be verified>",
    "userHandle": "<user ID from credential registration>"
  }
}

क्रेडेंशियल उपलब्ध न होने पर अपवादों को मैनेज करना

कुछ मामलों में, उपयोगकर्ता के पास कोई क्रेडेंशियल उपलब्ध नहीं हो सकता है या वह उपलब्ध क्रेडेंशियल का इस्तेमाल करने की सहमति नहीं दे सकता है. अगर getCredential() को शुरू किया जाता है और कोई क्रेडेंशियल नहीं मिलता है, तो NoCredentialException वापस कर दिया जाता है. ऐसा होने पर, आपके कोड को NoCredentialException उदाहरणों को मैनेज करना चाहिए.

coroutineScope {
    try {
        result = credentialManager.getCredential(
            context = activityContext,
            request = credentialRequest
        )
    } catch (e: GetCredentialException) {
        Log.e("CredentialManager", "No credential available", e)
    }
}

Android 14 या इसके बाद के वर्शन पर, खाता चुनने वाला टूल दिखाते समय लेटेन्सी कम की जा सकती है. इसके लिए, getCredential() को कॉल करने से पहले, prepareGetCredential() तरीके का इस्तेमाल करें.

coroutineScope {
    val response = credentialManager.prepareGetCredential(
        GetCredentialRequest(
            listOf(
                // Include all the sign-in options that your app supports
                getPublicKeyCredentialOption, 
                getPasswordOption
            )
        )
    )
}

prepareGetCredential() तरीके से यूज़र इंटरफ़ेस (यूआई) एलिमेंट को चालू नहीं किया जाता. यह सिर्फ़ तैयारी करने में आपकी मदद करता है, ताकि बाद में getCredential() एपीआई के ज़रिए, क्रेडेंशियल पाने की बाकी कार्रवाई (जिसमें यूज़र इंटरफ़ेस शामिल होते हैं) शुरू की जा सके.

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

रजिस्ट्रेशन फ़्लो

किसी उपयोगकर्ता को पुष्टि करने के लिए रजिस्टर किया जा सकता है. इसके लिए, पासकी या पासवर्ड का इस्तेमाल किया जा सकता है.

पासकी बनाना

उपयोगकर्ताओं को पासकी रजिस्टर करने और उसका इस्तेमाल दोबारा पुष्टि करने के लिए करने का विकल्प देने के लिए, CreatePublicKeyCredentialRequest ऑब्जेक्ट का इस्तेमाल करके उपयोगकर्ता क्रेडेंशियल रजिस्टर करें.

suspend fun createPasskey(requestJson: String, preferImmediatelyAvailableCredentials: Boolean) {
    var isConditional: Boolean = false
    val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
        // Contains the request in JSON format.
        requestJson = requestJson,
        // Defines whether you prefer to use only locally-available
        // credentials or hybrid credentials.
        preferImmediatelyAvailableCredentials = preferImmediatelyAvailableCredentials,
        // Automatically create a passkey if the user does not have one.
        isConditional = isConditional
    )

    // Execute createCredential asynchronously to register credentials
    // for a user account.
    coroutineScope {
        try {
            val result = credentialManager.createCredential(
                // Use an activity-based context to avoid undefined system
                // UI launching behavior
                context = activityContext,
                request = createPublicKeyCredentialRequest,
            )
            //  Handle passkey creation result
        } catch (e: CreateCredentialException) {
            handleFailure(e)
        }
    }
}

fun handleFailure(e: CreateCredentialException) {
    when (e) {
        is CreatePublicKeyCredentialDomException -> {
            // Handle the passkey DOM errors thrown according to the
            // WebAuthn spec.
        }
        is CreateCredentialCancellationException -> {
            // The user intentionally canceled the operation and chose not
            // to register the credential.
        }
        is CreateCredentialInterruptedException -> {
            // Retry-able error. Consider retrying the call.
        }
        is CreateCredentialProviderConfigurationException -> {
            // Your app is missing the provider configuration dependency.
            // Most likely, you're missing the
            // "credentials-play-services-auth" module.
        }
        is CreateCredentialCustomException -> {
            // You have encountered an error from a 3rd-party SDK. If you
            // make the API call with a request object that's a subclass of
            // CreateCustomCredentialRequest using a 3rd-party SDK, then you
            // should check for any custom exception type constants within
            // that SDK to match with e.type. Otherwise, drop or log the
            // exception.
        }
        else -> Log.w(TAG, "Unexpected exception type ${e::class.java.name}")
    }
}

JSON अनुरोध को फ़ॉर्मैट करना

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

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

{
  "challenge": "<base64url-encoded challenge>",
  "rp": {
    "name": "<relying party name>",
    "id": "<relying party host name>"
  },
  "user": {
    "id": "<base64url-encoded user ID>",
    "name": "<user name>",
    "displayName": "<user display name>"
  },
  "pubKeyCredParams": [
    {
      "type": "public-key",
      "alg": -7
    }
  ],
  "attestation": "none",
  "excludeCredentials": [
    {
        "id": "<base64url-encoded credential ID to exclude>", 
        "type": "public-key"
    }
  ],
  "authenticatorSelection": {
    "requireResidentKey": true,
    "residentKey": "required",
    "userVerification": "required"
  }
}

authenticatorAttachment के लिए वैल्यू सेट करना

authenticatorAttachment पैरामीटर को क्रेडेंशियल बनाते समय ही सेट किया जा सकता है. platform, cross-platform या कोई वैल्यू नहीं दी जा सकती. ज़्यादातर मामलों में, किसी वैल्यू का सुझाव नहीं दिया जाता.

  • platform: उपयोगकर्ता के मौजूदा डिवाइस को रजिस्टर करने या साइन इन करने के बाद, उपयोगकर्ता को पासकी पर अपग्रेड करने के लिए प्रॉम्प्ट करने के लिए, authenticatorAttachment को platform पर सेट करें.
  • cross-platform: इस वैल्यू का इस्तेमाल आम तौर पर, मल्टी-फ़ैक्टर क्रेडेंशियल रजिस्टर करते समय किया जाता है. इसका इस्तेमाल पासकी के संदर्भ में नहीं किया जाता.
  • कोई वैल्यू नहीं: उपयोगकर्ताओं को उनकी पसंद के डिवाइसों (जैसे, खाता सेटिंग में) पर पासकी बनाने की सुविधा देने के लिए, जब कोई उपयोगकर्ता पासकी जोड़ने का विकल्प चुनता है, तब authenticatorAttachment पैरामीटर को तय नहीं किया जाना चाहिए. ज़्यादातर मामलों में, पैरामीटर को तय न करना सबसे सही विकल्प होता है.

डुप्लीकेट पासकी बनने से रोकना

अगर एक ही पासकी सेवा देने वाली कंपनी की पासकी पहले से मौजूद है, तो नई पासकी बनने से रोकने के लिए, वैकल्पिक excludeCredentials ऐरे में क्रेडेंशियल आईडी की सूची बनाएं.

JSON रिस्पॉन्स को मैनेज करना

नीचे दिए गए कोड स्निपेट में, सार्वजनिक पासकोड क्रेडेंशियल बनाने के लिए JSON रिस्पॉन्स का उदाहरण दिखाया गया है. वापस किए गए सार्वजनिक पासकी क्रेडेंशियल को मैनेज करने के तरीके के बारे में ज़्यादा जानें.

{
  "id": "<identifier>",
  "type": "public-key",
  "rawId": "<identifier>",
  "response": {
    "clientDataJSON": "<ArrayBuffer encoded object with the origin and signed challenge>",
    "attestationObject": "<ArrayBuffer encoded object with the public key and other information.>"
  },
  "authenticatorAttachment": "platform"
}

क्लाइंट डेटा JSON से ऑरिजिन की पुष्टि करना

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

वेब के मामले में, origin उसी साइट के ऑरिजिन को दिखाता है जहां क्रेडेंशियल से साइन इन किया गया था. उदाहरण के लिए, अगर यूआरएल https://www.example.com:8443/store?category=shoes#athletic है , तो origin https://www.example.com:8443 है.

Android ऐप्लिकेशन के लिए, उपयोगकर्ता एजेंट अपने-आप origin को कॉलिंग ऐप्लिकेशन के हस्ताक्षर पर सेट करता है. इस हस्ताक्षर की पुष्टि आपके सर्वर पर की जानी चाहिए, ताकि यह पता चल सके कि यह हस्ताक्षर मेल खाता है. इससे पासकी एपीआई को कॉल करने वाले की पुष्टि की जा सकेगी. Android origin, APK पर हस्ताक्षर करने वाले सर्टिफ़िकेट के SHA-256 हैश से मिला URI है. जैसे:

android:apk-key-hash:<sha256_hash-of-apk-signing-cert>

किसी कीस्टोर के साइनिंग सर्टिफ़िकेट के SHA-256 हैश पाने के लिए, टर्मिनल में यह कमांड चलाएं:

keytool -list -keystore <path-to-apk-signing-keystore>

SHA-256 हैश, कोलन से अलग किए गए हेक्साडेसिमल फ़ॉर्मैट (91:F7:CB:F9:D6:81…) में होते हैं. साथ ही, Android origin वैल्यू, base64url-encoded होती हैं. इस Python उदाहरण में, हैश फ़ॉर्मैट को कोलन से अलग किए गए, काम करने वाले हैक्साडेसिमल फ़ॉर्मैट में बदलने का तरीका बताया गया है:

import binascii
import base64
fingerprint = '91:F7:CB:F9:D6:81:53:1B:C7:A5:8F:B8:33:CC:A1:4D:AB:ED:E5:09:C5'
print("android:apk-key-hash:" + base64.urlsafe_b64encode(binascii.a2b_hex(fingerprint.replace(':', ''))).decode('utf8').replace('=', ''))

fingerprint की वैल्यू को अपनी वैल्यू से बदलें. यहां नतीजे का एक उदाहरण दिया गया है:

android:apk-key-hash:kffL-daBUxvHpY-4M8yhTavt5QnFEI2LsexohxrGPYU

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

किसी उपयोगकर्ता का पासवर्ड सेव करना

अगर उपयोगकर्ता आपके ऐप्लिकेशन में पुष्टि करने के लिए, उपयोगकर्ता नाम और पासवर्ड देता है, तो उपयोगकर्ता के क्रेडेंशियल रजिस्टर किए जा सकते हैं. इनका इस्तेमाल उपयोगकर्ता की पुष्टि करने के लिए किया जा सकता है. इसके लिए, CreatePasswordRequest ऑब्जेक्ट बनाएं:

suspend fun registerPassword(username: String, password: String) {
    // Initialize a CreatePasswordRequest object.
    val createPasswordRequest =
        CreatePasswordRequest(id = username, password = password)

    // Create credential and handle result.
    coroutineScope {
        try {
            val result =
                credentialManager.createCredential(
                    // Use an activity based context to avoid undefined
                    // system UI launching behavior.
                    activityContext,
                    createPasswordRequest
                )
            // Handle register password result
        } catch (e: CreateCredentialException) {
            handleFailure(e)
        }
    }
}

क्रेडेंशियल वापस पाने की सुविधा

अगर किसी व्यक्ति के पास उस डिवाइस का ऐक्सेस नहीं है जिस पर उसने अपने क्रेडेंशियल सेव किए थे, तो उसे सुरक्षित ऑनलाइन बैकअप से क्रेडेंशियल वापस लाने पड़ सकते हैं. क्रेडेंशियल रिकवर करने की इस प्रोसेस के बारे में ज़्यादा जानने के लिए, इस ब्लॉग पोस्ट में "ऐक्सेस रिकवर करना या नए डिवाइस जोड़ना" सेक्शन पढ़ें: Google Password Manager में पासकी की सुरक्षा.

उपयोगकर्ताओं के लिए पासकी अपने-आप जनरेट होने की सुविधा

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

CreatePublicKeyCredentialRequest(
    // other parameters
    isConditionalCreateRequest: Boolean = true
)

जब उपयोगकर्ता साइन इन करता है, तो पासकी अपने-आप बन जाती है. साथ ही, यह उपयोगकर्ता के चुने गए Password Manager में सेव हो जाती है. Google Password Manager का इस्तेमाल करने वाले व्यक्ति को, पासवर्ड मैनेजर में सेव किए गए पासवर्ड का इस्तेमाल करना होगा. इसके लिए, वह क्रेडेंशियल मैनेजर या ऑटोमैटिक भरने की सुविधा का इस्तेमाल कर सकता है. पासकी बनाने पर, उपयोगकर्ता को इसकी सूचना मिलती है. साथ ही, वह इसे मैनेज करने के लिए Password Manager पर जा सकता है.

इस सुविधा के लिए, 1.6.0-alpha01 या इसके बाद का वर्शन ज़रूरी है.

पासकी एंडपॉइंट के जाने-माने यूआरएल के साथ, पासवर्ड मैनेज करने वाले टूल के लिए सहायता जोड़ें

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

  1. https://example.com पर मौजूद किसी रिलाइंग पार्टी के लिए, जिसका वेबसाइट के साथ-साथ Android और iOS ऐप्लिकेशन भी है, वेल-नोन यूआरएल https://example.com/.well-known/passkey-endpoints होगा.

  2. यूआरएल के बारे में क्वेरी किए जाने पर, जवाब में इस स्कीमा का इस्तेमाल किया जाना चाहिए

    {
  "enroll": "https://example.com/account/manage/passkeys/create"
  "manage": "https://example.com/account/manage/passkeys"
}

  3. अगर आपको इस लिंक को वेब पर खोलने के बजाय सीधे अपने ऐप्लिकेशन में खोलना है, तो Android ऐप्लिकेशन लिंक का इस्तेमाल करें.

  4. ज़्यादा जानकारी के लिए, GitHub पर पासकी एंडपॉइंट के जाने-माने यूआरएल के बारे में जानकारी देने वाला लेख पढ़ें.

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

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

उदाहरण के लिए, अगर कोई उपयोगकर्ता Google Password Manager का इस्तेमाल करके, Android डिवाइस पर पासकी बनाता है, तो आरपी को एक AAGUID मिलता है. यह कुछ इस तरह दिखता है: "ea9b8d66-4d01-1d21-3ce4-b6b48cb575d4". रिलाइंग पार्टी, पासकी की सूची में पासकी को एनोटेट कर सकती है. इससे यह पता चलता है कि इसे Google Password Manager का इस्तेमाल करके बनाया गया था.

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

AAGUID इंटिग्रेशन के बारे में ज़्यादा जानें.

सामान्य गड़बड़ियां ठीक करना

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

अन्य संसाधन

Credential Manager API और पासकी के बारे में ज़्यादा जानने के लिए, यहां दिए गए संसाधन देखें: