Android पर आसानी से साइन इन करने और डिजिटल क्रेडेंशियल इस्तेमाल करने की सुविधा देना

सभी को नमस्ते।

इस सेशन में शामिल होने के लिए धन्यवाद.

आज हम पुष्टि करने की प्रोसेस और डिजिटल आइडेंटिटी के भविष्य के बारे में बात करेंगे.

मेरा नाम टॉम कॉल्विन है.

मैं Apptaura में सीटीओ हूं और Android पर जीडीई हूं. मेरे साथ चिपिंग येह हैं, जो Google में सीनियर Android डेवलपर रिलेशंस इंजीनियर हैं.

पासवर्ड का इस्तेमाल अब पुराना हो गया है.

या कम से कम, ऐसा होना चाहिए.

आज मैं आपसे बिना पासवर्ड वाली दुनिया के बारे में बात करने जा रहा हूं.

पासवर्ड, हमारे सुरक्षा इंफ़्रास्ट्रक्चर में एक जाना-माना जोखिम है.

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

इंडस्ट्री के तौर पर, हमने इस समस्या को हल करने के लिए, पासवर्ड को जटिल बनाने की कोशिश की है. जैसे, खास वर्ण, नंबर, और पासवर्ड को समय-समय पर बदलना.

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

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

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

हालांकि, आज यह समस्या काफ़ी हद तक हल हो गई है.

पासकी, FIDO के मानकों पर आधारित होती हैं. साथ ही, इनमें सार्वजनिक-निजी पासकोड क्रिप्टोग्राफ़ी का इस्तेमाल किया जाता है.

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

आज हमारा मेनिफ़ेस्टो आसान है.

अब बिना पासवर्ड वाली दुनिया में जाने का समय आ गया है.

इसके लिए ज़रूरी टूल हमारे पास पहले से ही मौजूद हैं.

Android पर इस बदलाव को लागू करने के लिए, हमारे पास Jetpack Credential Manager है.

यह Android 4.4 और इसके बाद के वर्शन पर काम करता है. साथ ही, Android 9 और इसके बाद के वर्शन पर पासकी काम करती हैं. यह एक ऐसा एपीआई है जो पासकी के साथ-साथ, पुष्टि करने के पारंपरिक तरीकों के साथ भी काम करता है. जैसे, फ़ेडरेटेड साइन-इन, Google से साइन इन करना. साथ ही, ज़रूरत पड़ने पर पासवर्ड का इस्तेमाल करने की सुविधा भी देता है.

Credential Manager API को कॉल करने पर, यह यूज़र इंटरफ़ेस (यूआई) को मैनेज करता है. इससे यह तय किया जाता है कि उपयोगकर्ता को पुष्टि करने का कौनसा तरीका देखना है.

इसके बाद, यह सुरक्षित तरीके से सही क्रेडेंशियल हासिल करता है.

इसमें साइन इन करने, साइन अप करने, और क्रेडेंशियल का बैक अप लेने की सुविधा मिलती है.

इसका इस्तेमाल करके, क्रेडेंशियल अपडेट किए जा सकते हैं और मिटाए जा सकते हैं.

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

इसे इस तरह से डिज़ाइन किया गया है कि उपयोगकर्ताओं को उनके डेटा का पूरा कंट्रोल मिले. साथ ही, वे जब चाहें, तब सेवा देने वाली कंपनी को बदल सकें.

Credential Manager, कई तरह के डिवाइसों पर काम करता है. जैसे, स्मार्टवॉच, टीवी, XR, Automotive, फ़ोन, फ़ोल्ड किए जा सकने वाले डिवाइस, और टैबलेट.

सबसे अहम बात यह है कि इसमें पासकी के लिए एक खास फ़्लो है.

साइन अप करने के दौरान, उपयोगकर्ता को यह ऐसा दिखता है.

मेरा ऐप्लिकेशन, Credential Manager को बताता है कि पासकी से पुष्टि करने की सुविधा उपलब्ध है. साथ ही, यह बैक-एंड से इकट्ठा की गई जानकारी उपलब्ध कराता है.

'रजिस्टर करें' पर टैप करने पर, Credential Manager आपको स्क्रीन लॉक प्रॉम्प्ट के साथ एक बॉटम शीट दिखाता है.

