Authentication म्हणजे काय? Login, Sessions आणि OAuth स्पष्ट

Authentication म्हणजे ॲप वापरकर्ता कोण आहे हे पडताळणे — सहसा त्याला माहीत असलेली गोष्ट तपासून (पासवर्ड), त्याच्याकडे असलेली गोष्ट तपासून (फोन किंवा email वर पाठवलेला code), किंवा दुसऱ्या विश्वासार्ह सेवेकडून मिळालेली ओळख तपासून (जसे "Google सह साइन इन"). एकदा वापरकर्ता authenticate झाला की, ॲप त्याला session किंवा token द्वारे लक्षात ठेवते, म्हणजे प्रत्येक पेजवर त्याला पुन्हा login करावे लागत नाही. त्या ओळखलेल्या वापरकर्त्याला काय करण्याची परवानगी आहे हे ठरवणे ही वेगळी पायरी असते, जिला authorization म्हणतात.

AI सह बनवताना हे का महत्त्वाचे आहे

Login जोडणे ही लोक AI बिल्डरला सर्वात सामान्यपणे मागत असलेल्या गोष्टींपैकी एक आहे, आणि ती सूक्ष्मपणे चुकीची होणे सोपे आहे. Login पेज तयार करणे सोपे आहे. कठीण भाग म्हणजे त्याभोवतीचे सर्व काही:

पासवर्ड सुरक्षितपणे साठवले आहेत का?
प्रत्येक खाजगी पेज आणि प्रत्येक API endpoint खरोखर तपासतो का की कोण विचारत आहे?
Login केलेला ग्राहक URL मधील संख्या बदलून दुसऱ्या ग्राहकाचा डेटा पाहू शकतो का?
कोणी पासवर्ड विसरल्यावर काय होते?

एखादे ॲप वरून पूर्णपणे सुरक्षित दिसू शकते आणि तरीही हे सर्व अपयशी ठरू शकते. भागांची कार्यपद्धती समजल्याने तुम्हाला योग्य प्रश्न विचारता येतात आणि योग्य गोष्टी तपासता येतात.

दैनंदिन उदाहरण

हॉटेलमध्ये चेक-इन करण्याचा विचार करा.

फ्रंट डेस्कवर तुम्ही ओळखपत्र दाखवता. ही authentication आहे: तुम्ही कोण आहात हे सिद्ध करणे. मग रिसेप्शनिस्ट तुम्हाला key card देते. ती card म्हणजे तुमचे session: मुक्कामाच्या उर्वरित काळात तुम्हाला पुन्हा ओळखपत्र दाखवावे लागत नाही; फक्त card टॅप करता.

Card तुमची खोली, जिम आणि तुमच्या मजल्यापर्यंतची लिफ्ट उघडते — पण इतर पाहुण्यांच्या खोल्या किंवा स्टाफ ऑफिस नाही. ही authorization: तुमची ओळख कोणत्या गोष्टींपर्यंत पोहोचू शकते. Card हरवल्यास हॉटेल डेस्कवर ती निष्क्रिय करू शकते (session रद्द करणे). चेक-आउट केल्यावर ती चालणे थांबते (logout किंवा मुदत संपणे).

"Google सह साइन इन" म्हणजे हॉटेलने तुमचे ओळखपत्र स्वतः तपासण्याऐवजी एका विश्वासू भागीदाराकडून "हा माणूस हाच आहे" असे पत्र स्वीकारणे.

पद्धत	ती कशी काम करते	फायदे	तोटे
Email + पासवर्ड	वापरकर्ता पासवर्ड निवडतो; ॲप त्याचा hash साठवते	परिचित, बाह्य अवलंबित्व नाही	Hash सुरक्षित साठवावे लागतात आणि reset हाताळावे लागते
Magic link / एकवेळचा code	ॲप email वर link किंवा code पाठवते जो वापरकर्त्याला login करवतो	लीक किंवा विसरले जाणारे पासवर्ड नाहीत	Email delivery वर अवलंबून; login हळू
Social login (OAuth / OpenID Connect)	वापरकर्ता Google, Apple, GitHub इत्यादीने साइन इन करतो	वापरकर्त्यांसाठी जलद; तुम्ही पासवर्ड साठवत नाही	प्रत्येक provider सोबत सेटअप; ती खाती नसलेले वापरकर्ते
Hosted auth provider	Clerk, Auth0 किंवा Supabase Auth सारखी सेवा sign-up, login आणि reset हाताळते	तुमचे सुरक्षा काम कमी	मोठ्या प्रमाणावर मासिक खर्च; आणखी एक अवलंबित्व
Multi-factor (MFA / 2FA)	पहिल्या तपासणीनंतर दुसरी तपासणी, जसे authenticator app चा code	फोडणे खूप कठीण	थोडा अधिक त्रास

