Firebase Authentication उपयोगकर्ता ऑब्जेक्ट, उस उपयोगकर्ता खाते को दिखाता है जिसने आपके प्रोजेक्ट में किसी ऐप्लिकेशन के लिए साइन अप किया है. आम तौर पर, ऐप्लिकेशन में कई उपयोगकर्ता रजिस्टर होते हैं. साथ ही, किसी प्रोजेक्ट में मौजूद हर ऐप्लिकेशन, उपयोगकर्ता डेटाबेस को शेयर करता है.
उपयोगकर्ता इंस्टेंस, Firebase Authentication इंस्टेंस से अलग होते हैं. इसलिए, एक ही कॉन्टेक्स्ट में अलग-अलग उपयोगकर्ताओं के कई रेफ़रंस हो सकते हैं. साथ ही, उनके किसी भी तरीके को कॉल किया जा सकता है.
उपयोगकर्ता प्रॉपर्टी
Authentication उपयोगकर्ताओं के पास बुनियादी प्रॉपर्टी का एक तय सेट होता है. जैसे, यूनीक आईडी, प्राइमरी ईमेल पता, नाम, और फ़ोटो का यूआरएल. यह डेटा, प्रोजेक्ट के उपयोगकर्ता डेटाबेस में सेव होता है. इसे उपयोगकर्ता अपडेट कर सकता है (iOS, Android, वेब). उपयोगकर्ता ऑब्जेक्ट में सीधे तौर पर अन्य प्रॉपर्टी नहीं जोड़ी जा सकतीं. इसके बजाय, अतिरिक्त प्रॉपर्टी को Google Cloud Firestore जैसी किसी अन्य स्टोरेज सेवा में सेव किया जा सकता है.
जब कोई व्यक्ति पहली बार आपके ऐप्लिकेशन पर साइन अप करता है, तो उसकी प्रोफ़ाइल का डेटा अपने-आप भर जाता है. इसके लिए, उपलब्ध जानकारी का इस्तेमाल किया जाता है:
- अगर उपयोगकर्ता ने ईमेल पते और पासवर्ड से साइन अप किया है, तो सिर्फ़ मुख्य ईमेल पते की प्रॉपर्टी भरी जाती है
- अगर उपयोगकर्ता ने Google या Facebook जैसे फ़ेडरेटेड आइडेंटिटी प्रोवाइडर के साथ साइन अप किया है, तो प्रोवाइडर से मिली खाते की जानकारी का इस्तेमाल, उपयोगकर्ता की प्रोफ़ाइल भरने के लिए किया जाता है
- अगर उपयोगकर्ता ने आपके कस्टम ऑथराइज़ेशन सिस्टम से साइन अप किया है, तो आपको उपयोगकर्ता की प्रोफ़ाइल में वह जानकारी साफ़ तौर पर जोड़नी होगी जो आपको चाहिए
उपयोगकर्ता खाता बन जाने के बाद, उपयोगकर्ता की जानकारी को फिर से लोड किया जा सकता है. इससे, उपयोगकर्ता ने किसी दूसरे डिवाइस पर जो भी बदलाव किए होंगे वे शामिल हो जाएंगे.
साइन-इन करने की सुविधा देने वाली कंपनियां
अपने ऐप्लिकेशन में उपयोगकर्ताओं को साइन इन कराने के लिए, कई तरीकों का इस्तेमाल किया जा सकता है: ईमेल पता और पासवर्ड, फ़ेडरेटेड आइडेंटिटी प्रोवाइडर, और आपका कस्टम ऑथराइज़ेशन सिस्टम. किसी उपयोगकर्ता के खाते से एक से ज़्यादा साइन-इन के तरीके जोड़े जा सकते हैं. उदाहरण के लिए, कोई उपयोगकर्ता एक ही खाते में ईमेल पते और पासवर्ड का इस्तेमाल करके साइन इन कर सकता है या Google साइन-इन का इस्तेमाल करके साइन इन कर सकता है.
उपयोगकर्ता के इंस्टेंस, उपयोगकर्ता से जुड़े हर प्रोवाइडर को ट्रैक करते हैं. इसकी मदद से, किसी प्रोवाइडर से मिली जानकारी का इस्तेमाल करके, खाली प्रोफ़ाइल की प्रॉपर्टी अपडेट की जा सकती हैं. उपयोगकर्ताओं को मैनेज करना (iOS, Android, वेब) लेख पढ़ें.
मौजूदा उपयोगकर्ता
जब कोई उपयोगकर्ता साइन अप या साइन इन करता है, तो वह Auth इंस्टेंस का मौजूदा उपयोगकर्ता बन जाता है. यह इंस्टेंस, उपयोगकर्ता की स्थिति को सेव रखता है. इससे ब्राउज़र में पेज को रीफ़्रेश करने या ऐप्लिकेशन को फिर से शुरू करने पर, उपयोगकर्ता की जानकारी नहीं मिटती.
जब उपयोगकर्ता साइन आउट करता है, तो Auth इंस्टेंस, उपयोगकर्ता ऑब्जेक्ट का रेफ़रंस सेव करना बंद कर देता है. साथ ही, वह इसकी स्थिति को सेव नहीं करता. इसलिए, कोई मौजूदा उपयोगकर्ता नहीं होता. हालांकि, उपयोगकर्ता का इंस्टेंस पूरी तरह से काम करता रहता है: अगर आपने इसका रेफ़रंस सेव रखा है, तो अब भी उपयोगकर्ता के डेटा को ऐक्सेस और अपडेट किया जा सकता है.
उपयोगकर्ता का लाइफ़साइकल
Auth इंस्टेंस की मौजूदा स्थिति को ट्रैक करने का सुझाव दिया गया है. इसके लिए, लिसनर का इस्तेमाल करें. इन्हें JavaScript में "ऑब्ज़र्वर" भी कहा जाता है. Auth ऑब्जेक्ट में कोई भी बदलाव होने पर, Auth लिसनर को सूचना मिलती है. उपयोगकर्ताओं को मैनेज करना (iOS, Android, वेब) लेख पढ़ें.
ऑथ लिसनर को इन स्थितियों में सूचना मिलती है:
- Auth ऑब्जेक्ट का इनिशियलाइज़ेशन पूरा हो गया है और उपयोगकर्ता पहले से ही पिछले सेशन से साइन इन है या उसे आइडेंटिटी प्रोवाइडर के साइन-इन फ़्लो से रीडायरेक्ट किया गया है
- जब कोई उपयोगकर्ता साइन इन करता है (मौजूदा उपयोगकर्ता सेट होता है)
- जब कोई उपयोगकर्ता साइन आउट करता है (मौजूदा उपयोगकर्ता की वैल्यू शून्य हो जाती है)
- मौजूदा उपयोगकर्ता का ऐक्सेस टोकन रीफ़्रेश किया जाता है. ऐसा इन स्थितियों में हो सकता है:
- ऐक्सेस टोकन की समयसीमा खत्म हो गई है: यह एक आम समस्या है. रीफ़्रेश टोकन का इस्तेमाल, मान्य टोकन का नया सेट पाने के लिए किया जाता है.
- उपयोगकर्ता अपना पासवर्ड बदलता है: Authentication नए ऐक्सेस और रीफ़्रेश टोकन जारी करता है और पुराने टोकन को खत्म कर देता है. सुरक्षा के लिहाज़ से, इससे उपयोगकर्ता का टोकन अपने-आप खत्म हो जाता है और/या उसे हर डिवाइस से साइन आउट कर दिया जाता है.
- उपयोगकर्ता की फिर से पुष्टि की जाती है: कुछ कार्रवाइयों के लिए, यह ज़रूरी है कि उपयोगकर्ता के क्रेडेंशियल हाल ही में जारी किए गए हों. इन कार्रवाइयों में, खाता मिटाना, मुख्य ईमेल पता सेट करना, और पासवर्ड बदलना शामिल है. उपयोगकर्ता को साइन आउट करने और फिर से साइन इन करने के बजाय, उससे नए क्रेडेंशियल पाएं. इसके बाद, उपयोगकर्ता ऑब्जेक्ट के reauthenticate तरीके को नए क्रेडेंशियल पास करें.
उपयोगकर्ता के लिए खुद मैनेज की जा रही सेवा
डिफ़ॉल्ट रूप से, Firebase Authentication उपयोगकर्ताओं को एडमिन के हस्तक्षेप के बिना, साइन-अप करने और अपने खाते मिटाने की अनुमति देता है. कई मामलों में, इससे असली उपयोगकर्ताओं को आपके ऐप्लिकेशन या सेवा के बारे में पता चलता है. साथ ही, वे आसानी से इसका इस्तेमाल शुरू कर सकते हैं या बंद कर सकते हैं.
हालांकि, कुछ मामलों में आपको एडमिन से उपयोगकर्ताओं को मैन्युअल तरीके से या प्रोग्राम के हिसाब से बनाने की ज़रूरत पड़ सकती है. इसके लिए, Admin SDK या Firebase console का इस्तेमाल किया जा सकता है. ऐसे मामलों में, Firebase Authentication सेटिंग पेज पर जाकर, उपयोगकर्ता की कार्रवाइयां बंद की जा सकती हैं. इससे, असली उपयोगकर्ता खाते नहीं बना पाएंगे और न ही उन्हें मिटा पाएंगे. अगर मल्टी-टेंसी का इस्तेमाल किया जा रहा है, तो आपको हर किरायेदार के हिसाब से इन सुविधाओं को बंद करने के लिए, एचटीटीपी अनुरोध करना होगा.
अगर कोई व्यक्ति आपके सिस्टम में खाता बनाने या मिटाने की कोशिश करता है, तो Firebase Authentication सेवा गड़बड़ी का कोड दिखाएगी:
auth/admin-restricted-operation वेब एपीआई कॉल के लिए या ERROR_ADMIN_RESTRICTED_OPERATION Android और iOS के लिए. आपको अपने फ़्रंट-एंड पर गड़बड़ी को ठीक से हैंडल करना चाहिए. इसके लिए, उपयोगकर्ता से अपनी सेवा के लिए ज़रूरी कार्रवाइयां करने के लिए कहें.
पुष्टि करने वाले टोकन
Authentication की मदद से पुष्टि करने पर, आपको तीन तरह के पुष्टि करने वाले टोकन मिल सकते हैं:
| Authentication आईडी टोकन | जब कोई उपयोगकर्ता किसी ऐप्लिकेशन में साइन इन करता है, तब Authentication इस कुकी को बनाता है. ये टोकन, हस्ताक्षर किए गए JWT होते हैं. ये Firebase प्रोजेक्ट में किसी उपयोगकर्ता की पहचान को सुरक्षित तरीके से करते हैं. इन टोकन में उपयोगकर्ता की प्रोफ़ाइल की बुनियादी जानकारी होती है. इसमें उपयोगकर्ता की आईडी स्ट्रिंग भी शामिल होती है, जो Firebase प्रोजेक्ट के लिए यूनीक होती है. ऐसा इसलिए, क्योंकि आईडी टोकन की पुष्टि की जा सकती है. इसलिए, इन्हें बैकएंड सर्वर पर भेजा जा सकता है, ताकि साइन इन किए गए मौजूदा उपयोगकर्ता की पहचान की जा सके. |
| आइडेंटिटी प्रोवाइडर टोकन | इन्हें फ़ेडरेटेड आइडेंटिटी प्रोवाइडर (जैसे, Google और Facebook) बनाते हैं. इन टोकन के फ़ॉर्मैट अलग-अलग हो सकते हैं. हालांकि, ये अक्सर OAuth 2.0 ऐक्सेस टोकन होते हैं. ऐप्लिकेशन इन टोकन का इस्तेमाल करके यह पुष्टि करते हैं कि उपयोगकर्ताओं ने पहचान की पुष्टि करने वाली कंपनी के साथ सफलतापूर्वक पुष्टि कर ली है. इसके बाद, वे इन टोकन को ऐसे क्रेडेंशियल में बदल देते हैं जिनका इस्तेमाल Authentication सेवाएं कर सकती हैं. |
| Authentication कस्टम टोकन | इसे आपके कस्टम पुष्टि करने वाले सिस्टम ने बनाया है, ताकि उपयोगकर्ता आपके पुष्टि करने वाले सिस्टम का इस्तेमाल करके किसी ऐप्लिकेशन में साइन इन कर सकें. कस्टम टोकन, JWT होते हैं. इन्हें सेवा खाते की निजी कुंजी का इस्तेमाल करके साइन किया जाता है. ऐप्लिकेशन इन टोकन का इस्तेमाल उसी तरह करते हैं जिस तरह वे फ़ेडरेटेड आइडेंटिटी प्रोवाइडर से मिले टोकन का इस्तेमाल करते हैं. |
पुष्टि किए गए ईमेल पते
Authentication किसी ईमेल की पुष्टि तब करता है, जब वह इन दो शर्तों को पूरा करता हो:
- उपयोगकर्ता, Authentication की पुष्टि करने की प्रोसेस पूरी करता है
- इस ईमेल की पुष्टि, भरोसेमंद आइडेंटिटी प्रोवाइडर (आईडीपी) ने की है.
ऐसे IdP पर भरोसा नहीं किया जाता जो एक बार ईमेल की पुष्टि करते हैं, लेकिन उपयोगकर्ताओं को दोबारा पुष्टि किए बिना ईमेल पते बदलने की अनुमति देते हैं. ऐसे IdP को भरोसेमंद माना जाता है जिनके पास डोमेन का मालिकाना हक होता है या जिनके लिए हमेशा पुष्टि करना ज़रूरी होता है.
भरोसेमंद कंपनियां:
- Google (for @gmail.com addresses)
- Yahoo (for @yahoo.com addresses)
- Microsoft (for @outlook.com and @hotmail.com addresses)
- Apple (इसकी हमेशा पुष्टि की जाती है, क्योंकि खातों की हमेशा पुष्टि की जाती है और कई चरणों में पुष्टि करने की सुविधा चालू होती है)
भरोसेमंद नहीं मानी जाने वाली कंपनियां:
- GitHub
- Google, Yahoo, और Microsoft के लिए, उन डोमेन के लिए जो आइडेंटिटी प्रोवाइडर ने जारी नहीं किए हैं
- ईमेल / पासवर्ड, लेकिन ईमेल पते की पुष्टि नहीं की गई है
कुछ मामलों में, Authentication एक ही ईमेल पते का इस्तेमाल करके अलग-अलग प्रोवाइडर के साथ साइन इन करने पर, खातों को अपने-आप लिंक कर देगा. हालांकि, ऐसा सिर्फ़ तब हो सकता है, जब कुछ खास शर्तें पूरी की गई हों. इसकी वजह समझने के लिए, यह स्थिति देखें: कोई व्यक्ति @gmail.com खाते से Google में साइन इन करता है. इसके बाद, कोई धोखेबाज़ उसी @gmail.com पते का इस्तेमाल करके खाता बनाता है, लेकिन वह Facebook के ज़रिए साइन इन करता है. अगर ये दोनों खाते अपने-आप लिंक हो जाते हैं, तो धोखाधड़ी करने वाले व्यक्ति को उपयोगकर्ता के खाते का ऐक्सेस मिल जाएगा.
यहां कुछ ऐसे उदाहरण दिए गए हैं जिनमें हम खातों को अपने-आप लिंक कर देते हैं. साथ ही, कुछ ऐसे उदाहरण भी दिए गए हैं जिनमें हम गड़बड़ी का मैसेज दिखाते हैं और उपयोगकर्ता या डेवलपर को कार्रवाई करनी पड़ती है:
- जब कोई उपयोगकर्ता, किसी गैर-भरोसेमंद कंपनी की सेवा का इस्तेमाल करके साइन इन करता है. इसके बाद, उसी ईमेल पते से किसी दूसरी गैर-भरोसेमंद कंपनी की सेवा का इस्तेमाल करके साइन इन करता है. उदाहरण के लिए, Facebook के बाद GitHub. इससे खाता लिंक करने से जुड़ी गड़बड़ी होती है.
- उपयोगकर्ता, भरोसेमंद कंपनी के खाते से साइन इन करता है. इसके बाद, उसी ईमेल पते से किसी गैर-भरोसेमंद कंपनी के खाते से साइन इन करता है. उदाहरण के लिए, पहले Google और फिर Facebook. इससे खाता लिंक करने से जुड़ी गड़बड़ी होती है.
- जब कोई उपयोगकर्ता, किसी गैर-भरोसेमंद कंपनी के खाते से साइन इन करता है. इसके बाद, उसी ईमेल पते से किसी भरोसेमंद कंपनी के खाते से साइन इन करता है. उदाहरण के लिए, पहले Facebook से और फिर Google से साइन इन करना. भरोसेमंद प्रोवाइडर, गैर-भरोसेमंद प्रोवाइडर की जानकारी को बदल देता है. अगर उपयोगकर्ता Facebook से फिर से साइन इन करने की कोशिश करता है, तो एक गड़बड़ी होगी. इसके लिए, खाते को लिंक करना ज़रूरी होगा.
- उपयोगकर्ता किसी भरोसेमंद सेवा देने वाली कंपनी के खाते से साइन इन करता है. इसके बाद, उसी ईमेल पते से किसी दूसरी भरोसेमंद सेवा देने वाली कंपनी के खाते से साइन इन करता है. उदाहरण के लिए, Apple के बाद Google. दोनों कंपनियां बिना किसी गड़बड़ी के लिंक हो जाएंगी.
एडमिन SDK का इस्तेमाल करके, किसी ईमेल को मैन्युअल तरीके से 'पुष्टि हो गई' के तौर पर सेट किया जा सकता है. हालांकि, हमारा सुझाव है कि ऐसा सिर्फ़ तब करें, जब आपको पता हो कि उपयोगकर्ता के पास वाकई में उस ईमेल का मालिकाना हक है.