Authentication क्या है? Login, Session और OAuth आसान भाषा में
Authentication वह तरीका है जिससे ऐप यह पुष्टि करता है कि यूज़र कौन है। आमतौर पर वह किसी ऐसी चीज़ की जाँच करता है जो यूज़र को पता है (पासवर्ड), किसी ऐसी चीज़ की जो उसके पास है (उसके फ़ोन या ईमेल पर भेजा गया कोड), या किसी भरोसेमंद दूसरी सेवा की पहचान (जैसे “Google से साइन इन करें”)। एक बार यूज़र की पुष्टि हो जाए, तो ऐप उसे session या token से याद रखता है, ताकि उसे हर पेज पर दोबारा login न करना पड़े। वह पहचाना हुआ यूज़र क्या कर सकता है, यह तय करना एक अलग चरण है जिसे authorization कहते हैं।
AI से ऐप बनाते समय यह क्यों मायने रखता है
Login जोड़ना उन सबसे आम अनुरोधों में से एक है जो लोग AI बिल्डर से करते हैं, और उन्हीं में से एक जिसमें सूक्ष्म गलती आसानी से हो जाती है। Login पेज बनाना सरल है। असली मुश्किल उसके आसपास की हर चीज़ है:
- क्या पासवर्ड सुरक्षित रूप से सहेजे गए हैं?
- क्या हर निजी पेज और हर API endpoint वास्तव में जाँचता है कि माँग कौन रहा है?
- क्या login किया हुआ ग्राहक URL में संख्या बदलकर किसी और ग्राहक का डेटा देख सकता है?
- जब कोई अपना पासवर्ड भूल जाए तो क्या होता है?
कोई ऐप बाहर से पूरी तरह सुरक्षित दिख सकता है और फिर भी इन सभी में विफल हो सकता है। इसके चलते हिस्सों को समझने से आप सही सवाल पूछ पाते हैं और सही चीज़ें टेस्ट कर पाते हैं।
रोज़मर्रा की एक मिसाल
किसी होटल में चेक-इन करने की कल्पना कीजिए।
फ़्रंट डेस्क पर आप अपना ID दिखाते हैं। यही authentication है: यह साबित करना कि आप कौन हैं। फिर रिसेप्शनिस्ट आपको एक key card देता है। वह कार्ड आपका session है: पूरे प्रवास में आपको दोबारा ID नहीं दिखानी पड़ती; आप बस कार्ड दिखाते हैं।
वह कार्ड आपके कमरे, जिम और आपकी मंज़िल की लिफ़्ट को खोलता है, लेकिन दूसरे मेहमानों के कमरों या स्टाफ़ ऑफ़िस को नहीं। यही authorization है: आपकी पहचान किस चीज़ तक पहुँच सकती है। कार्ड खो जाए, तो होटल डेस्क पर उसे निष्क्रिय कर सकता है (session रद्द करना)। चेक-आउट करने पर वह काम करना बंद कर देता है (logout या मियाद खत्म होना)।
“Google से साइन इन करें” ऐसा है जैसे होटल खुद आपका ID जाँचने के बजाय एक भरोसेमंद साथी का पत्र स्वीकार कर ले, जिसमें लिखा हो “यही यह व्यक्ति है।”
मुख्य login तरीके
| तरीका | यह कैसे काम करता है | फ़ायदे | नुकसान |
|---|---|---|---|
| ईमेल + पासवर्ड | यूज़र पासवर्ड चुनता है; ऐप उसका hash सहेजता है | परिचित, किसी बाहरी निर्भरता के बिना | hash को सुरक्षित रूप से सहेजना और reset संभालना ज़रूरी है |
| Magic link / एक बार का कोड | ऐप ईमेल से एक लिंक या कोड भेजता है जो यूज़र को login करा देता है | लीक या भूलने के लिए कोई पासवर्ड नहीं | ईमेल डिलीवरी पर निर्भर; login धीमा |
| सोशल login (OAuth / OpenID Connect) | यूज़र Google, Apple, GitHub आदि से साइन इन करता है | यूज़र के लिए तेज़; आपके द्वारा कोई पासवर्ड नहीं सहेजा जाता | हर प्रदाता के साथ अलग सेटअप; जिनके पास वे अकाउंट नहीं, उनके लिए नहीं |
| होस्टेड auth प्रदाता | Clerk, Auth0 या Supabase Auth जैसी सेवा sign-up, login और reset संभालती है | आपके लिए सुरक्षा का कम काम | बड़े पैमाने पर मासिक खर्च; एक और निर्भरता |
| Multi-factor (MFA / 2FA) | पहली जाँच के बाद दूसरी जाँच, जैसे authenticator ऐप का कोड | सेंध लगाना कहीं ज़्यादा मुश्किल | थोड़ी और झंझट |
पासवर्ड कैसे सहेजे जाने चाहिए
सुरक्षित ऐप आपका असली पासवर्ड कभी नहीं सहेजता। इसके बजाय वह एक hash सहेजता है: एक ऐसे one-way फ़ंक्शन का नतीजा जो पासवर्ड को एक तय स्ट्रिंग में बदल देता है। Login करते समय ऐप आपके टाइप किए हुए को hash करता है और नतीजे की तुलना सहेजे गए hash से करता है।
दो बारीकियाँ इसे सुरक्षित बनाती हैं:
- Salt: हर पासवर्ड में hash करने से पहले जोड़ा गया एक यादृच्छिक मान, ताकि एक ही पासवर्ड वाले दो लोगों के hash अलग हों, और पहले से बनी लुकअप टेबल बेकार हो जाएँ।
- पासवर्ड के लिए बना धीमा एल्गोरिदम: जैसे Argon2, bcrypt या scrypt। MD5 या SHA-256 जैसे सामान्य hash अकेले में बहुत तेज़ हैं; हमलावर अरबों अनुमान लगा सकते हैं।
Hashing, encryption जैसा नहीं है। Encrypt किया गया डेटा key से decrypt हो सकता है; पासवर्ड hash को उलटा ही न जा सके, ऐसा डिज़ाइन किया जाता है।
Sessions बनाम tokens
Login के बाद ऐप को हर अनुरोध पर आपको पहचानना होता है। इसके दो आम तरीके हैं।
| Session (cookie) | Token (जैसे JWT) | |
|---|---|---|
| ब्राउज़र के पास क्या है | cookie में एक यादृच्छिक session ID | एक signed token, जिसमें यूज़र की जानकारी और मियाद होती है |
| Login की स्थिति कहाँ रहती है | सर्वर पर, डेटाबेस या स्टोर में | token के भीतर ही |
| किसी को हर जगह logout करना | आसान: सर्वर पर session हटाएँ | कठिन: block-list न रखें तो token मियाद खत्म होने तक मान्य रहता है |
| आम इस्तेमाल | पारंपरिक वेब ऐप्स | APIs, मोबाइल ऐप्स, एक-दूसरे से बात करने वाली सेवाएँ |
Cookies के लिए तीन सेटिंग मायने रखती हैं: HttpOnly (पेज का JavaScript cookie नहीं पढ़ सकता), Secure (सिर्फ़ HTTPS पर भेजी जाती है) और SameSite (दूसरी साइटों के अनुरोधों पर उसे भेजने को सीमित करती है)। Tokens को ब्राउज़र के localStorage में रखना आम है, लेकिन इससे वे पेज पर चलने वाली किसी भी स्क्रिप्ट के सामने खुल जाते हैं।
OAuth और “Google से साइन इन करें”
OAuth 2.0 सौंपी गई authorization का मानक है: यह किसी ऐप को किसी दूसरी सेवा पर आपके अकाउंट तक सीमित पहुँच देने देता है, जैसे आपका Google Calendar पढ़ना, वह भी आपका Google पासवर्ड देखे बिना। आपको Google पर भेजा जाता है, आप खास अनुमतियों (जिन्हें scopes कहते हैं) को मंज़ूरी देते हैं, और Google ऐप को सिर्फ़ उन्हीं अनुमतियों के लिए एक token देता है।
अकेले OAuth को पहुँच देने के लिए बनाया गया था, यह बताने के लिए नहीं कि आप कौन हैं। OpenID Connect (OIDC) OAuth 2.0 के ऊपर की एक परत है जो identity जोड़ती है, और “Google से साइन इन करें” या “Apple से साइन इन करें” इसी का इस्तेमाल करते हैं। इसे सेट करने के लिए आप अपने ऐप को प्रदाता के पास पंजीकृत करते हैं और एक client ID व client secret पाते हैं; secret आपके सर्वर पर ही रहता है।
एक उदाहरण: क्लाइंट पोर्टल के लिए login
मान लीजिए आप एक ऐसा पोर्टल बना रहे हैं जहाँ एक डिज़ाइन एजेंसी के ग्राहक अपने प्रोजेक्ट और इनवॉइस देखते हैं।
- Authentication: ग्राहक ईमेल और magic link से login करते हैं, इसलिए संभालने के लिए कोई पासवर्ड नहीं। एजेंसी का स्टाफ़ Google Workspace अकाउंट से login करता है।
- Roles: हर यूज़र की एक भूमिका है:
clientयाstaff। - Authorization नियम:
| कार्य | ग्राहक | स्टाफ़ |
|---|---|---|
| अपनी कंपनी के प्रोजेक्ट देखना | हाँ | हाँ |
| दूसरी कंपनियों के प्रोजेक्ट देखना | नहीं | हाँ |
| किसी प्रोजेक्ट में फ़ाइल अपलोड करना | सिर्फ़ अपने प्रोजेक्ट | हाँ |
| इनवॉइस को भुगतान किया हुआ चिह्नित करना | नहीं | हाँ |
- यह कहाँ लागू होता है: सर्वर पर, हर अनुरोध के लिए। सर्वर login यूज़र को खोजता है, फिर सिर्फ़ वही प्रोजेक्ट लौटाता है जहाँ
project.company_idयूज़र की कंपनी से मेल खाता है। “Mark paid” बटन छुपाना काफ़ी नहीं है; endpoint को खुद मना करना होगा।
आम शब्दों की व्याख्या
| शब्द | मतलब |
|---|---|
| Authentication (AuthN) | यह पुष्टि करना कि कोई कौन है। |
| Authorization (AuthZ) | यह तय करना कि वह क्या कर सकता है। |
| Session | अनुरोधों के बीच ऐप का यह याद रखना कि आप login हैं। |
| Cookie | एक छोटा डेटा टुकड़ा जिसे ब्राउज़र हर अनुरोध के साथ साइट को वापस भेजता है। |
| JWT | JSON Web Token: एक signed, संक्षिप्त token जिसमें user ID और मियाद जैसे दावे होते हैं। |
| Role / permission | admin या member जैसे लेबल जो पहुँच तय करते हैं। |
| MFA / 2FA | दूसरा प्रमाण माँगना, जैसे authenticator ऐप का कोड। |
| SSO | Single sign-on: कई ऐप्स के लिए एक ही login (अक्सर कंपनी अकाउंट से)। |
| 401 बनाम 403 | “आप कौन हैं?” (पहचान नहीं हुई) बनाम “आप यह नहीं कर सकते” (अनुमति नहीं)। |
आम गलतियाँ और गलतफ़हमियाँ
- सिर्फ़ पेज में अनुमति जाँचना। अगर ब्राउज़र बटन छुपाता है पर API नहीं जाँचता, तो कोई भी सीधे API को कॉल कर सकता है।
- URL के ID पर भरोसा करना।
/invoices/1042को जाँचना होगा कि इनवॉइस 1042 login यूज़र का है। - अपनी क्रिप्टो खुद बनाना। जानी-मानी लाइब्रेरी या प्रदाता इस्तेमाल करें; AI को hashing की अपनी योजना न गढ़ने दें।
- कमज़ोर पासवर्ड reset। Reset लिंक एक बार इस्तेमाल होने वाले, जल्दी खत्म होने वाले हों और यह न बताएँ कि ईमेल का अकाउंट है या नहीं।
- अपने login को बिल्डर के login के साथ मिलाना। आपके ऐप के यूज़र उस टूल पर आपके अकाउंट से अलग हैं जिससे आप ऐप बनाते हैं।
- Login पर rate limiting नहीं। उसके बिना हमलावर पासवर्ड अनगिनत बार आज़मा सकते हैं।
अपने AI बिल्डर से क्या माँगें
- “[जानी-मानी लाइब्रेरी या प्रदाता] से sign-up और login जोड़ो। कस्टम पासवर्ड hashing मत लिखो।”
- “पासवर्ड bcrypt या Argon2 से hash करके सहेजो।”
- “session के लिए HttpOnly, Secure cookies इस्तेमाल करो।”
- “दो roles जोड़ो: admin और member। हर endpoint की सूची दो और बताओ कौन सी roles उसे बुला सकती हैं।”
- “सर्वर पर लागू करो कि यूज़र सिर्फ़ अपने रिकॉर्ड देख और बदल सकें। फिर दिखाओ कि तुमने यह कैसे जाँचा।”
- “ऐसा पासवर्ड reset जोड़ो जिसमें एक बार चलने वाले लिंक हों और एक घंटे में खत्म हो जाएँ।”
- “Login की कोशिशों पर rate limit लगाओ।”
फिर खुद टेस्ट करें: दो अकाउंट बनाएँ और एक के login रहते हुए दूसरे का डेटा पाने की कोशिश करें। ऐप में login जोड़ने की गाइड और AI से बने ऐप्स का सुरक्षा चेकलिस्ट इससे आगे जाते हैं।
Mythex में authentication
Mythex आपके ऐप के यूज़र्स के लिए कोई अंतर्निर्मित auth प्रोडक्ट नहीं देता; आप एक तरीका चुनते हैं, जैसे आपके प्रोजेक्ट के डेटाबेस में सहेजे गए ईमेल और पासवर्ड, या किसी होस्टेड प्रदाता का SDK, और एजेंट से उसे जोड़ने को कहते हैं। प्रदाता की keys चैट में नहीं, प्रोजेक्ट सीक्रेट्स में जाती हैं। यह उस तरीके से अलग है जिससे आप खुद Mythex में साइन इन करते हैं। अपने ऐप में login जोड़ने पर दस्तावेज़ की रेसिपी में एक starter prompt है जिसे आप अपना सकते हैं, और API क्या है समझाता है कि वे सर्वर-साइड जाँचें कहाँ रहती हैं।
सवाल
Authentication और authorization में क्या फ़र्क है?
Authentication जाँचता है कि आप कौन हैं, जैसे आपका पासवर्ड सत्यापित करके। Authorization तय करता है कि आपको पहचाने जाने के बाद क्या करने की अनुमति है, जैसे आप एडमिन पेज देख सकते हैं या किसी और की बुकिंग बदल सकते हैं। ऐप्स को दोनों चाहिए।
OAuth क्या है?
OAuth 2.0 एक मानक है जो किसी ऐप को आपका पासवर्ड देखे बिना किसी दूसरी सेवा पर आपके अकाउंट तक सीमित पहुँच देने देता है। 'Google से साइन इन करें' OpenID Connect इस्तेमाल करता है, जो OAuth 2.0 के ऊपर बनी एक identity परत है, ताकि ऐप Google से जान सके कि आप कौन हैं।
क्या मेरे ऐप को पासवर्ड सहेजने चाहिए?
पढ़े जा सकने वाले रूप में कभी नहीं। अगर आप ईमेल और पासवर्ड से login करते हैं, तो पासवर्ड को salt के साथ hash करके सहेजना होगा, वह भी पासवर्ड के लिए बनाए गए धीमे एल्गोरिदम से, जैसे Argon2 या bcrypt। कई ऐप्स होस्टेड auth प्रदाता, सोशल login या ईमेल मैजिक लिंक इस्तेमाल करके इस समस्या से बच जाते हैं।
मेरे ऐप को session या token में से कौन सा इस्तेमाल करना चाहिए?
दोनों काम करते हैं। Session login की स्थिति सर्वर पर रखता है और ब्राउज़र को cookie में एक यादृच्छिक ID देता है, जिसे रद्द करना आसान है। JWT जैसा token खुद signed जानकारी लेकर चलता है, जो APIs और मोबाइल क्लाइंट्स के लिए ठीक है, पर मियाद खत्म होने से पहले उसे रद्द करना मुश्किल है। आम वेब ऐप के लिए cookie-आधारित session एक भरोसेमंद डिफ़ॉल्ट है।