पासकी सेट करें

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

पासकी बनाने के लिए, अपने ऐप्लिकेशन सर्वर से पासकी बनाने के लिए ज़रूरी जानकारी पाएं. इसके बाद, Credential Manager API को कॉल करें. यह एपीआई, सार्वजनिक और निजी पासकोड का एक जोड़ा दिखाता है. लौटाई गई निजी कुंजी को क्रेडेंशियल प्रोवाइडर, जैसे कि Google Password Manager में पासकी के तौर पर सेव किया जाता है. सार्वजनिक पासकोड, आपके ऐप्लिकेशन सर्वर पर सेव होता है.

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

पक्का करें कि आपने Digital Asset Links सेट अप किए हों. साथ ही, आपने Android 9 (एपीआई लेवल 28) या उसके बाद के वर्शन वाले डिवाइसों को टारगेट किया हो.

खास जानकारी

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

1. अपने ऐप्लिकेशन में डिपेंडेंसी जोड़ें: Credential Manager की ज़रूरी लाइब्रेरी जोड़ें.
2. Credential Manager को इंस्टैंशिएट करना: Credential Manager का इंस्टेंस बनाएं.
3. ऐप्लिकेशन सर्वर से क्रेडेंशियल बनाने के विकल्प पाना: अपने ऐप्लिकेशन सर्वर से, क्लाइंट ऐप्लिकेशन को पासकी बनाने के लिए ज़रूरी जानकारी भेजें. जैसे, ऐप्लिकेशन और उपयोगकर्ता के बारे में जानकारी, challenge, और अन्य फ़ील्ड.
4. पासकी का अनुरोध करना: अपने ऐप्लिकेशन में, ऐप्लिकेशन सर्वर से मिली जानकारी का इस्तेमाल करके GetPublicKeyCredentialOption ऑब्जेक्ट बनाएं. इसके बाद, इस ऑब्जेक्ट का इस्तेमाल करके credentialManager.getCredential() तरीके को लागू करें, ताकि पासकी बनाई जा सके.
5. पासकी बनाने के अनुरोध के जवाब को मैनेज करना: जब आपको अपने क्लाइंट ऐप्लिकेशन पर क्रेडेंशियल मिलते हैं, तब आपको सार्वजनिक पासकोड को एन्कोड और क्रमबद्ध करना होगा. इसके बाद, उसे ऐप्लिकेशन सर्वर पर भेजना होगा. आपको पासकी बनाने के दौरान होने वाली हर गड़बड़ी को भी ठीक करना होगा.
6. सर्वर पर सार्वजनिक कुंजी की पुष्टि करें और उसे सेव करें: सर्वर-साइड पर दिए गए चरणों को पूरा करके, क्रेडेंशियल के ऑरिजिन की पुष्टि करें. इसके बाद, सार्वजनिक कुंजी को सेव करें.
7. उपयोगकर्ता को सूचना दें: उपयोगकर्ता को सूचना दें कि उसकी पासकी बन गई है.

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

अपने ऐप्लिकेशन मॉड्यूल की build.gradle फ़ाइल में, ये डिपेंडेंसी जोड़ें:

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

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

2. क्रेडेंशियल मैनेजर को इंस्टैंशिएट करना

CredentialManager ऑब्जेक्ट बनाने के लिए, अपने ऐप्लिकेशन या गतिविधि के कॉन्टेक्स्ट का इस्तेमाल करें.

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

3. अपने ऐप्लिकेशन सर्वर से क्रेडेंशियल बनाने के विकल्प पाना

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

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

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

यहां दिए गए स्निपेट में, ऐप्लिकेशन सर्वर से भेजे गए सार्वजनिक पासकोड बनाने के विकल्पों का स्ट्रक्चर दिखाया गया है:

{
  "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"
  }
}

सार्वजनिक पासकोड बनाने के विकल्पों में ये मुख्य फ़ील्ड शामिल हैं:

• challenge: सर्वर से जनरेट की गई रैंडम स्ट्रिंग. इसका इस्तेमाल रीप्ले अटैक को रोकने के लिए किया जाता है.
• rp: ऐप्लिकेशन के बारे में जानकारी.
  • rp.name: ऐप्लिकेशन का नाम.
  • rp.id: ऐप्लिकेशन का डोमेन या सबडोमेन.
• user: उपयोगकर्ता के बारे में जानकारी.
  • id: उपयोगकर्ता का यूनीक आईडी. इस वैल्यू में, व्यक्तिगत पहचान से जुड़ी जानकारी शामिल नहीं होनी चाहिए. उदाहरण के लिए, ईमेल पते या उपयोगकर्ता नाम. आपके पास 16 बाइट की कोई भी रैंडम वैल्यू इस्तेमाल करने का विकल्प होता है.
  • name: खाते के लिए यूनीक आइडेंटिफ़ायर, जिसे उपयोगकर्ता पहचान पाएगा. जैसे, उसका ईमेल पता या उपयोगकर्ता नाम. यह खाता चुनने वाले टूल में दिखेगा. अगर उपयोगकर्ता नाम का इस्तेमाल किया जा रहा है, तो वही वैल्यू इस्तेमाल करें जो पासवर्ड की पुष्टि करने के लिए इस्तेमाल की गई थी.
  • displayName: यह खाते का ऐसा नाम होता है जिसे उपयोगकर्ता आसानी से समझ सकता है. यह नाम, खाता चुनने वाले टूल में दिखता है.