आम तौर पर, इसे फ़िंगरप्रिंट या फ़ेस स्कैन जैसे बायोमेट्रिक डेटा से अनलॉक किया जाता है.

इसके बाद, Credential Manager पासकी बनाने जैसे मुश्किल क्रिप्टोग्राफ़ी टास्क को हैंडल करता है.

यह पासकी को मेरे क्रेडेंशियल मैनेजर में सेव करता है. इस मामले में, यह Google Password Manager है. हालांकि, यह कोई और मैनेजर भी हो सकता है.

कोड ऐसा दिखता है.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

सबसे पहले, हम बैक-एंड से मिली जानकारी का इस्तेमाल करके, यह createPublicKeyCredentialRequest ऑब्जेक्ट बना रहे हैं. यह registerRequestJson है.

इसके बाद, हम मैजिक मेथड credentialManager.createCredential को कॉल करते हैं.

हम उस अनुरोध और लोकल कॉन्टेक्स्ट को पास करते हैं, जिससे यूज़र इंटरफ़ेस (यूआई) दिखता है.

ध्यान दें कि मुझे यहां यूज़र इंटरफ़ेस (यूआई) का कोई कोड नहीं लिखना पड़ा.

Credential Manager हमारे लिए यह काम पूरी तरह से करता है.

अब, साइन-इन करने की प्रोसेस के बारे में जानें.

उपयोगकर्ता को यह प्रोसेस, साइन अप करने की प्रोसेस जैसी ही लगती है.

इसके बाद, आपको अनलॉक करने का एक प्रॉम्प्ट दिखेगा. बस, आपका काम हो गया.

डेवलपर के लिए, यह थोड़ा अलग है.

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

सबसे पहले, हम GetPublicKeyCredential इंस्टेंस बनाने के लिए, बैक-एंड से साइन इन की जानकारी लेते हैं.

हम Credential Manager को बताते हैं कि हमारे ऐप्लिकेशन में किस तरह के क्रेडेंशियल इस्तेमाल किए जा सकते हैं.

यहां सिर्फ़ पासकी का इस्तेमाल किया जाता है.

हालांकि, अगर हम चाहें, तो अन्य तरह के क्रेडेंशियल भी जोड़ सकते हैं.

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

इसके लिए भी, यूज़र इंटरफ़ेस (यूआई) कोड की ज़रूरत नहीं होती.

कोई यूज़र इंटरफ़ेस (यूआई) कोड लिखने की ज़रूरत नहीं है.

Credential Manager, हमारे लिए इस बात का पूरा ध्यान रखता है.

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

इससे, पुष्टि करने से जुड़ी आज की सबसे बड़ी समस्याओं में से एक अपने-आप हल हो जाती है.

क्या आपने ध्यान दिया?

इसका मतलब है कि मैंने पिछली बार साइन इन करने के लिए जिस तरीके का इस्तेमाल किया था उसे याद रखना.

देखिए, बॉटम शीट में जवाब कितने अच्छे से दिया गया है.

हालांकि, इससे उपयोगकर्ता को सिर्फ़ परेशानी नहीं होती.

यह एक असली समस्या है.

इसकी वजह से, लोगों को बेवजह खाता वापस पाने की प्रोसेस पूरी करनी पड़ती है. साथ ही, इससे कारोबार पर भी असर पड़ता है. जैसे, लोग शॉपिंग कार्ट में आइटम जोड़कर छोड़ देते हैं.

यहां मेरे डेमो ऐप्लिकेशन का कोड दिया गया है. इसका इस्तेमाल करके, Credential Manager को आज़माया जा सकता है.

इन फ़्लो को अपने डिवाइस पर देखा जा सकता है.

बाईं ओर, Google के आधिकारिक कोड सैंपल मौजूद हैं.

यह पासकी बनाने की प्रोसेस को मैनेज करता है.

पासवर्ड इस्तेमाल करने वाले मौजूदा उपयोगकर्ताओं को पासकी पर अपग्रेड करने के बारे में क्या?

इसके लिए, कंडीशनल क्रिएट एक बेहतरीन टूल है.

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

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

इससे उपयोगकर्ता के वर्कफ़्लो में कोई रुकावट नहीं आती.

पासकी अपने-आप जनरेट होती है और सेव हो जाती है.

Google Password Manager आपको सूचना दिखाता है कि आपके लिए एक पासकी बनाई गई है.

