तुमच्या ॲपमध्ये लॉगिन कसे जोडायचे: पासवर्ड, मॅजिक लिंक्स, Google आणि भूमिका

ॲपमध्ये लॉगिन जोडण्यासाठी एक पद्धत निवडा — ईमेल आणि पासवर्ड, मॅजिक लिंक्स (ईमेलने पाठवलेली एकदाच वापरता येणारी साइन-इन लिंक), किंवा "Sign in with Google" — आणि ती शून्यापासून न लिहिता सिद्ध auth लायब्ररी किंवा होस्टेड प्रदात्याने अंमलात आणा. मग प्रत्येक प्रकारचा वापरकर्ता काय करू शकतो ते ठरवा (भूमिका), आणि प्रत्येक पेज आणि API विनंतीवर ते सर्व्हरवर लागू करा. सेशन्सनी सुरक्षित कुकीज वापराव्यात, कालबाह्य व्हाव्यात, आणि लॉगआउटवर योग्यरित्या संपाव्यात.

हे मार्गदर्शक प्रत्येक निवड आणि कार्यरत लॉगिन आणि सुरक्षित लॉगिन यातील फरक करणारे तपशील सांगते. त्यामागच्या संकल्पनांसाठी, ऑथेंटिकेशन म्हणजे काय पहा.

आधी ठरवा: तुम्हाला लॉगिन हवेच आहे का?

लॉगिनमुळे अडथळा आणि जबाबदारी वाढते. तुम्हाला त्याची गरज असते जेव्हा:

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

मार्केटिंग साइट, सार्वजनिक निर्देशिका, किंवा फक्त तुम्हाला ईमेल पाठवणारा फॉर्म यासाठी तुम्हाला कदाचित लॉगिनची गरज नसेल. वेटलिस्टला खात्यांची गरज नसते; ईमेल फील्ड पुरेसे आहे.

चार सामान्य लॉगिन पद्धती

अनेक ॲप्स दोन एकत्र करतात: Google साइन-इन आणि ईमेल मॅजिक लिंक्स ही लोकप्रिय जोडी आहे, जी कोणतेही पासवर्ड न साठवता बहुतेक लोकांना व्यापते.

ईमेल आणि पासवर्ड

तुम्ही पासवर्ड देत असाल, तर या गोष्टी अनिवार्य आहेत:

• संथ पासवर्ड-हॅशिंग अल्गोरिदमने पासवर्ड हॅश करा. OWASP च्या पासवर्ड साठवणूक मार्गदर्शनात Argon2id ची शिफारस आहे, scrypt, bcrypt किंवा PBKDF2 पर्याय म्हणून. पासवर्ड कधीही साध्या मजकुरात किंवा जलद सामान्य हॅशने साठवू नका.
• पासवर्ड रीसेट यादृच्छिक, एकदाच वापरता येणारी, कालबाह्य होणारी लिंक वापरतात, सत्यापित ईमेलवर पाठवलेली.
• कोणत्या ईमेलचे खाते आहे हे उघड करू नका. "ही ईमेल नोंदणीकृत असल्यास, आम्ही रीसेट लिंक पाठवली आहे" हे "खाते सापडले नाही" यापेक्षा चांगले.
• लॉगिन आणि रीसेट प्रयत्नांवर रेट-लिमिट लावा, पासवर्ड अंदाजाला मंद करण्यासाठी.
• लांब पासवर्ड आणि पासवर्ड मॅनेजरना परवानगी द्या; विचित्र अक्षरांचे मिश्रण सक्तीचे करणारे नियम टाळा.

मॅजिक लिंक्स आणि एकवेळचे कोड

मॅजिक लिंक ही वापरकर्त्याला ईमेल केलेली साइन-इन लिंक आहे. ती क्लिक केल्यावर तो लॉग इन होतो. एकवेळचा कोड हीच कल्पना आहे, क्लिक करण्याऐवजी टाइप करून.

• लिंक्स आणि कोड लवकर कालबाह्य व्हावेत आणि फक्त एकदाच चालावेत.
• लिंकने ज्या डिव्हाइसवर क्लिक झाली तिथेच वापरकर्त्याला लॉग इन करावे, आणि टोकन लॉग्स किंवा ॲनालिटिक्स साधनांमध्ये राहू नये.
• तुम्हाला विश्वसनीय ईमेल पाठवणे आवश्यक आहे — पहा ॲपमधून ईमेल कसे पाठवायचे. Gmail आणि Outlook वर चाचणी करा, आणि स्पॅम फोल्डर तपासा.

Sign in with Google (आणि इतर OAuth प्रदाते)

"Sign in with 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 कॉल करण्यापासून थांबत नाही.
• मालकानुसार मर्यादित करा. "बुकिंग 123" मागणाऱ्या सदस्याला ती त्याचीच असेल तरच मिळावी.
• वापरकर्ते स्वतःला बढती देऊ शकत नाहीत. प्रोफाइल अपडेटमध्ये ब्राउझरकडून आलेले भूमिका फील्ड्स दुर्लक्षित करा.
• डीफॉल्ट प्रवेश नाकारलेला ठेवा. नवीन राउट्सना तुम्ही ठरवल्याशिवाय लॉगिन आवश्यक असावे.