• authenticatorSelection: उस डिवाइस के बारे में जानकारी जिसका इस्तेमाल पुष्टि के लिए किया जाएगा.

  • authenticatorAttachment: इससे पसंदीदा Authenticator के बारे में पता चलता है. ये वैल्यू इस्तेमाल की जा सकती हैं: - platform: इस वैल्यू का इस्तेमाल, उपयोगकर्ता के डिवाइस में पहले से मौजूद पुष्टि करने वाले ऐप्लिकेशन के लिए किया जाता है. जैसे, फ़िंगरप्रिंट सेंसर. - cross-platform: इस वैल्यू का इस्तेमाल, रोमिंग डिवाइसों के लिए किया जाता है. जैसे, सुरक्षा कुंजियां. आम तौर पर, इसका इस्तेमाल पासकी के संदर्भ में नहीं किया जाता. - ब्यौरा नहीं दिया गया (सुझाया गया): इस वैल्यू का ब्यौरा न देने पर, उपयोगकर्ताओं को अपनी पसंद के डिवाइसों पर पासकी बनाने की सुविधा मिलती है. ज़्यादातर मामलों में, पैरामीटर को अनस्पेसिफ़ाइड के तौर पर छोड़ना सबसे अच्छा विकल्प होता है.
    • requireResidentKey: पासकी बनाने के लिए, इस Boolean फ़ील्ड की वैल्यू को true पर सेट करें.
    • residentKey: पासकी बनाने के लिए, वैल्यू को required पर सेट करें.
    • userVerification: इसका इस्तेमाल, पासकी रजिस्टर करने के दौरान उपयोगकर्ता की पुष्टि करने से जुड़ी ज़रूरी शर्तों के बारे में बताने के लिए किया जाता है. इसकी ये वैल्यू हो सकती हैं: - preferred: इस वैल्यू का इस्तेमाल तब करें, जब आपको सुरक्षा के मुकाबले उपयोगकर्ता अनुभव को प्राथमिकता देनी हो. जैसे, ऐसे एनवायरमेंट में जहां उपयोगकर्ता की पुष्टि करने से सुरक्षा के मुकाबले ज़्यादा परेशानी होती है. - required: अगर डिवाइस पर उपलब्ध उपयोगकर्ता की पुष्टि करने का कोई तरीका शुरू करना है, तो इस वैल्यू का इस्तेमाल करें. - discouraged: अगर उपयोगकर्ता की पुष्टि करने के तरीके का इस्तेमाल करने का सुझाव नहीं दिया जाता है, तो इस वैल्यू का इस्तेमाल करें.
      के बारे में ज़्यादा जानने के लिए, userVerification देखें. उपयोगकर्ता की पुष्टि के बारे में ज़्यादा जानकारी देखें.

• excludeCredentials: क्रेडेंशियल आईडी को ऐरे में शामिल करें, ताकि एक ही क्रेडेंशियल प्रोवाइडर के साथ पहले से मौजूद पासकी की डुप्लीकेट पासकी न बनाई जा सके.

4. पासकी का अनुरोध करना

सर्वर-साइड पर सार्वजनिक पासकोड बनाने के विकल्पों को पार्स करने के बाद, इन विकल्पों को CreatePublicKeyCredentialRequest ऑब्जेक्ट में रैप करके और createCredential() को कॉल करके, पासकी बनाएं.

createPublicKeyCredentialRequest में ये शामिल हैं:

• requestJson: ऐप्लिकेशन सर्वर से भेजे गए क्रेडेंशियल बनाने के विकल्प.
• preferImmediatelyAvailableCredentials: यह एक वैकल्पिक बूलियन फ़ील्ड है. यह तय करता है कि अनुरोध को पूरा करने के लिए, सिर्फ़ स्थानीय तौर पर उपलब्ध या क्रेडेंशियल सेवा देने वाली कंपनी के साथ सिंक किए गए क्रेडेंशियल का इस्तेमाल करना है. इसके बजाय, सुरक्षा कुंजियों या हाइब्रिड कुंजी फ़्लो से मिले क्रेडेंशियल का इस्तेमाल करना है. इसका इस्तेमाल इन तरीकों से किया जा सकता है:
  • false (डिफ़ॉल्ट): अगर क्रेडेंशियल मैनेजर को कॉल करने की सुविधा, उपयोगकर्ता की किसी कार्रवाई से ट्रिगर हुई है, तो इस वैल्यू का इस्तेमाल करें.
  • true: इस वैल्यू का इस्तेमाल तब करें, जब Credential Manager को किसी अवसर पर कॉल किया गया हो. जैसे, पहली बार ऐप्लिकेशन खोलने पर.
    अगर आपने वैल्यू को true पर सेट किया है और तुरंत उपलब्ध होने वाले क्रेडेंशियल नहीं हैं, तो Credential Manager कोई यूज़र इंटरफ़ेस (यूआई) नहीं दिखाएगा. साथ ही, अनुरोध तुरंत पूरा नहीं होगा. इसके अलावा, get अनुरोधों के लिए NoCredentialException और create अनुरोधों के लिए CreateCredentialNoCreateOptionException दिखेगा.