पासवर्ड कसे साठवावेत

सुरक्षित ॲप तुमचा खरा पासवर्ड कधीच साठवत नाही. त्याऐवजी ते hash साठवते: एका दिशेने चालणाऱ्या फंक्शनचे आउटपुट, जे पासवर्डला एका निश्चित स्ट्रिंगमध्ये बदलते. तुम्ही login करता तेव्हा ॲप तुम्ही टाइप केलेल्याचा hash काढते आणि साठवलेल्या hash शी तुलना करते.

दोन तपशील हे सुरक्षित करतात:

Salt — hash करण्यापूर्वी प्रत्येक पासवर्डमध्ये जोडलेले यादृच्छिक मूल्य, जेणेकरून एकच पासवर्ड असलेल्या दोन लोकांचे hash वेगळे असतात आणि पूर्वगणित lookup tables निरुपयोगी ठरतात.
पासवर्डसाठी बनवलेला हळू algorithm — जसे Argon2, bcrypt किंवा scrypt. MD5 किंवा SHA-256 सारखे सामान्य hash स्वतःहून खूप वेगवान असतात; हल्लेखोर अब्जावधी अंदाज लावू शकतात.

Hashing म्हणजे encryption नव्हे. Encrypted डेटा key वापरून उलगडता येतो; पासवर्ड hash हे उलटे न करता येण्यासाठी बनवलेले असते.

Sessions विरुद्ध tokens

	Session (cookie)	Token (उदा. JWT)
ब्राउझरकडे काय असते	Cookie मधील एक यादृच्छिक session ID	वापरकर्ता माहिती आणि मुदत असलेला सही केलेला token
Login स्थिती कुठे राहते	सर्व्हरवर, डेटाबेस किंवा store मध्ये	Token च्या आतच
सर्व ठिकाणांहून logout करणे	सोपे: सर्व्हरवरून session हटवा	कठीण: मुदत संपेपर्यंत token वैध राहतो, block-list ठेवल्याशिवाय
सामान्य उपयोग	पारंपरिक वेब ॲप्स	APIs, मोबाइल ॲप्स, एकमेकांशी बोलणाऱ्या सेवा

Cookies साठी तीन सेटिंग्ज महत्त्वाच्या आहेत: HttpOnly (पेजवरील JavaScript cookie वाचू शकत नाही), Secure (फक्त HTTPS वरून पाठवली जाते) आणि SameSite (इतर साइट्सवरील requests वर ती पाठवणे मर्यादित करते). ब्राउझरच्या localStorage मध्ये tokens साठवणे सामान्य आहे, पण ते पेजवर चालणाऱ्या कोणत्याही script ला उघड करते.

OAuth आणि "Google सह साइन इन"

OAuth 2.0 हे delegated authorization साठीचे मानक आहे: ते ॲपला दुसऱ्या सेवेवरील तुमच्या खात्यात मर्यादित प्रवेश देते — उदाहरणार्थ तुमचे Google Calendar वाचणे — तुमचा Google पासवर्ड कधीही न पाहता. तुम्हाला Google कडे पाठवले जाते, तुम्ही विशिष्ट परवानग्या (ज्यांना scopes म्हणतात) मंजूर करता, आणि Google ॲपला फक्त त्या परवानग्यांसाठी token देते.