ऐसा हो सकता है कि अन्य पासवर्ड मैनेजर अलग तरीके से काम करें.

कंडिशनल क्रिएट का कोड, साइन अप करने के कोड से काफ़ी मिलता-जुलता है.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

मैजिक फ़्लैग isConditional true है. इससे यह पक्का होता है कि उपयोगकर्ता को वह यूज़र इंटरफ़ेस (यूआई) न दिखे.

यह सुविधा ज़रूरत के हिसाब से काम करती है. इसलिए, हम इसे try-catch में रखेंगे.

हम किसी भी गड़बड़ी को चुपचाप ठीक कर देंगे, ताकि प्रोसेस पूरी न होने पर उपयोगकर्ता को परेशानी न हो.

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

Credential Manager, क्रेडेंशियल उपलब्ध कराने वाली कंपनियों को अपने क्रेडेंशियल सुरक्षित तरीके से इंपोर्ट और एक्सपोर्ट करने की सुविधा भी देता है.

बस कुछ ही क्लिक में.

इसके लिए, आपको कुछ भी डाउनलोड करने की ज़रूरत नहीं है.

इससे, जानकारी को सुरक्षित रखते हुए, ज़्यादा आसानी से काम किया जा सकता है.

फ़्लो कुछ ऐसा दिखता है.

उपयोगकर्ता, क्रेडेंशियल उपलब्ध कराने वाली नई सेवा में क्रेडेंशियल इंपोर्ट करने का अनुरोध करता है.

इसके बाद, Credential Manager इंपोर्ट यूज़र इंटरफ़ेस (यूआई) को मैनेज करता है. इससे उपयोगकर्ता, क्रेडेंशियल डेटा का सोर्स चुन सकता है.

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

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

इसलिए, यह उपयोगकर्ता के इंटरैक्शन के बिना ही इसे इंपोर्ट कर सकता है.

अगर उपयोगकर्ता अपने ऐप्लिकेशन या वेबसाइट से पासकी को रद्द कर देता है, तो क्या होगा?

ऐसे में, क्रेडेंशियल प्रोवाइडर को यह पता नहीं होता कि ऐसा हुआ है.

अगली बार जब वे साइन इन करने की कोशिश करेंगे, तो Credential Manager उस पासकी को इस्तेमाल करने का सुझाव देगा जो अब काम नहीं करती. इससे वे साइन इन नहीं कर पाएंगे.

इसी तरह, जब कोई उपयोगकर्ता अपना उपयोगकर्ता नाम या डिसप्ले नेम अपडेट करता है, तो उसे सिंक करना ज़रूरी होता है.

अब Signal API की मदद से, आपका ऐप्लिकेशन क्रेडेंशियल मैनेजर को इन स्थितियों के बारे में फ़्लैग कर सकता है.

उदाहरण के लिए, रद्द किए गए पासवर्ड से साइन इन करने का मामला लें.

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

इसके बाद, क्रेडेंशियल प्रोवाइडर खुद को अपडेट कर सकता है, ताकि वह पासकी फिर से न दी जाए.

ये Credential Manager की कुछ सुविधाएं हैं. यह पासकी का इस्तेमाल करके, उपयोगकर्ताओं को साइन अप करने में मदद करता है. साथ ही, साइन इन करते समय अन्य तरीकों के मुकाबले पासकी को प्राथमिकता देता है.

हालांकि, याद रखें कि हमारा मकसद पासवर्ड का इस्तेमाल पूरी तरह से बंद करना है.

Credential Manager इस लक्ष्य को हासिल करने में कैसे मदद करता है?

यहां पांच चरणों वाली प्रोसेस दी गई है.

पहले दो चरणों में, पासवर्ड इस्तेमाल करने वाले उपयोगकर्ताओं को पासकी पर अपग्रेड किया जाता है.

सबसे पहले, हम कंडिशनल क्रिएट का इस्तेमाल करके, मौके का फ़ायदा उठाने की कोशिश करते हैं.

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

हम धीरे-धीरे उन वीडियो को ज़्यादा से ज़्यादा लोगों को दिखा सकते हैं.

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

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

हालांकि, पुराने उपयोगकर्ताओं के लिए, हम इन आखिरी तीन चरणों का इस्तेमाल करते हैं.

हम पासकी का इस्तेमाल करने वाले लोगों को अपने पासवर्ड हटाने का सुझाव देते हैं.