• origin: यह फ़ील्ड, Android ऐप्लिकेशन के लिए अपने-आप सेट हो जाता है. ब्राउज़र और इसी तरह के खास अधिकार वाले ऐप्लिकेशन के लिए, origin सेट करने की ज़रूरत होती है. इसके लिए, खास अधिकार वाले ऐप्लिकेशन के लिए, अन्य पक्षों की ओर से Credential Manager कॉल करना लेख पढ़ें.
• isConditional: यह एक ऐसा फ़ील्ड है जिसकी वैल्यू देना ज़रूरी नहीं है. इसकी डिफ़ॉल्ट वैल्यू false होती है. इसे true पर सेट करने पर, अगर किसी उपयोगकर्ता के पास पासकी नहीं है, तो अगली बार सेव किए गए पासवर्ड से साइन इन करने पर, हम उसके लिए अपने-आप एक पासकी बना देते हैं. पासकी, उपयोगकर्ता के क्रेडेंशियल प्रोवाइडर में सेव की जाती है. शर्त के हिसाब से क्रिएट करने की सुविधा के लिए, androidx.credentials का नया वर्शन होना ज़रूरी है.

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

5. जवाब मैनेज करना

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

createCredential() को कॉल करने के बाद, आपको PublicKeyCredential ऑब्जेक्ट मिलता है.

PublicKeyCredential ऐसा दिखता है:

{
  "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"
}

क्लाइंट ऐप्लिकेशन में, ऑब्जेक्ट को क्रम से लगाएं और उसे ऐप्लिकेशन सर्वर पर भेजें.

नीचे दिए गए स्निपेट में दिखाए गए तरीके से, फ़ेल होने की स्थितियों को मैनेज करने के लिए कोड जोड़ें:

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}")
    }
}

6. ऐप्लिकेशन सर्वर पर सार्वजनिक पासकोड की पुष्टि करना और उसे सेव करना

ऐप्लिकेशन सर्वर पर, आपको सार्वजनिक पासकोड क्रेडेंशियल की पुष्टि करनी होगी. इसके बाद, सार्वजनिक पासकोड सेव करें.

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

ऐप्लिकेशन का SHA 256 फ़िंगरप्रिंट पाने के लिए:

1. टर्मिनल में यह कमांड चलाकर, रिलीज़ किए जाने वाले ऐप्लिकेशन के हस्ताक्षर करने वाले सर्टिफ़िकेट को प्रिंट करें:

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

   जवाब में, साइनिंग सर्टिफ़िकेट के SHA 256 फ़िंगरप्रिंट की पहचान करें. इसे Certificate fingerprints block : SHA256 के तौर पर दिखाया गया है.

2. SHA256 फ़िंगरप्रिंट को base64url कोड में बदलें. इस Python उदाहरण में, फ़िंगरप्रिंट को सही तरीके से एन्कोड करने का तरीका बताया गया है:

   import binascii
   import base64
   fingerprint = '<SHA256 finerprint>' # your app's SHA256 fingerprint
   print(base64.urlsafe_b64encode(binascii.a2b_hex(fingerprint.replace(':', ''))).decode('utf8').replace('=', ''))
   

3. पिछले चरण के आउटपुट की शुरुआत में android:apk-key-hash: जोड़ें, ताकि आपको कुछ ऐसा मिले:

   android:apk-key-hash:<encoded SHA 256 fingerprint>
   

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

7. उपयोगकर्ता को सूचना देना

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

उपयोगकर्ता अनुभव को बेहतर बनाना

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

नए डिवाइस पर क्रेडेंशियल वापस लाने की सुविधा जोड़ी गई

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

क्रेडेंशियल फ़ील्ड में ऑटोमैटिक तरीके से भरने की सुविधा बंद करें (ज़रूरी नहीं)

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

isCredential एट्रिब्यूट, Android 14 और इसके बाद के वर्शन पर काम करता है.

यहां दिए गए उदाहरण में बताया गया है कि अपने ऐप्लिकेशन के लिए, काम के उपयोगकर्ता नाम और पासवर्ड फ़ील्ड में isCredential एट्रिब्यूट कैसे जोड़ा जा सकता है:

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

अगले चरण

• पासकी से साइन इन करना
• पासकी मैनेज करना
• पासकी के उपयोगकर्ता अनुभव के फ़्लो को समझना