OAuth स्वतः प्रवेश देण्यासाठी बनवला होता, तुम्ही कोण आहात हे सांगण्यासाठी नाही. OpenID Connect (OIDC) हा OAuth 2.0 वरील थर आहे जो identity जोडतो, आणि "Google सह साइन इन" किंवा "Apple सह साइन इन" तोच वापरतात. सेटअपसाठी तुम्ही तुमचे ॲप provider कडे नोंदवता आणि client ID व client secret मिळवता; secret तुमच्या सर्व्हरवर राहते.

समजा तुम्ही एक पोर्टल बनवत आहात जिथे एका डिझाइन एजन्सीचे क्लायंट त्यांचे प्रोजेक्ट्स आणि इनव्हॉइस पाहतात.

Authentication: क्लायंट email आणि magic link वापरून login करतात, त्यामुळे व्यवस्थापित करायला पासवर्ड नाहीत. एजन्सीचे कर्मचारी Google Workspace खात्यांनी login करतात.
Roles: प्रत्येक वापरकर्त्याची भूमिका असते — client किंवा staff.
Authorization नियम:

कृती	क्लायंट	कर्मचारी
स्वतःच्या कंपनीचे प्रोजेक्ट्स पाहणे	होय	होय
इतर कंपन्यांचे प्रोजेक्ट्स पाहणे	नाही	होय
प्रोजेक्टमध्ये फाइल अपलोड करणे	फक्त स्वतःचे प्रोजेक्ट्स	होय
इनव्हॉइस paid म्हणून चिन्हांकित करणे	नाही	होय

ते कुठे लागू होते: सर्व्हरवर, प्रत्येक request साठी. सर्व्हर login वापरकर्ता शोधतो, आणि नंतर फक्त project.company_id वापरकर्त्याच्या कंपनीशी जुळणारे प्रोजेक्ट्स परत करतो. "Mark paid" बटण लपवणे पुरेसे नाही — endpoint स्वतः नकार दिला पाहिजे.

सामान्य संज्ञा स्पष्ट

संज्ञा	अर्थ
Authentication (AuthN)	कोणी आहे हे पडताळणे.
Authorization (AuthZ)	त्याला काय करण्याची परवानगी आहे हे ठरवणे.
Session	Requests दरम्यान ॲपने तुम्ही login असल्याचे लक्षात ठेवणे.
Cookie	प्रत्येक request सोबत ब्राउझर साइटकडे परत पाठवणारा छोटा डेटा तुकडा.
JWT	JSON Web Token: user ID आणि मुदत यांसारखी माहिती असलेला सही केलेला, लहान token.
Role / permission	`admin` किंवा `member` सारखी लेबल्स जी प्रवेश ठरवतात.
MFA / 2FA	authenticator app चा code यासारखा दुसरा पुरावा मागणे.
SSO	Single sign-on: अनेक ॲप्ससाठी एकच login (अनेकदा कंपनी खाते).
401 विरुद्ध 403	"तुम्ही कोण आहात?" (authenticated नाही) विरुद्ध "तुम्ही ते करू शकत नाही" (authorized नाही).

सामान्य चुका आणि गैरसमज

फक्त पेजमध्ये परवानग्या तपासणे. ब्राउझर बटण लपवतो पण API तपासत नसेल, तर कोणीही थेट API कॉल करू शकतो.
URL मधील IDs वर विश्वास ठेवणे. /invoices/1042 ने तपासायला हवे की invoice 1042 लॉग इन वापरकर्त्याचा आहे.
स्वतःचे crypto तयार करणे. सुप्रसिद्ध लायब्ररी किंवा providers वापरा; AI ला स्वतःची hashing योजना शोधू देऊ नका.
कमकुवत password reset. Reset links एकदाच वापरता येणारे, लवकर मुदत संपणारे असावेत आणि email खाते आहे का हे उघड करू नयेत.
तुमचे login आणि बिल्डरचे login गोंधळणे. तुमच्या ॲपचे वापरकर्ते हे तुम्ही ज्या टूलने बांधता त्यावरील तुमच्या खात्यापासून वेगळे असतात.
Login वर rate limiting नाही. त्याशिवाय हल्लेखोर पासवर्ड अमर्याद प्रयत्न करू शकतात.

तुमच्या AI बिल्डरला काय मागावे

