1. शुरू करने से पहले
पुष्टि करने के पारंपरिक तरीकों से, सुरक्षा और इस्तेमाल से जुड़ी कई समस्याएं आती हैं.
पासवर्ड का इस्तेमाल बड़े पैमाने पर किया जाता है, लेकिन...
- आसानी से भूल जाने वाले
- उपयोगकर्ताओं को मज़बूत पासवर्ड बनाने के बारे में जानकारी होनी चाहिए.
- इसे हैकर आसानी से फ़िश कर सकते हैं, इकट्ठा कर सकते हैं, और फिर से चला सकते हैं.
Android ने Credential Manager API बनाया है. इससे साइन इन करने की प्रोसेस को आसान बनाया जा सकता है. साथ ही, पासकी का इस्तेमाल करके, सुरक्षा से जुड़े जोखिमों को कम किया जा सकता है. पासवर्ड के बिना पुष्टि करने के लिए, पासकी को इंडस्ट्री के अगले स्टैंडर्ड के तौर पर देखा जा रहा है.
Credential Manager, पासकी की सुविधा के साथ-साथ, पुष्टि करने के पारंपरिक तरीकों को भी साथ लाता है. जैसे, पासवर्ड, 'Google से साइन इन करें' वगैरह.
उपयोगकर्ता पासकी बना सकेंगे और उन्हें Google Password Manager में सेव कर सकेंगे. इससे, वे पासकी उन सभी Android डिवाइसों पर सिंक हो जाएंगी जिन पर उपयोगकर्ता ने साइन इन किया है. पासकी का इस्तेमाल करके साइन इन करने से पहले, उसे बनाना होगा. साथ ही, उसे किसी उपयोगकर्ता खाते से जोड़ना होगा. इसके अलावा, उसकी सार्वजनिक पासकी को सर्वर पर सेव करना होगा.
इस कोडलैब में, Credential Manager API का इस्तेमाल करके पासकी और पासवर्ड से साइन अप करने का तरीका बताया गया है. साथ ही, आने वाले समय में पुष्टि करने के लिए इनका इस्तेमाल करने का तरीका भी बताया गया है. इसमें दो फ़्लो शामिल हैं:
- साइन अप करना : पासकी और पासवर्ड का इस्तेमाल करके.
- साइन इन करना : पासकी और सेव किए गए पासवर्ड का इस्तेमाल करके.
ज़रूरी शर्तें
- Android Studio में ऐप्लिकेशन चलाने के तरीके के बारे में बुनियादी जानकारी.
- Android ऐप्लिकेशन में पुष्टि करने की प्रोसेस की बुनियादी जानकारी.
- पासकी के बारे में बुनियादी जानकारी.
आपको क्या सीखने को मिलेगा
- पासकी बनाने का तरीका.
- पासवर्ड मैनेजर में पासवर्ड सेव करने का तरीका.
- पासकी या सेव किए गए पासवर्ड की मदद से, उपयोगकर्ताओं की पुष्टि करने का तरीका.
आपको किन चीज़ों की ज़रूरत होगी
डिवाइसों के इनमें से किसी एक कॉम्बिनेशन का इस्तेमाल किया जा सकता है:
- Android 9 या इसके बाद के वर्शन पर चलने वाला Android डिवाइस (पासकी के लिए) और Android 4.4 या इसके बाद के वर्शन पर चलने वाला Android डिवाइस(Credential Manager API के ज़रिए पासवर्ड की पुष्टि करने के लिए).
- डिवाइस में बायोमेट्रिक सेंसर होना चाहिए.
- पक्का करें कि आपने स्क्रीन लॉक (बायोमेट्रिक या कोई और तरीका) रजिस्टर किया हो.
- Kotlin प्लगिन का वर्शन : 1.8.10
2. सेट अप करें
इस सैंपल के तौर पर मिले ऐप्लिकेशन के लिए, किसी वेबसाइट से डिजिटल ऐसेट लिंक करना ज़रूरी है. इससे Credential Manager, लिंक करने की प्रोसेस की पुष्टि कर पाएगा और आगे की कार्रवाई कर पाएगा. इसलिए, मॉक जवाबों में इस्तेमाल किया गया आरपी आईडी, मॉक किए गए 3P सर्वर से लिया गया है. अगर आपको खुद से मॉक रिस्पॉन्स जनरेट करना है, तो अपना ऐप्लिकेशन डोमेन जोड़ें. साथ ही, डिजिटल ऐसेट लिंक करने की प्रोसेस पूरी करना न भूलें. इसके बारे में यहां बताया गया है.
प्रोजेक्ट में बताए गए debug.keystore का इस्तेमाल करके, डीबग और रिलीज़ वैरिएंट बनाएं. इससे, आपके मॉक सर्वर पर पैकेज के नाम और SHA के डिजिटल ऐसेट लिंक करने की पुष्टि की जा सकेगी. (build.gradle में मौजूद सैंपल के तौर पर मिले ऐप्लिकेशन के लिए, यह पहले से किया जा रहा है).
- अपने लैपटॉप पर, credman_codelab ब्रांच से इस रेपो को क्लोन करें: https://github.com/android/identity-samples/tree/credman_codelab
git clone -b credman_codelab https://github.com/android/identity-samples.git
- CredentialManager मॉड्यूल पर जाएं और Android Studio में प्रोजेक्ट खोलें.
इससे ऐप्लिकेशन की शुरुआती स्थिति का पता चलता है
ऐप्लिकेशन की शुरुआती स्थिति कैसे काम करती है, यह देखने के लिए यह तरीका अपनाएं:
- ऐप्लिकेशन लॉन्च करें.
- आपको साइन अप और साइन इन बटन के साथ एक मुख्य स्क्रीन दिखती है. ये बटन अभी कुछ नहीं करते, लेकिन हम आने वाले सेक्शन में इनकी सुविधा चालू करेंगे.

