अपनी ऐप में लॉगिन कैसे जोड़ें: पासवर्ड, मैजिक लिंक, Google और रोल

अपनी ऐप में लॉगिन जोड़ने के लिए एक तरीका चुनें: ईमेल और पासवर्ड, मैजिक लिंक (ईमेल से भेजा गया एक बार चलने वाला साइन-इन लिंक), या "Google से साइन इन"। फिर उसे किसी जाँचे-परखे ऑथ लाइब्रेरी या होस्टेड प्रदाता से लागू करें, शून्य से न लिखें। इसके बाद तय करें कि हर तरह का यूज़र क्या कर सकता है (रोल), और यह हर पेज और API रिक्वेस्ट पर सर्वर पर लागू करें। सेशन सुरक्षित कुकी इस्तेमाल करें, उनकी समय सीमा हो, और लॉग आउट पर ठीक से खत्म हों।

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

पहले तय करें: क्या आपको लॉगिन चाहिए भी?

लॉगिन से झंझट और ज़िम्मेदारी दोनों बढ़ती हैं। आपको इसकी ज़रूरत तब है जब:

• यूज़र्स का निजी डेटा हो (उनकी बुकिंग, दस्तावेज़, इनवॉइस)
• यूज़र ऐसी चीज़ें बदल सकें जो दूसरे देखेंगे
• आप एक्सेस के लिए शुल्क लेते हों
• अलग-अलग लोगों को अलग अनुमतियाँ चाहिए (मालिक बनाम स्टाफ़ बनाम ग्राहक)

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

चार आम लॉगिन तरीके

कई ऐप दो को मिलाती हैं: Google साइन इन के साथ ईमेल मैजिक लिंक एक लोकप्रिय जोड़ी है, जो बिना कोई पासवर्ड स्टोर किए ज़्यादातर लोगों को कवर करती है।

ईमेल और पासवर्ड

अगर आप पासवर्ड देते हैं, तो ये ज़रूरी हैं:

• पासवर्ड को धीमे पासवर्ड-हैशिंग एल्गोरिदम से हैश करें। OWASP की पासवर्ड स्टोरेज गाइडेंस Argon2id की सलाह देती है, और विकल्प के रूप में scrypt, bcrypt या PBKDF2। पासवर्ड कभी सादे टेक्स्ट में या तेज़ सामान्य हैश में स्टोर न करें।
• पासवर्ड रीसेट एक रैंडम, एक बार चलने वाले और खत्म होने वाले लिंक से हों, जो सत्यापित ईमेल पर भेजा जाए।
• यह न बताएँ कि किन ईमेल से अकाउंट हैं। "अगर वह ईमेल रजिस्टर्ड है, तो हमने रीसेट लिंक भेज दिया है" बेहतर है, "कोई अकाउंट नहीं मिला" की तुलना में।
• लॉगिन और रीसेट कोशिशों पर रेट लिमिट लगाएँ, ताकि पासवर्ड अनुमान लगाने की रफ़्तार धीमी हो।
• लंबे पासवर्ड और पासवर्ड मैनेजर की अनुमति दें; अजीब अक्षरों के मिश्रण वाले नियम छोड़ दें।

मैजिक लिंक और एक बार के कोड

मैजिक लिंक यूज़र को ईमेल किया गया साइन-इन लिंक है। उस पर क्लिक करने से वह लॉग इन हो जाता है। एक बार का कोड वही विचार है, बस क्लिक की जगह टाइप करके डाला जाता है।

• लिंक और कोड जल्दी खत्म होते हैं और सिर्फ़ एक बार काम करते हैं।
• लिंक उसी डिवाइस पर लॉग इन करे जहाँ यूज़र ने क्लिक किया, और टोकन लॉग या एनालिटिक्स टूल में न रहे।
• आपको भरोसेमंद ईमेल भेजना चाहिए; देखें अपनी ऐप से ईमेल कैसे भेजें। Gmail और Outlook पर टेस्ट करें, और स्पैम फ़ोल्डर जाँचें।

Google से साइन इन (और दूसरे OAuth प्रदाता)

"Google से साइन इन" OAuth और OpenID Connect इस्तेमाल करता है: Google पक्का करता है कि यूज़र कौन है, और आपकी ऐप को उसका ईमेल और नाम बताता है। सितंबर 2026 तक का सेटअप Google Cloud Console के Google Auth Platform सेक्शन में होता है:

