उपयोगकर्ताओं के पासकी से पुष्टि करने से पहले, यह ज़रूरी है कि आपका ऐप्लिकेशन उनके खाते के लिए पासकी रजिस्टर करे या बनाए.
पासकी बनाने के लिए, अपने ऐप्लिकेशन सर्वर से पासकी बनाने के लिए ज़रूरी जानकारी हासिल करें. इसके बाद, क्रेडेंशियल मैनेजर एपीआई को कॉल करें. यह एपीआई, सार्वजनिक और निजी कुंजी का पेयर दिखाता है. दिखाई गई निजी कुंजी, क्रेडेंशियल प्रोवाइडर में पासकी के तौर पर सेव की जाती है. जैसे, Google Password Manager. सार्वजनिक कुंजी, आपके ऐप्लिकेशन सर्वर पर सेव की जाती है.
ज़रूरी शर्तें
पक्का करें कि आपने डिजिटल ऐसेट लिंक सेट अप किए हों और Android 9 (एपीआई लेवल 28) या इसके बाद के वर्शन वाले डिवाइसों को टारगेट किया हो.
खास जानकारी
इस गाइड में, पासकी बनाने के लिए, रिलाइंग पार्टी क्लाइंट ऐप्लिकेशन में किए जाने वाले ज़रूरी बदलावों के बारे में बताया गया है. साथ ही, इसमें रिलाइंग पार्टी ऐप्लिकेशन सर्वर को लागू करने की खास जानकारी भी दी गई है. सर्वर-साइड इंटिग्रेशन के बारे में ज़्यादा जानने के लिए, सर्वर-साइड पासकी रजिस्ट्रेशन लेख पढ़ें.
- अपने ऐप्लिकेशन में डिपेंडेंसी जोड़ना: ज़रूरी क्रेडेंशियल मैनेजर लाइब्रेरी जोड़ें.
- क्रेडेंशियल मैनेजर को इंस्टैंशिएट करना: क्रेडेंशियल मैनेजर का इंस्टेंस बनाएं.
- ऐप्लिकेशन सर्वर से क्रेडेंशियल बनाने के विकल्प पाना: अपने ऐप्लिकेशन
सर्वर से, क्लाइंट ऐप्लिकेशन को पासकी बनाने के लिए ज़रूरी जानकारी भेजें. जैसे,
ऐप्लिकेशन और उपयोगकर्ता के बारे में जानकारी. साथ ही,
challengeऔर अन्य फ़ील्ड. - पासकी का अनुरोध करना: अपने ऐप्लिकेशन में,
ऐप्लिकेशन सर्वर से मिली जानकारी का इस्तेमाल करके,
GetPublicKeyCredentialOptionऑब्जेक्ट बनाएं. इसके बाद, पासकी बनाने के लिए, इस ऑब्जेक्ट का इस्तेमाल करकेcredentialManager.getCredential()तरीके को लागू करें. - पासकी बनाने के जवाब को मैनेज करना: जब आपको अपने क्लाइंट ऐप्लिकेशन पर क्रेडेंशियल मिलते हैं, तो आपको सार्वजनिक कुंजी को कोड में बदलना, क्रम से लगाना, और फिर ऐप्लिकेशन सर्वर पर भेजना होगा. पासकी बनाने के दौरान होने वाले हर अपवाद को भी मैनेज करना होगा.
- सर्वर पर सार्वजनिक कुंजी की पुष्टि करना और उसे सेव करना: क्रेडेंशियल के सोर्स की पुष्टि करने के लिए, सर्वर-साइड के चरण पूरे करें. इसके बाद, सार्वजनिक कुंजी को सेव करें.
- उपयोगकर्ता को सूचना देना: उपयोगकर्ता को सूचना दें कि उसकी पासकी बन गई है.
अपने ऐप्लिकेशन में डिपेंडेंसी जोड़ना
अपने ऐप्लिकेशन मॉड्यूल की build.gradle फ़ाइल में, ये डिपेंडेंसी जोड़ें:
Kotlin
dependencies { implementation("androidx.credentials:credentials:1.7.0-alpha02") implementation("androidx.credentials:credentials-play-services-auth:1.7.0-alpha02") }
Groovy
dependencies { implementation "androidx.credentials:credentials:1.7.0-alpha02" implementation "androidx.credentials:credentials-play-services-auth:1.7.0-alpha02" }
UnsupportedOperationException("Post-U not supported yet") अपवाद दिखाते हैं.
क्रेडेंशियल मैनेजर को इंस्टैंशिएट करना
CredentialManager ऑब्जेक्ट बनाने के लिए, अपने ऐप्लिकेशन या गतिविधि के कॉन्टेक्स्ट का इस्तेमाल करें.
// Use your app or activity context to instantiate a client instance of
// CredentialManager.
private val credentialManager = CredentialManager.create(context)
अपने ऐप्लिकेशन सर्वर से क्रेडेंशियल बनाने के विकल्प पाना
जब उपयोगकर्ता "पासकी बनाएं" बटन पर क्लिक करता है या जब कोई नया उपयोगकर्ता साइन अप करता है, तो पासकी रजिस्ट्रेशन की प्रोसेस शुरू करने के लिए ज़रूरी जानकारी पाने के लिए, अपने ऐप्लिकेशन से ऐप्लिकेशन सर्वर पर अनुरोध करें.
अपने क्लाइंट ऐप्लिकेशन को पासकी बनाने के लिए ज़रूरी जानकारी भेजने के लिए, अपने ऐप्लिकेशन सर्वर में 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: पसंदीदा ऑथेंटिकेटर के बारे में बताता है. इसकी ये वैल्यू हो सकती हैं:platform: इस वैल्यू का इस्तेमाल, उपयोगकर्ता के डिवाइस में बने ऑथेंटिकेटर के लिए किया जाता है. जैसे, फ़िंगरप्रिंट सेंसर.cross-platform: इस वैल्यू का इस्तेमाल, रोमिंग डिवाइसों के लिए किया जाता है. जैसे, सुरक्षा कुंजियां. आम तौर पर, इसका इस्तेमाल पासकी के संदर्भ में नहीं किया जाता.- कोई वैल्यू तय नहीं की गई (सुझाया जाता है): इस वैल्यू को तय न करने पर, उपयोगकर्ताओं को अपनी पसंद के डिवाइसों पर पासकी बनाने की सुविधा मिलती है. ज़्यादातर मामलों में, पैरामीटर के लिए कोई वैल्यू तय न करना सबसे अच्छा विकल्प होता है.
requireResidentKey: पासकी बनाने के लिए, इसBooleanफ़ील्ड की वैल्यू कोtrueपर सेट करें.residentKey: पासकी बनाने के लिए, वैल्यू कोrequiredपर सेट करें.userVerification: पासकी रजिस्ट्रेशन के दौरान, उपयोगकर्ता की पुष्टि करने के लिए ज़रूरी शर्तें तय करने के लिए इसका इस्तेमाल किया जाता है. इसकी ये वैल्यू हो सकती हैं:preferred: अगर सुरक्षा के मुकाबले उपयोगकर्ता अनुभव को प्राथमिकता देनी है, तो इस वैल्यू का इस्तेमाल करें. जैसे, उन एनवायरमेंट में जहां उपयोगकर्ता की पुष्टि करने से सुरक्षा के मुकाबले ज़्यादा समस्याएं होती हैं.required: अगर डिवाइस पर उपलब्ध उपयोगकर्ता की पुष्टि का तरीका लागू करना ज़रूरी है, तो इस वैल्यू का इस्तेमाल करें.discouraged: अगर उपयोगकर्ता की पुष्टि करने के किसी तरीके का इस्तेमाल करने से बचना है, तो इस वैल्यू का इस्तेमाल करें.
के बारे में ज़्यादा जानने के लिए,userVerificationदेखें userVerification डीप डाइव लेख.
excludeCredentials: अगर एक ही क्रेडेंशियल प्रोवाइडर के साथ पहले से कोई पासकी मौजूद है, तो डुप्लीकेट पासकी बनने से रोकने के लिए, क्रेडेंशियल आईडी को किसी कलेक्शन में शामिल करें.
पासकी बनाना
सर्वर-साइड सार्वजनिक कुंजी बनाने के विकल्पों को पार्स करने के बाद, इन विकल्पों को CreatePublicKeyCredentialRequest ऑब्जेक्ट में रैप करके और createCredential() को कॉल करके पासकी बनाएं.
createPublicKeyCredentialRequest में ये चीज़ें शामिल होती हैं:
requestJson: ऐप्लिकेशन सर्वर से भेजे गए क्रेडेंशियल बनाने के विकल्प.preferImmediatelyAvailableCredentials: यह एक वैकल्पिक बूलियन फ़ील्ड है . इससे यह तय होता है कि अनुरोध पूरा करने के लिए, सुरक्षा कुंजियों या हाइब्रिड कुंजी फ़्लो के क्रेडेंशियल के बजाय, सिर्फ़ स्थानीय तौर पर उपलब्ध या क्रेडेंशियल प्रोवाइडर के साथ सिंक किए गए क्रेडेंशियल का इस्तेमाल किया जाए या नहीं. इसके ये इस्तेमाल हो सकते हैं:false(डिफ़ॉल्ट): अगर Credential Manager को कॉल करने की प्रोसेस, उपयोगकर्ता की किसी साफ़ तौर पर की गई कार्रवाई से ट्रिगर हुई है, तो इस वैल्यू का इस्तेमाल करें.true: अगर क्रेडेंशियल मैनेजर को किसी मौके पर कॉल किया जाता है, तो इस वैल्यू का इस्तेमाल करें. जैसे, पहली बार ऐप्लिकेशन खोलने पर.
अगर आपने वैल्यू कोtrueपर सेट किया है और तुरंत उपलब्ध क्रेडेंशियल नहीं हैं, तो क्रेडेंशियल मैनेजर कोई यूज़र इंटरफ़ेस (यूआई) नहीं दिखाएगा. साथ ही, अनुरोध तुरंत पूरा नहीं होगा. इसके अलावा, 'पाएं' अनुरोधों के लिए NoCredentialException और 'बनाएं' अनुरोधों के लिएCreateCredentialNoCreateOptionExceptionदिखेगा.
origin: यह फ़ील्ड, Android ऐप्लिकेशन के लिए अपने-आप सेट हो जाता है. उन ब्राउज़र और इसी तरह के खास अधिकार वाले ऐप्लिकेशन के लिए जिनमेंoriginसेट करना ज़रूरी है, खास अधिकार वाले ऐप्लिकेशन के लिए, अन्य पक्षों की ओर से क्रेडेंशियल मैनेजर को कॉल करना लेख पढ़ें.isConditional: यह एक वैकल्पिक फ़ील्ड है. इसकी डिफ़ॉल्ट वैल्यूfalseहोती है. ज़्यादा जानकारी के लिए, पासकी अपने-आप बनने की सुविधा लेख पढ़ें.
createCredential() फ़ंक्शन को कॉल करने पर, क्रेडेंशियल मैनेजर का इन-बिल्ट बॉटम शीट यूज़र इंटरफ़ेस (यूआई) लॉन्च होता है. इसमें उपयोगकर्ता को पासकी का इस्तेमाल करने के लिए कहा जाता है. साथ ही, स्टोरेज के लिए क्रेडेंशियल प्रोवाइडर और खाता चुनने के लिए कहा जाता है. हालांकि, अगर isConditional को true पर सेट किया जाता है, तो बॉटम शीट यूज़र इंटरफ़ेस (यूआई) नहीं दिखता है. साथ ही, पासकी अपने-आप बन जाती है.
पासकी अपने-आप बनने की सुविधा
पासकी बनाते समय, CreatePublicKeyCredentialRequest में isConditional पैरामीटर को true पर सेट करके, पासवर्ड से लॉगिन करने के बाद, उपयोगकर्ता के लिए पासकी अपने-आप बनाई जा सकती है. अगर उपयोगकर्ता के पास पहले से कोई पासकी नहीं है, तो आपका ऐप्लिकेशन बैकग्राउंड में पासकी बनाने की कोशिश करेगा और उसे उपयोगकर्ता के क्रेडेंशियल प्रोवाइडर में सेव करेगा. जैसे, Google Password Manager. इसे लागू करने के तरीके का उदाहरण देखने के लिए, सार्वजनिक
नमूना देखें.
जवाब मैनेज करना
डिवाइस के स्क्रीन लॉक का इस्तेमाल करके, उपयोगकर्ता की पुष्टि करने के बाद, पासकी बनती है और उपयोगकर्ता के चुने गए क्रेडेंशियल प्रोवाइडर में सेव हो जाती है.
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}")
}
}
ऐप्लिकेशन सर्वर पर सार्वजनिक कुंजी की पुष्टि करना और उसे सेव करना
ऐप्लिकेशन सर्वर पर, आपको सार्वजनिक कुंजी क्रेडेंशियल की पुष्टि करनी होगी. इसके बाद, सार्वजनिक कुंजी को सेव करना होगा.
सार्वजनिक कुंजी क्रेडेंशियल के सोर्स की पुष्टि करने के लिए, इसकी तुलना मंज़ूरी वाले ऐप्लिकेशन की अनुमति वाली सूची से करें. अगर किसी कुंजी का सोर्स नहीं पहचाना जा सकता, तो उसे अस्वीकार करें.
ऐप्लिकेशन का SHA 256 फ़िंगरप्रिंट पाने के लिए:
टर्मिनल में यह निर्देश चलाकर, रिलीज़ ऐप्लिकेशन का साइनिंग सर्टिफ़िकेट प्रिंट करें:
keytool -list -keystore <path-to-apk-signing-keystore>जवाब में, साइनिंग सर्टिफ़िकेट का SHA 256 फ़िंगरप्रिंट ढूंढें. यह
Certificate fingerprints block:SHA256के तौर पर दिखता है.base64url एन्कोडिंग की मदद से, SHA256 फ़िंगरप्रिंट को कोड में बदलें. इस 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('=', ''))पिछले चरण के आउटपुट की शुरुआत में
android:apk-key-hash: जोड़ें, ताकि आपको कुछ ऐसा मिले:android:apk-key-hash:<encoded SHA 256 fingerprint>नतीजा, आपके ऐप्लिकेशन सर्वर पर अनुमति वाले सोर्स से मेल खाना चाहिए. अगर आपके पास एक से ज़्यादा साइनिंग सर्टिफ़िकेट हैं, जैसे कि डीबग करने और रिलीज़ करने के लिए सर्टिफ़िकेट या एक से ज़्यादा ऐप्लिकेशन हैं, तो प्रोसेस दोहराएं और ऐप्लिकेशन सर्वर पर सभी सोर्स को मान्य के तौर पर स्वीकार करें.
उपयोगकर्ता को सूचना देना
पासकी के बन जाने के बाद, अपने उपयोगकर्ताओं को पासकी के बारे में सूचना दें और उन्हें बताएं कि वे अपने क्रेडेंशियल प्रोवाइडर ऐप्लिकेशन या ऐप्लिकेशन की सेटिंग में जाकर, अपनी पासकी मैनेज कर सकते हैं. उपयोगकर्ताओं को सूचना देने के लिए, कस्टम डायलॉग, सूचना या स्नैकबार का इस्तेमाल करें. अगर किसी नुकसान पहुंचाने वाली इकाई ने पासकी बनाई है, तो तुरंत सुरक्षा से जुड़ी चेतावनी देना ज़रूरी है. इसलिए, ऐप्लिकेशन में सूचना देने के इन तरीकों के साथ-साथ, ईमेल जैसे बाहरी तरीके से भी सूचना देने पर विचार करें.
उपयोगकर्ता अनुभव को बेहतर बनाना
क्रेडेंशियल मैनेजर की मदद से साइन अप की सुविधा लागू करते समय, उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, क्रेडेंशियल वापस पाने और अपने-आप भरने वाले डायलॉग को बंद करने की सुविधा जोड़ने पर विचार करें.
नए डिवाइस पर क्रेडेंशियल वापस पाने की सुविधा जोड़ना
उपयोगकर्ताओं को नए डिवाइस पर अपने खातों में आसानी से लॉग इन करने की अनुमति देने के लिए, क्रेडेंशियल वापस पाने की सुविधा लागू करें. BackupAgent की मदद से क्रेडेंशियल वापस पाने की सुविधा जोड़ने पर, उपयोगकर्ता नए डिवाइस पर वापस पाए गए ऐप्लिकेशन को खोलते ही लॉग इन हो जाते हैं. इससे वे तुरंत आपका ऐप्लिकेशन इस्तेमाल कर पाते हैं.
क्रेडेंशियल फ़ील्ड पर, अपने-आप भरने की सुविधा को बंद करना (ज़रूरी नहीं)
ऐप्लिकेशन की उन स्क्रीन के लिए जहां उपयोगकर्ताओं से पुष्टि करने के लिए, क्रेडेंशियल मैनेजर के बॉटम शीट यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करने की उम्मीद की जाती है, उपयोगकर्ता नाम और पासवर्ड फ़ील्ड में isCredential एट्रिब्यूट जोड़ें. इससे, अपने-आप भरने वाले डायलॉग (FillDialog और SaveDialog), क्रेडेंशियल मैनेजर के बॉटम शीट यूज़र इंटरफ़ेस (यूआई) के साथ ओवरलैप नहीं होंगे.
isCredential एट्रिब्यूट, Android 14 और इसके बाद के वर्शन पर काम करता है.
यहां दिए गए उदाहरण में, बताया गया है कि अपने ऐप्लिकेशन के लिए, काम के व्यू में, काम के उपयोगकर्ता नाम और पासवर्ड फ़ील्ड में isCredential एट्रिब्यूट कैसे जोड़ा जा सकता है:
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:isCredential="true" />