दोन खात्यांनी तपासा: एकाने लॉग इन करा, एका नोंदीचा ID लक्षात ठेवा, मग दुसऱ्याने लॉग इन करून ती उघडण्याचा प्रयत्न करा. पूर्ण चाचणीसाठी आमची सुरक्षा चेकलिस्ट पहा.

सेशन सुरक्षा

लॉगिननंतर, ॲप वापरकर्त्याला सेशनद्वारे लक्षात ठेवते — सहसा कुकीद्वारे. OWASP च्या सेशन व्यवस्थापन मार्गदर्शनाची शिफारस:

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

ब्राउझरच्या local storage मध्ये लॉगिन टोकन्स साठवणे ट्यूटोरियलमध्ये सामान्य आहे, पण ते पेजवर चालणाऱ्या कोणत्याही स्क्रिप्टला उघड होतात; वेब ॲप्ससाठी सुरक्षित कुकीज सहसा चांगला डीफॉल्ट असतो.

आवश्यक गोष्टी कव्हर करणारा प्रॉम्प्ट

या ॲपमध्ये वापरकर्ता खाती जोडा. वापरकर्ते ईमेल आणि पासवर्डने, किंवा Google ने साइन अप आणि लॉग इन करू शकतील. कस्टम auth कोडऐवजी [लायब्ररी किंवा प्रदाता] वापरा. Argon2id किंवा bcrypt ने पासवर्ड हॅश करा. ईमेलद्वारे पासवर्ड रीसेट जोडा, एका तासात कालबाह्य होणाऱ्या एकदाच-वापराच्या लिंकसह. सेशन्स सुरक्षित, HttpOnly कुकीजमध्ये ठेवा. /dashboard आणि प्रत्येक /api राउटचे संरक्षण करा, जेणेकरून फक्त लॉग इन वापरकर्ते वापरू शकतील, आणि वापरकर्ते फक्त स्वतःचे प्रकल्प पाहू शकतील याची खात्री करा. "admin" भूमिका जोडा जी सर्व वापरकर्ते पाहू शकते; फक्त प्रशासक /admin पर्यंत पोहोचू शकतील, सर्व्हरवर तपासलेले.

मग चाचणी करा: साइन अप करा, लॉगआउट करा, लॉग इन करा, पासवर्ड रीसेट करा, लॉग आउट असताना खासगी URL वापरून पाहा, आणि दुसऱ्या वापरकर्त्याच्या नोंदीचा प्रयत्न करा.

AI-बांधलेल्या लॉगिनमधील सामान्य चुका

• संरक्षण फक्त पेजमध्ये. पेज लॉग आउट वापरकर्त्यांना रीडायरेक्ट करते, पण API कोणालाही डेटा परत करते.
• ब्राउझरमध्ये सिक्रेट्स. OAuth क्लायंट सिक्रेट्स आणि auth प्रदात्याच्या admin कीज सर्व्हरवर असाव्यात.
• प्रीव्ह्यू आणि लाइव्ह URL गोंधळणे. Google चा redirect URI किंवा रीसेट ईमेलची लिंक प्रीव्ह्यूकडे निर्देश करते, त्यामुळे प्रकाशित केल्यावर लॉगिन तुटते.
• ईमेल पडताळणी नसणे. कोणीही anyone@company.com म्हणून साइन अप करू शकतो. त्या पत्त्याशी जोडलेले काहीही देण्यापूर्वी ईमेल सत्यापित करा.
• फक्त यशस्वी मार्गाची चाचणी. चुकीचे पासवर्ड, कालबाह्य लिंक्स आणि दुसरे खाते वापरून पाहा.

Mythex मध्ये लॉगिन जोडणे

Mythex वर, तुमच्या ॲपच्या वापरकर्त्यांसाठी लॉगिन हे तुम्ही तुमच्या ॲपमध्ये जोडता — ते तुमच्या स्वतःच्या Mythex खात्यापेक्षा वेगळे आहे. Mythex अंगभूत auth उत्पादन देत नाही, त्यामुळे तुम्ही auth लायब्ररी किंवा प्रदाता आणि त्याच्या कीज आणता:

1. एक पद्धत निवडा — उदाहरणार्थ तुमच्या स्वतःच्या डेटाबेसमध्ये साठवलेला ईमेल आणि पासवर्ड, किंवा होस्टेड प्रदात्याचा SDK.
2. तुम्ही वापरकर्ते स्वतः साठवत असाल, तर ॲपला डेटाबेस लागतो; चॅटमध्ये मागा किंवा /database वापरा.
3. प्रदात्याच्या कीज प्रोजेक्ट सिक्रेट्समध्ये (/secrets किंवा प्रोजेक्ट सेटिंग्ज) ठेवा.
4. वरीलसारखा प्रॉम्प्ट वापरा, मग Preview मध्ये चाचणी करा. Google साइन-इनसाठी, तुमच्या प्रीव्ह्यू आणि प्रकाशित पत्त्यासाठी दोन्ही redirect URIs जोडा.

डॉक्समध्ये तुमच्या ॲपमध्ये लॉगिन जोडा पहा. तुम्ही पेड उत्पादन बांधत असाल, तर SaaS MVP कसा बांधायचा खाती आणि बिलिंग एकत्र कव्हर करते.

प्रश्न