1. एक प्रोजेक्ट बनाएँ या चुनें, और Branding पेज भरें, यानी कन्सेंट स्क्रीन पर यूज़र्स को क्या दिखता है (ऐप का नाम, सपोर्ट ईमेल, लोगो)।
2. Clients पेज पर "Web application" प्रकार का क्लाइंट बनाएँ।
3. अपने authorized JavaScript origins और redirect URIs जोड़ें, यानी वे सटीक पते जिन पर आपकी ऐप चलती है और जहाँ Google साइन-इन के बाद यूज़र को वापस भेजता है।
4. क्लाइंट ID और क्लाइंट सीक्रेट को अपनी ऐप के सीक्रेट्स में रखें।

Google के OAuth डॉक्यूमेंटेशन के अनुसार आम तौर पर ये चीज़ें गलत होती हैं:

• redirect_uri_mismatch: redirect पता बिल्कुल मेल खाना चाहिए, जिसमें http बनाम https, बड़े-छोटे अक्षर और आखिरी slash भी शामिल हैं। अपने प्रीव्यू पते के लिए एक और लाइव डोमेन के लिए एक जोड़ें।
• HTTPS ज़रूरी है: redirect URIs HTTPS पर होने चाहिए, सिर्फ़ डेवलपमेंट में localhost के अलावा।
• state पैरामीटर वापस लौटने पर जाँचा जाना चाहिए, ताकि cross-site request forgery से बचाव हो। अच्छी लाइब्रेरी यह आपके लिए करती हैं।

अगर आप सिर्फ़ बुनियादी साइन-इन जानकारी (नाम, ईमेल, प्रोफ़ाइल) माँगते हैं, तो Google कहता है कि ऐप वेरिफ़िकेशन अनिवार्य नहीं है। यूज़र्स के Gmail, Drive या Calendar की पहुँच माँगना अलग बात है, और उसके लिए वेरिफ़िकेशन चाहिए।

खुद बनाएँ या प्रदाता इस्तेमाल करें?

पहले दो दोनों ठीक हैं। होस्टेड प्रदाता आपके लिए ज़्यादा संभालते हैं, लेकिन एक निर्भरता जोड़ते हैं और कभी-कभी सक्रिय यूज़र के हिसाब से शुल्क लेते हैं; मौजूदा कीमतें उनकी साइट पर जाँचें। लाइब्रेरी सब कुछ आपके डेटाबेस में रखती हैं, लेकिन सही कॉन्फ़िगर करने की ज़िम्मेदारी आपकी रहती है। जो भी चुनें, AI से उसी का इस्तेमाल करवाएँ, पासवर्ड या सेशन का तर्क हाथ से न लिखवाएँ।

रोल और अनुमतियाँ

लॉगिन आपको बताता है कि कोई कौन है। अनुमतियाँ तय करती हैं कि वह क्या कर सकता है। शुरुआत में इसे सरल रखें:

रोल के नामों से ज़्यादा ज़रूरी नियम ये हैं:

• हर बार सर्वर पर जाँचें। पेज पर बटन छिपाने से कोई API को सीधे कॉल करने से नहीं रुकता।
• मालिक के आधार पर सीमित करें। सदस्य "booking 123" माँगे तो वही मिलना चाहिए जो उसका अपना है।
• यूज़र खुद को प्रमोट न कर सकें। प्रोफ़ाइल अपडेट में ब्राउज़र से आए रोल फ़ील्ड को अनदेखा करें।
• डिफ़ॉल्ट रूप से कोई एक्सेस न दें। नए रूट के लिए लॉगिन ज़रूरी हो, जब तक आप अलग तय न करें।

दो अकाउंट से टेस्ट करें: एक से लॉग इन करें, किसी रिकॉर्ड का ID नोट करें, फिर दूसरे से लॉग इन करके उसे खोलने की कोशिश करें। पूरा टेस्ट हमारी सुरक्षा चेकलिस्ट में है।

सेशन सुरक्षा

लॉगिन के बाद ऐप सेशन के ज़रिए यूज़र को याद रखती है, आम तौर पर एक कुकी से। OWASP की सेशन मैनेजमेंट गाइडेंस यह सुझाती है:

• सेशन कुकी Secure (सिर्फ़ HTTPS), HttpOnly (पेज स्क्रिप्ट से न पढ़ी जा सके) और SameSite के साथ सेट हों
• लॉगिन पर नया सेशन ID जारी हो, और अधिकार बदलने पर फिर से
• निष्क्रियता की समय सीमा और अधिकतम कुल अवधि हो, सर्वर पर लागू
• लॉग आउट सर्वर पर सेशन खत्म करे, सिर्फ़ कुकी डिलीट न करे
• यूज़र के पासवर्ड बदलने पर सेशन अमान्य हों