इसलिए, तीसरे चरण में हम उन्हें मैन्युअल तरीके से ऐसा करने की अनुमति दे रहे हैं. इसके लिए, उन्हें खाते की सेटिंग में जाकर, 'पासवर्ड मिटाएं' विकल्प को चुनना होगा.

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

आखिर में, पासवर्ड मिटाने की सुविधा को शामिल होने से बाहर होने पर स्विच करें.

आखिर में, ऑप्ट-आउट करने का आखिरी विकल्प भी हट सकता है.

Analytics से हमें ऐप्लिकेशन से पासवर्ड फ़्लो को पूरी तरह से हटाने का भरोसा मिलेगा.

इसलिए, पासवर्ड के बिना साइन इन करने की सुविधा अब सिर्फ़ एक थ्योरी नहीं रह गई है, बल्कि यह एक हकीकत है.

यह सुविधा ज़्यादातर डिवाइसों पर काम करती है.

एपीआई बेहतरीन हैं और उपयोगकर्ता अनुभव शानदार है.

हमारा सुझाव है कि आप आज ही Credential Manager के साथ पासकी फ़्लो को इंटिग्रेट करना शुरू करें.

अपने उपयोगकर्ताओं को अपग्रेड करना शुरू करें और पासवर्ड के इस्तेमाल को हमेशा के लिए अलविदा कहें.

धन्यवाद.

अब मैं चिपिंग को बुलाना चाहूंगा, ताकि वे डिवाइस माइग्रेशन और आइडेंटिटी के अगले चरण के बारे में बता सकें.

चलिए.

ठीक है, धन्यवाद, टॉम.

टॉम ने बताया कि उपयोगकर्ता के डिवाइसों पर आसानी से पुष्टि करना ज़रूरी है.

हालांकि, जब कोई उपयोगकर्ता नया फ़ोन खरीदता है, तो क्या होता है?

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

आज, मैं सबसे पहले इस बारे में बात करना चाहता हूं कि हम इस समस्या को कैसे हल कर रहे हैं. साथ ही, क्रेडेंशियल वापस लाने के बारे में Play Store की आने वाली ज़रूरी शर्त के बारे में भी बताना चाहता हूं.

अप्रैल 2027 से, Google Play पर मौजूद सभी ऐप्लिकेशन को बिना टैप किए साइन-इन करने की सुविधा से जुड़ी ज़रूरी शर्तें पूरी करनी होंगी. ऐसा करने पर ही, ऐप्लिकेशन को पब्लिश करने की सभी सुविधाएं मिलती रहेंगी और वह Play Store पर ज़्यादा से ज़्यादा लोगों को दिखेगा.

बिना टैप किए साइन इन करने की सुविधा क्या है?

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

हम इसे कैसे लागू करें?

हमारा सुझाव है कि इसके लिए, Credential Manager के ज़रिए Android के Restore Credentials API का इस्तेमाल करें.

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

हमारा सुझाव है कि उपयोगकर्ता के साइन इन करने के बाद, बैकग्राउंड में यह कुंजी जनरेट करें.

इस डायग्राम में, हमने ऐप्लिकेशन में साइन इन करने वाले उपयोगकर्ता को दिखाया है.

इसके बाद, ऐप्लिकेशन का इस्तेमाल करने के दौरान, रीस्टोर करने की कुंजी (क्रेडेंशियल) बनाई जाती है.

इसके बाद, इस पासकी को डिवाइस की मेमोरी या स्टोरेज में सेव किया जाता है. इसके अलावा, अगर क्लाउड पर सेव करने की सुविधा चालू है, तो इसे क्लाउड पर सेव किया जाता है.

जब उपयोगकर्ता अपना नया डिवाइस सेट अप करता है, तो डिवाइस सेटअप की प्रोसेस के दौरान, बैकग्राउंड में रीस्टोर क्रेडेंशियल अपने-आप ट्रांसफ़र हो जाता है.

उपयोगकर्ता, क्लाउड से डेटा वापस लाने या डिवाइस-टू-डिवाइस ट्रांसफ़र करने का विकल्प चुन सकते हैं.

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

इससे उपयोगकर्ता, आपके ऐप्लिकेशन में तुरंत और सुरक्षित तरीके से लॉग इन कर सकता है.

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