3. पासकी का इस्तेमाल करके साइन अप करने की सुविधा जोड़ना
Android ऐप्लिकेशन पर नया खाता बनाने के लिए साइन अप करते समय, उपयोगकर्ता अपने खाते के लिए पासकी बना सकते हैं. यह ऐप्लिकेशन, Credential Manager API का इस्तेमाल करता है. यह पासकी, उपयोगकर्ता के चुने गए क्रेडेंशियल प्रोवाइडर पर सुरक्षित तरीके से सेव की जाएगी. इसका इस्तेमाल आने वाले समय में साइन इन करने के लिए किया जाएगा. इसके लिए, उपयोगकर्ता को हर बार अपना पासवर्ड डालने की ज़रूरत नहीं होगी.
अब आपको बायोमेट्रिक/स्क्रीन लॉक का इस्तेमाल करके, पासकी बनानी होगी और उपयोगकर्ता के क्रेडेंशियल रजिस्टर करने होंगे.
पासकी से साइन अप करना
CredentialManager/app/src/main/java/com/google/credentialmanager/sample/SignUpScreen.kt में मौजूद कोड, "username" टेक्स्ट फ़ील्ड और पासकी से साइन अप करने के लिए बटन को तय करता है.

View Model में इस्तेमाल करने के लिए, createCredential() लैम्डा को तय करना
क्रेडेंशियल मैनेजर ऑब्जेक्ट के लिए, Activity को पास करना ज़रूरी है. यह किसी स्क्रीन से जुड़ा होता है. हालांकि, क्रेडेंशियल मैनेजर के ऑपरेशन आम तौर पर व्यू मॉडल में ट्रिगर होते हैं. इसलिए, व्यू मॉडल में गतिविधियों को रेफ़र करने का सुझाव नहीं दिया जाता. इसलिए, हम क्रेडेंशियल मैनेजर के फ़ंक्शन को एक अलग फ़ाइल CredentialManagerUtil.kt में तय करते हैं और उन्हें सही स्क्रीन में रेफ़रंस देते हैं. इसके बाद, ये स्क्रीन उन्हें लैम्डा फ़ंक्शन के ज़रिए, अपने व्यू मॉडल को कॉलबैक के तौर पर पास करती हैं.
CredentialManagerUtil.kt में मौजूद createCredential() फ़ंक्शन में TODO टिप्पणी ढूंढें और CredentialManager.create() फ़ंक्शन को कॉल करें:
CredentialManagerUtil.kt
suspend fun createCredential(
activity: Activity,
request: CreateCredentialRequest
): CreateCredentialResponse {
TODO("Create a CredentialManager object and call createCredential() with a CreateCredentialRequest")
val credentialManager = CredentialManager.create(activity)
return credentialManager.createCredential(activity, request)
}
चैलेंज और अन्य JSON जवाब को createPasskey() कॉल में पास करें
पासकी बनाने से पहले, आपको सर्वर से ज़रूरी जानकारी का अनुरोध करना होगा. यह जानकारी, createCredential() कॉल के दौरान Credential Manager API को भेजी जाएगी.
आपके प्रोजेक्ट की ऐसेट में पहले से ही एक मॉक रिस्पॉन्स मौजूद है. इसे RegFromServer.txt कहा जाता है. यह इस कोडलैब में ज़रूरी पैरामीटर दिखाता है.
- अपने ऐप्लिकेशन में,
SignUpViewModel.ktपर जाएं.signUpWithPasskeysवाला वह तरीका ढूंढें जहां आपको पासकी बनाने और उपयोगकर्ता को ऐक्सेस देने के लिए लॉजिक लिखना है. आपको यह तरीका, उसी क्लास में मिलेगा. TODOसेcreate a CreatePublicKeyCredentialRequest()तक के कमेंट ब्लॉक को ढूंढें और उसकी जगह यह कोड डालें:
SignUpViewModel.kt
TODO("Create a CreatePublicKeyCredentialRequest() with necessary registration json from server")
val request = CreatePublicKeyCredentialRequest(
jsonProvider.fetchRegistrationJson()
.replace("<userId>", getEncodedUserId())
.replace("<userName>", _username.value)
.replace("<userDisplayName>", _username.value)
.replace("<challenge>", getEncodedChallenge())
)
jsonProvider.fetchRegistrationJsonFromServer() तरीका, ऐसेट से, सर्वर PublicKeyCredentialCreationOptions के JSON रिस्पॉन्स को पढ़ता है. साथ ही, पासकी बनाते समय पास किए जाने वाले रजिस्ट्रेशन JSON को दिखाता है. हम प्लेसहोल्डर की कुछ वैल्यू को अपने ऐप्लिकेशन से मिली उपयोगकर्ता की एंट्री और कुछ मॉक फ़ील्ड से बदल देते हैं:
- यह JSON अधूरा है और इसमें चार फ़ील्ड हैं जिन्हें बदलने की ज़रूरत है.
- UserId यूनीक होना चाहिए, ताकि उपयोगकर्ता ज़रूरत पड़ने पर एक से ज़्यादा पासकी बना सके. जनरेट की गई
userIdवैल्यू को<userId>से बदलें. <challenge>भी यूनीक होना चाहिए, इसलिए आपको एक रैंडम यूनीक चैलेंज जनरेट करना होगा. यह तरीका आपके कोड में पहले से मौजूद है.
असली सर्वर PublicKeyCredentialCreationOptions से मिले जवाब में ज़्यादा विकल्प हो सकते हैं. इनमें से कुछ फ़ील्ड का उदाहरण यहां दिया गया है:
{
"challenge": String,
"rp": {
"name": String,
"id": String
},
"user": {
"id": String,
"name": String,
"displayName": String
},
"pubKeyCredParams": [
{
"type": "public-key",
"alg": -7
},
{
"type": "public-key",
"alg": -257
}
],
"timeout": 1800000,
"attestation": "none",
"excludeCredentials": [],
"authenticatorSelection": {
"authenticatorAttachment": "platform",
"requireResidentKey": true,
"residentKey": "required",
"userVerification": "required"
}
}
यहां दी गई टेबल में, PublicKeyCredentialCreationOptions ऑब्जेक्ट के कुछ अहम पैरामीटर के बारे में बताया गया है:
पैरामीटर | जानकारी |
यह सर्वर से जनरेट की गई एक रैंडम स्ट्रिंग होती है. इसमें इतनी एंट्रॉपी होती है कि इसका अनुमान लगाना मुश्किल होता है. यह कम से कम 16 बाइट का होना चाहिए. यह ज़रूरी है, लेकिन रजिस्ट्रेशन के दौरान इसका इस्तेमाल नहीं किया जाता. हालांकि, अटेस्टेशन के दौरान इसका इस्तेमाल किया जाता है. | |
उपयोगकर्ता का यूनीक आईडी. इस वैल्यू में, पहचान ज़ाहिर करने वाली निजी जानकारी शामिल नहीं होनी चाहिए. उदाहरण के लिए, ईमेल पते या उपयोगकर्ता नाम. हर खाते के लिए, किसी भी क्रम में जनरेट की गई 16-बाइट की वैल्यू का इस्तेमाल किया जा सकता है. | |
इस फ़ील्ड में, खाते का ऐसा यूनीक आइडेंटिफ़ायर होना चाहिए जिसे उपयोगकर्ता पहचान सके. जैसे, उनका ईमेल पता या उपयोगकर्ता नाम. यह खाता चुनने की सुविधा में दिखेगा. (अगर उपयोगकर्ता नाम का इस्तेमाल किया जा रहा है, तो पासवर्ड की पुष्टि करने के लिए इस्तेमाल की गई वैल्यू का इस्तेमाल करें.) | |
यह फ़ील्ड, खाते का वैकल्पिक नाम है. यह नाम, उपयोगकर्ता के लिए ज़्यादा आसान होता है. | |
भरोसेमंद पार्टी की इकाई, आपके आवेदन की जानकारी से मेल खाती है. इसमें ये एट्रिब्यूट शामिल हैं:
| |
अनुमति वाले एल्गोरिदम और कुंजी के टाइप की सूची. इस सूची में कम से कम एक एलिमेंट होना चाहिए. | |
ऐसा हो सकता है कि डिवाइस रजिस्टर करने की कोशिश करने वाले व्यक्ति ने पहले ही अन्य डिवाइस रजिस्टर कर लिए हों. अगर आपको एक ही Authenticator ऐप्लिकेशन पर, एक ही खाते के लिए कई क्रेडेंशियल बनाने की सुविधा को सीमित करना है, तो इन डिवाइसों को अनदेखा किया जा सकता है. अगर | |
इससे पता चलता है कि डिवाइस को प्लैटफ़ॉर्म पर अटैच किया जाना चाहिए या नहीं. इसके अलावा, इससे यह भी पता चलता है कि ऐसा करना ज़रूरी है या नहीं. इस वैल्यू को | |
| पासकी बनाने के लिए, वैल्यू |
क्रेडेंशियल बनाना
CreatePublicKeyCredentialRequest()बनाने के बाद, आपको बनाए गए अनुरोध के साथcreateCredential()को कॉल करना होगा.
SignUpViewModel.kt
try {
TODO("Call createCredential() with createPublicKeyCredentialRequest")
createCredential(request)
TODO("Complete the registration process after sending public key credential to your server and let the user in")
} catch (e: CreateCredentialException) {
handlePasskeyFailure(e)
}
- आपके पास रेंडर किए गए व्यू की विज़िबिलिटी को मैनेज करने का विकल्प होता है. साथ ही, अनुरोध पूरा न होने या किसी वजह से फ़ेल होने पर, अपवादों को मैनेज करने का विकल्प होता है. यहां गड़बड़ी के मैसेज लॉग किए जाते हैं और ऐप्लिकेशन में गड़बड़ी वाले डायलॉग में दिखाए जाते हैं. Android Studio या
adb debugकमांड का इस्तेमाल करके, गड़बड़ी के पूरे लॉग देखे जा सकते हैं.
- आखिर में, आपको रजिस्ट्रेशन की प्रोसेस पूरी करनी होगी. ऐप्लिकेशन, सर्वर को सार्वजनिक कुंजी क्रेडेंशियल भेजता है. सर्वर, इसे मौजूदा उपयोगकर्ता के लिए रजिस्टर करता है.
यहां हमने एक मॉक सर्वर का इस्तेमाल किया है. इसलिए, हम सिर्फ़ यह बताते हैं कि सर्वर ने रजिस्टर की गई सार्वजनिक कुंजी को सेव कर लिया है, ताकि आने वाले समय में पुष्टि और पुष्टि की जा सके. सर्वर साइड पासकी रजिस्ट्रेशन के बारे में ज़्यादा जानकारी पाएं, ताकि इसे लागू किया जा सके.
signUpWithPasskeys() तरीके में जाकर, काम की टिप्पणी ढूंढें और उसे इस कोड से बदलें:
SignUpViewModel.kt
try {
createCredential(request)
TODO("Complete the registration process after sending public key credential to your server and let the user in")
registerResponse()
DataProvider.setSignedInThroughPasskeys(true)
_navigationEvent.emit(NavigationEvent.NavigateToHome(signedInWithPasskeys = true))
} catch (e: CreateCredentialException) {
handlePasskeyFailure(e)
}
registerResponse(),trueदिखाता है. इसका मतलब है कि मॉक सर्वर ने सार्वजनिक पासकोड को बाद में इस्तेमाल करने के लिए सेव कर लिया है.setSignedInThroughPasskeysफ़्लैग कोtrueपर सेट करें.- लॉग इन करने के बाद, उपयोगकर्ता को होम स्क्रीन पर रीडायरेक्ट करें.
असल PublicKeyCredential में ज़्यादा फ़ील्ड हो सकते हैं. इन फ़ील्ड का उदाहरण यहां दिया गया है:
{
"id": String,
"rawId": String,
"type": "public-key",
"response": {
"clientDataJSON": String,
"attestationObject": String,
}
}
यहां दी गई टेबल में, PublicKeyCredential ऑब्जेक्ट के कुछ अहम पैरामीटर के बारे में बताया गया है:
पैरामीटर | जानकारी |
यह बनाई गई पासकी का Base64URL कोड में बदला गया आईडी होता है. इस आईडी से ब्राउज़र को यह तय करने में मदद मिलती है कि पुष्टि करने के दौरान, डिवाइस में मिलती-जुलती पासकी मौजूद है या नहीं. यह वैल्यू, बैकएंड पर मौजूद डेटाबेस में सेव होनी चाहिए. | |
| |