ट्यूटोरियल में लॉगिन टोकन ब्राउज़र के local storage में रखना आम है, लेकिन इससे वे पेज पर चलने वाली किसी भी स्क्रिप्ट को दिख जाते हैं; वेब ऐप के लिए सुरक्षित कुकी आम तौर पर बेहतर डिफ़ॉल्ट है।

ज़रूरी बातें कवर करने वाला प्रॉम्प्ट

इस ऐप में यूज़र अकाउंट जोड़ो। यूज़र ईमेल और पासवर्ड से, या Google से साइन अप और लॉग इन कर सकें। कस्टम ऑथ कोड की जगह [लाइब्रेरी या प्रदाता] इस्तेमाल करो। पासवर्ड Argon2id या bcrypt से हैश करो। ईमेल से पासवर्ड रीसेट जोड़ो, जिसमें एक बार चलने वाला लिंक हो जो एक घंटे में खत्म हो। सेशन सुरक्षित, HttpOnly कुकी में रखो। /dashboard और हर /api रूट को सुरक्षित करो ताकि सिर्फ़ लॉग इन यूज़र उन्हें इस्तेमाल कर सकें, और पक्का करो कि यूज़र सिर्फ़ अपने प्रोजेक्ट देखें। एक "admin" रोल जोड़ो जो सभी यूज़र देख सके; सिर्फ़ एडमिन /admin तक पहुँचें, और यह सर्वर पर जाँचा जाए।

फिर टेस्ट करें: साइन अप करें, लॉग आउट करें, लॉग इन करें, पासवर्ड रीसेट करें, लॉग आउट अवस्था में निजी URL आज़माएँ, और दूसरे यूज़र का रिकॉर्ड आज़माएँ।

AI से बने लॉगिन में आम गलतियाँ

• सुरक्षा सिर्फ़ पेज में। पेज लॉग आउट यूज़र को रीडायरेक्ट करता है, लेकिन API हर किसी को डेटा लौटाता है।
• सीक्रेट्स ब्राउज़र में। OAuth क्लाइंट सीक्रेट और ऑथ प्रदाता की एडमिन keys सर्वर पर होनी चाहिए।
• प्रीव्यू और लाइव URL गड़बड़ होना। Google का redirect URI या रीसेट ईमेल का लिंक प्रीव्यू की ओर इशारा करता है, तो पब्लिश के बाद लॉगिन टूट जाता है।
• ईमेल सत्यापन नहीं। कोई भी anyone@company.com बनकर साइन अप कर सकता है। उस पते से जुड़ी कोई चीज़ देने से पहले ईमेल सत्यापित करें।
• सिर्फ़ सही रास्ते की टेस्टिंग। गलत पासवर्ड, खत्म हो चुके लिंक और दूसरे अकाउंट आज़माएँ।

Mythex में लॉगिन जोड़ना

Mythex पर, आपकी ऐप के यूज़र्स के लिए लॉगिन आप अपनी ऐप में जोड़ते हैं — यह आपके अपने Mythex अकाउंट से अलग है। Mythex कोई अंतर्निहित ऑथ प्रोडक्ट नहीं देता, इसलिए आप एक ऑथ लाइब्रेरी या प्रदाता और उसकी keys लाते हैं:

1. एक तरीका चुनें — जैसे आपके अपने डेटाबेस में स्टोर होने वाला ईमेल और पासवर्ड, या किसी होस्टेड प्रदाता का SDK।
2. अगर यूज़र आप खुद स्टोर करते हैं, तो ऐप को डेटाबेस चाहिए; चैट में माँगें या /database इस्तेमाल करें।
3. प्रदाता की keys प्रोजेक्ट सीक्रेट्स में रखें (/secrets या प्रोजेक्ट सेटिंग्स)।
4. ऊपर जैसा प्रॉम्प्ट इस्तेमाल करें, फिर प्रीव्यू में टेस्ट करें। Google साइन इन के लिए अपने प्रीव्यू और पब्लिश्ड पते, दोनों के redirect URIs जोड़ें।

डॉक्स में अपनी ऐप में लॉगिन जोड़ें देखें। अगर आप पेड प्रोडक्ट बना रहे हैं, तो SaaS MVP कैसे बनाएँ में अकाउंट और बिलिंग एक साथ समझाए गए हैं।

सवाल