इससे उपयोगकर्ता, आपके ऐप्लिकेशन को मैन्युअल तरीके से खोले बिना उसमें लॉग इन कर पाएगा.

हमारे कुछ पार्टनर ने इसे अपने ऐप्लिकेशन में पहले ही लागू कर दिया है.

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

ऐक्सेस करने में आसान होना ज़रूरी है.

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

डिवाइस बदलने की इस आदत की वजह से, उपयोगकर्ताओं को अपने साथ जोड़े रखना एक चुनौती बन जाता है.

उपयोगकर्ताओं की मांग और कोड प्रोटोटाइपिंग का आकलन करने के बाद, Uber ने Uber Rider ऐप्लिकेशन में Restore Credentials की सुविधा जोड़ी. इसके नतीजे काफ़ी अच्छे रहे.

उनका अनुमान है कि इससे हर दिन औसतन 40 लाख लॉगिन बचेंगे. साथ ही, उन्हें उम्मीद है कि जैसे-जैसे इस सुविधा का इस्तेमाल बढ़ेगा, यह संख्या भी बढ़ेगी.

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

यह बदलाव अप्रैल 2027 में लागू होगा. इसलिए, कृपया अपने कैलेंडर में यह तारीख मार्क कर लें.

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

इस स्किल का इस्तेमाल करके, अपनी पसंद के एजेंट के साथ सुविधा को तेज़ी से डेवलप किया जा सकता है या उसकी जांच की जा सकती है.

अब डिजिटल आइडेंटिटी के अगले पड़ाव के बारे में जानते हैं: Credential Manager के ज़रिए Digital Credentials API.

आइए, जानते हैं कि डिजिटल क्रेडेंशियल क्या हैं और ये कैसे काम करते हैं.

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

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

इसके कई फ़ायदे हैं. जैसे, पहचान की पुष्टि करना, सेवाओं को ऐक्सेस करना, और ऑनलाइन खरीदारी करना.

डिजिटल क्रेडेंशियल, प्लास्टिक कार्ड के बिना जानकारी शेयर करने का एक सुरक्षित और आसान तरीका है.

डिजिटल क्रेडेंशियल में तीन पक्ष शामिल होते हैं: क्रेडेंशियल जारी करने वाला, क्रेडेंशियल होल्डर, और क्रेडेंशियल की पुष्टि करने वाला.

डिजिटल क्रेडेंशियल की लाइफ़ साइकल आम तौर पर बाईं से दाईं ओर चलती है.

आइए, इन सभी इकाइयों और उनकी भूमिकाओं के बारे में जानें.

पहला है क्रेडेंशियल जारी करने वाला. जैसा कि नाम से पता चलता है, यह वह पक्ष है जो क्रेडेंशियल जारी करता है. जैसे, सरकार आपका पासपोर्ट जारी करती है.

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

कोई भी व्यक्ति या कारोबार, पास जारी कर सकता है. जैसे, जिम, होटल या आप खुद.

आपको बस क्रेडेंशियल बनाना होगा और उस पर हस्ताक्षर करना होगा.

ठीक है, तो क्रेडेंशियल जारी करने वाली इकाई, क्रेडेंशियल बनाती और जारी करती है. हालांकि, उन्हें कहीं सेव करना ज़रूरी होता है. ठीक वैसे ही, जैसे आपको अपने सरकारी आईडी को अपने वॉलेट में सेव करना होता है.

यह अगली पार्टी है, जिसे होल्डर कहा जाता है. इसे आम तौर पर डिजिटल वॉलेट भी कहा जाता है.

होल्डर, जैसा कि नाम से पता चलता है, मुख्य रूप से क्रेडेंशियल को सेव करते हैं. ये क्रेडेंशियल, उन्हें जारी करने वाले लोगों या संगठनों से मिलते हैं.

ये आपके डिवाइस पर एक ऐप्लिकेशन के तौर पर मौजूद होते हैं. इसके बाद, इन्हें अनुरोध करने वाले पक्षों को दिखाया जा सकता है.

जारी करने वालों की तरह ही, कोई भी व्यक्ति होल्डर हो सकता है.

आम तौर पर, कार्ड जारी करने वाली और कार्ड इस्तेमाल करने वाली इकाई एक ही होती है.