"[सुप्रसिद्ध लायब्ररी किंवा provider] वापरून sign-up आणि login जोडा. स्वतः पासवर्ड hashing लिहू नका."
"पासवर्ड bcrypt किंवा Argon2 ने hash करून साठवा."
"Session साठी HttpOnly, Secure cookies वापरा."
"Roles जोडा: admin आणि member. प्रत्येक endpoint आणि कोणत्या roles ना तो कॉल करता येतो ते यादी करा."
"सर्व्हरवर खात्री करा की वापरकर्ते फक्त स्वतःचे रेकॉर्ड वाचू आणि संपादित करू शकतात. मग तुम्ही ते कसे तपासले ते दाखवा."
"एकदाच वापरता येणारे, एका तासात मुदत संपणारे links असलेला password reset जोडा."
"Login प्रयत्नांवर rate limit लावा."

मग स्वतः चाचणी करा: दोन खाती बनवा आणि एका खात्याने login असताना दुसऱ्याच्या डेटापर्यंत पोहोचण्याचा प्रयत्न करा. आमचे login जोडण्याचे मार्गदर्शक आणि सुरक्षा चेकलिस्ट अधिक तपशील देतात.

Mythex मधील Authentication

Mythex तुमच्या ॲपच्या वापरकर्त्यांसाठी अंगभूत auth उत्पादन देत नाही; तुम्ही एक पद्धत निवडता — तुमच्या प्रोजेक्टच्या डेटाबेसमध्ये साठवलेले email आणि पासवर्ड, किंवा hosted provider चा SDK — आणि एजंटला ते जोडण्यास सांगता. Provider keys प्रोजेक्ट secrets मध्ये जातात, चॅटमध्ये नाही. हे Mythex मध्ये स्वतःच्या साइन इनपेक्षा वेगळे आहे. ॲपमध्ये login जोडणे या docs recipe मध्ये तुम्ही जुळवून घेऊ शकता असा starter prompt आहे, आणि API म्हणजे काय हे त्या सर्व्हर-बाजूच्या तपासण्या कुठे राहतात ते समजावते.

प्रश्न

Authentication आणि authorization मध्ये काय फरक आहे?

Authentication तपासते की तुम्ही कोण आहात, उदाहरणार्थ तुमचा पासवर्ड पडताळून. Authorization ठरवते की तुम्हाला ओळखल्यानंतर काय करण्याची परवानगी आहे, जसे की admin पेज पाहणे किंवा दुसऱ्याचे booking बदलणे. ॲपला दोन्ही लागतात.

OAuth म्हणजे काय?

OAuth 2.0 हे एक मानक आहे जे ॲपला तुमचा पासवर्ड न पाहता दुसऱ्या सेवेवरील तुमच्या खात्यात मर्यादित प्रवेश मिळवू देते. 'Google सह साइन इन' OpenID Connect वापरते, जो OAuth 2.0 वर बांधलेला identity थर आहे, त्यामुळे ॲपला Google कडून तुम्ही कोण आहात ते कळते.

माझ्या ॲपने पासवर्ड साठवावेत का?

वाचता येईल अशा स्वरूपात कधीच नाही. Email आणि पासवर्ड login वापरत असाल, तर पासवर्ड salted hash म्हणून साठवले पाहिजेत, Argon2 किंवा bcrypt सारख्या पासवर्डसाठी बनवलेल्या हळू algorithm ने. अनेक ॲप्स hosted auth provider, social login किंवा email magic links वापरून हा प्रश्न टाळतात.

Sessions की tokens — माझ्या ॲपने कोणते वापरावे?

दोन्ही चालतात. Session सर्व्हरवर login स्थिती साठवते आणि ब्राउझरला cookie मध्ये एक यादृच्छिक ID देते, जी सहज रद्द करता येते. JWT सारखे token स्वतःत सही केलेली माहिती घेऊन जाते, जे APIs आणि मोबाइल क्लायंट्ससाठी योग्य आहे, पण मुदत संपण्याआधी रद्द करणे कठीण असते. सामान्य वेब ॲपसाठी cookie-आधारित sessions हा चांगला डीफॉल्ट पर्याय आहे.