मान लें कि कोई जिम, डिजिटल सदस्यता क्रेडेंशियल बनाना चाहता है और उसे अपने ऐप्लिकेशन से मैनेज करना चाहता है.

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

ठीक है, तीसरा पक्ष वह होता है जो पुष्टि करता है या डिजिटल क्रेडेंशियल का अनुरोध करता है.

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

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

Android पर, इन तीनों पक्षों और उपयोगकर्ता के बीच होने वाले इंटरैक्शन को Credential Manager के ज़रिए मैनेज किया जाता है. इसके लिए, Digital Credentials API का इस्तेमाल किया जाता है.

क्रेडेंशियल जारी करने वाली इकाई, एपीआई को कॉल करके क्रेडेंशियल होल्डर को क्रेडेंशियल जारी कर सकती है. हालांकि, अगर क्रेडेंशियल जारी करने वाली इकाई और क्रेडेंशियल होल्डर एक ही इकाई हैं, तो ऐसा करना ज़रूरी नहीं है.

क्रेडेंशियल जारी होने के बाद, पुष्टि करने वाला व्यक्ति क्रेडेंशियल का अनुरोध करने के लिए एपीआई को कॉल कर सकता है.

Credential Manager, अनुरोध को सभी उपलब्ध होल्डर से मैच करता है. इसके बाद, वह उपयोगकर्ता को क्रेडेंशियल चुनने और सहमति देने के लिए दिखाता है.

क्रेडेंशियल होल्डर को चुनने के बाद, उसे शुरू किया जाता है. साथ ही, क्रेडेंशियल की पुष्टि करने वाले के साथ क्रेडेंशियल शेयर करने से पहले, ज़रूरत पड़ने पर अतिरिक्त जांच की जा सकती है.

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

अब आपको लग सकता है कि डिजिटल क्रेडेंशियल सुरक्षित कैसे हैं?

इस प्रोसेस के हर चरण में सुरक्षा का ध्यान रखा जाता है. चलिए, अब हम इनमें से कुछ चरणों के बारे में बात करते हैं.

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

यह इसकी पुष्टि कैसे कर सकता है?

क्रेडेंशियल जारी करने से पहले, जारी करने वाले को यह पुष्टि करनी होती है कि क्रेडेंशियल होल्डर की पहचान सही है और वह जिस डिवाइस का इस्तेमाल कर रहा है वह सुरक्षित है.

होल्डर, अपने वॉलेट का अटेस्टेशन भेजता है. आम तौर पर, यह पुष्टि किए जा सकने वाले सर्टिफ़िकेट की चेन के तौर पर होता है.

होल्डर, हार्डवेयर से बाउंड कुंजी का जोड़ा भी जनरेट करता है.

यह जारी करने वाली कंपनी को, इस कुंजी के जोड़े से सार्वजनिक पासकोड भेजता है. इसके लिए, Android की कुंजी की पुष्टि करने की सुविधा का इस्तेमाल किया जाता है. इससे जारी करने वाली कंपनी, हार्डवेयर की वैधता की पुष्टि कर सकती है.

जारी करने वाला संगठन, जारी किए गए क्रेडेंशियल में इस सार्वजनिक पासकोड को साइन करेगा. इससे क्रेडेंशियल, आधिकारिक तौर पर सिर्फ़ एक डिवाइस से बाउंड हो जाएगा.

होल्डर के पास नया क्रेडेंशियल होने पर, वह Credential Manager के साथ सिर्फ़ अपने क्रेडेंशियल का मेटाडेटा रजिस्टर करता है.

Credential Manager इस मेटाडेटा का इस्तेमाल करके यह तय करता है कि जब पुष्टि करने वाला कोई व्यक्ति क्रेडेंशियल का अनुरोध करे, तो उसे कौनसे होल्डर दिखाने हैं.

Credential Manager में, उपयोगकर्ता का कोई भी असली डेटा रजिस्टर नहीं किया जाता. इसके अलावा, Google के साथ भी ऐसा कोई डेटा शेयर नहीं किया जाता.

जब Credential Manager, उपयोगकर्ता को दिखाने के लिए वॉलेट चुनता है, तब भी हर वॉलेट में मौजूद कॉन्टेंट को उस समय नहीं दिखाया जाता.

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

आपको याद होगा कि होल्डर सिर्फ़ एक ऐप्लिकेशन होता है. इसलिए, ऐप्लिकेशन को शुरू किया जाता है.

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

Google, क्रेडेंशियल डेटा को ऐक्सेस नहीं कर सकता.

सिर्फ़ रूटिंग मेटाडेटा को रजिस्टर किया जाता है. साथ ही, होल्डर और पुष्टि करने वाले के बीच पेलोड को पूरी तरह सुरक्षित रखा जाता है.

इससे क्रेडेंशियल होल्डर को यह कंट्रोल मिलता है कि वह अपने क्रेडेंशियल किन पक्षों के साथ शेयर करना चाहता है.

आखिर में, क्रेडेंशियल का अनुरोध करने के बाद, क्रेडेंशियल की पुष्टि करने वाले व्यक्ति को क्रेडेंशियल मिल जाता है.

अब पुष्टि करने वाला व्यक्ति यह जांच सकता है कि जवाब, अनुरोध के लिए क्रेडेंशियल के मूल मालिक ने हाल ही में जनरेट किया था या नहीं.

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

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

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

हमने यह जान लिया है कि डिजिटल क्रेडेंशियल कैसे सुरक्षित होते हैं. अब हम डिजिटल क्रेडेंशियल के इस्तेमाल के कुछ उदाहरणों के बारे में जानेंगे. ये उदाहरण, Android पर Digital Credentials API के ज़रिए उपलब्ध हैं.

इनमें से सबसे पहले, हम ईमेल पते की पुष्टि करने की सुविधा के बारे में बात करेंगे.

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

इसका मतलब है कि उपयोगकर्ता को आपका ऐप्लिकेशन छोड़ने की ज़रूरत नहीं पड़ती. उसे सिर्फ़ एक टैप करके, Credential Manager की बॉटम शीट पर सहमति देनी होती है.

यहां एपीआई के काम करने के तरीके की रिकॉर्डिंग का डेमो दिया गया है.

यह सैंपल के तौर पर मिला ऐप्लिकेशन है, जो Digital Credentials API के ज़रिए ईमेल पते की पुष्टि करता है.

"पुष्टि किए गए ईमेल पते का अनुरोध करें" पर टैप करने पर, Credential Manager उन डिवाइसों से पुष्टि किए गए ईमेल पते के डिजिटल क्रेडेंशियल का अनुरोध करता है जिनमें इस तरह के क्रेडेंशियल मौजूद होते हैं.

इस मामले में, पुष्टि किए गए इस ईमेल क्रेडेंशियल का ऐक्सेस सिर्फ़ Google के पास होता है. इसे बॉटम शीट में देखा जा सकता है.

यह उन ईमेल पतों में से एक है जिससे उपयोगकर्ता ने डिवाइस पर लॉग इन किया है.

इस मामले में, Google ही डिजिटल क्रेडेंशियल जारी करता है और उसे सेव करता है.

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

अपने ऐप्लिकेशन में, इस जानकारी का इस्तेमाल करके अगली स्क्रीन पर जाएं. जैसे, पासकी बनाना या खाता बनाने के अन्य चरण.

उपयोगकर्ता के लिए, यह सहमति देने और फिर अगली स्क्रीन पर जाने जितना ही आसान है.

अगर आपको इसे आज़माना है, तो GitHub पर मौजूद हमारे सैंपल पर जाएं और इसे अपने डिवाइस पर इंस्टॉल करें.

कृपया इसे किसी फ़िज़िकल डिवाइस पर इस्तेमाल करें. ध्यान दें कि आपको अपने डिवाइस पर कम से कम एक Gmail खाते में साइन इन करना होगा.

इसलिए, अगर लोग दिलचस्पी दिखाते हैं, तो मैं थोड़ा और समय दूंगा.

ठीक है।

है न मज़ेदार?

ईमेल पते की पुष्टि करने के अलावा, उपयोगकर्ता की पुष्टि करने का कौनसा तरीका आपके दिमाग में आता है?

सही कहा, फ़ोन नंबर की पुष्टि करने की सुविधा.

Digital Credentials API, फ़ोन नंबर की पुष्टि करने की सुविधा भी देता है. इससे एसएमएस ओटीपी की समस्या और जोखिम से बचा जा सकता है.

फ़ोन नंबर की पुष्टि करने की सुविधा भी Digital Credentials API के ज़रिए काम करती है. इस मामले में, डिवाइस पर मौजूद फ़ोन नंबर का अनुरोध किया जाता है और उसे डिजिटल क्रेडेंशियल के तौर पर दिखाया जाता है.

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

यहां एक ऐप्लिकेशन का उदाहरण दिया गया है. इसमें ग्राहक, ऐप्लिकेशन को छोड़े बिना ही सिर्फ़ एक टैप करके अपना फ़ोन नंबर शेयर कर सकता है.

यह सेटअप कैसे काम करता है?

अगर हम इसे डिजिटल क्रेडेंशियल की पार्टियों से मैप करें, तो इस मामले में, क्रेडेंशियल जारी करने वाली इकाई, डिवाइस के सिम कार्ड पर मौजूद फ़ोन नंबर की मोबाइल और इंटरनेट सेवा देने वाली कंपनी है. वहीं, क्रेडेंशियल होल्डर, Android Telephony है.

जब पुष्टि करने वाला कोई व्यक्ति या ऐप्लिकेशन, उपयोगकर्ता के फ़ोन नंबर का अनुरोध करता है, तो उसे Digital Credentials API कॉल की मदद से, Google Telephony से वापस लाया जाता है.

आपको शायद यह जानने में दिलचस्पी हो कि बिलिंग कैसे काम करती है.

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

ऐसा तब होता है, जब फ़ोन नंबर को Google Telephony से वापस लाया जाता है. Google Telephony में, फ़ोन नंबर को एन्क्रिप्ट (सुरक्षित) करके सेव किया जाता है.

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

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

यहां हमने फ़ोन नंबर की पुष्टि करने की सुविधा का डेमो दिया है. इसमें Firebase को मोबाइल और इंटरनेट सेवा देने वाली कंपनियों के एग्रीगेटर के तौर पर इस्तेमाल किया गया है.

ऐप्लिकेशन, साइन-इन करने की प्रोसेस के दौरान उपयोगकर्ता का फ़ोन नंबर मांगता है.

इस उपयोगकर्ता के पास एक से ज़्यादा सिम कार्ड हैं. वह ऐप्लिकेशन के साथ शेयर करने के लिए, इनमें से कोई एक सिम कार्ड चुनता है.

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

इसके बाद, आपको अगली स्क्रीन पर वह फ़ोन नंबर दिखेगा जिसे वापस लाया गया है.

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

बस इसे पूरा होने दें, ताकि आप एक बार फिर से देख सकें कि यह कैसे पूरा होता है.

इसलिए, आपको उस आखिरी स्क्रीन पर फ़ोन नंबर दिखता है.

बस इतना ही!

आज हमने काफ़ी विषयों पर बात की.

हमने सबसे पहले Credential Manager का इस्तेमाल करके, पासकी को लागू करने की प्रोसेस को बेहतर बनाने और पासवर्ड के बिना साइन इन करने की सुविधा को बढ़ावा देने की कोशिश की.

Credential Manager और पासकी के बारे में ज़्यादा जानने और सैंपल के तौर पर उपलब्ध हमारे ऐप्लिकेशन ऐक्सेस करने के लिए, कृपया यहां दिए गए हमारे संसाधन देखें.

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

Play Store पर यह ज़रूरी शर्त अप्रैल 2027 से लागू होगी. इसलिए, कृपया इसे अपने कैलेंडर में नोट कर लें.

आखिर में, हमने डिजिटल क्रेडेंशियल के काम करने के तरीके और Android पर उनकी कुछ सबसे काम की सुविधाओं के बारे में बताया.

कॉन्टेंट के बारे में ज़्यादा जानकारी पाने और हमारे सैंपल ऐक्सेस करने के लिए, कृपया डिजिटल क्रेडेंशियल से जुड़े हमारे संसाधन यहां देखें.

आज हमने जो भी शेयर किया है वह लाइव है और आपके लिए उपलब्ध है.

Android पर पहचान की पुष्टि करने का नया तरीका आ गया है. यह पहले से ज़्यादा बेहतर है.

अपना समय देने के लिए धन्यवाद. मुझे पता है कि यह लंच का समय है, इसलिए कृपया बाहर जाकर खाने का आनंद लें.

पासकी या डिजिटल क्रेडेंशियल के बारे में सवाल पूछने के लिए, मुझसे या टॉम से संपर्क करने में संकोच न करें.

धन्यवाद.