Authentication என்றால் என்ன? Login, Session, OAuth விளக்கம்
Authentication என்பது ஒரு ஆப் பயனர் யார் என்பதை உறுதிசெய்யும் வழி — பொதுவாக அவர்களுக்குத் தெரிந்த ஒன்றைச் (password) சரிபார்த்தல், அவர்களிடம் உள்ள ஒன்றைச் (தொலைபேசி அல்லது email-க்கு அனுப்பப்பட்ட code) சரிபார்த்தல், அல்லது நம்பகமான வேறொரு சேவையின் அடையாளத்தை (“Google மூலம் உள்நுழை” போல) ஏற்றுக்கொள்ளுதல் மூலம். பயனர் உறுதிசெய்யப்பட்டதும், ஒவ்வொரு பக்கத்திலும் மீண்டும் உள்நுழையத் தேவையில்லாமல் ஆப் அவரை session அல்லது token மூலம் நினைவில் வைத்திருக்கும். உறுதிசெய்யப்பட்ட அந்தப் பயனர் என்ன செய்யலாம் என்று தீர்மானிப்பது தனிப் படியான authorization ஆகும்.
AI மூலம் உருவாக்கும்போது இது ஏன் முக்கியம்
AI builder-இடம் கேட்கும் பொதுவான கோரிக்கைகளில் login சேர்ப்பதும் ஒன்று; அதைச் சற்று தவறாகச் செய்வதும் எளிது. Login பக்கத்தை உருவாக்குவது எளிமையானது. கடினமான பகுதி அதைச் சுற்றியுள்ள அனைத்தும்:
- Passwords பாதுகாப்பாகச் சேமிக்கப்படுகின்றனவா?
- ஒவ்வொரு தனிப்பட்ட பக்கமும், ஒவ்வொரு API endpoint-உம், கேட்பவர் யார் என்று உண்மையில் சரிபார்க்கிறதா?
- URL-இல் ஓர் எண்ணை மாற்றி, உள்நுழைந்த ஒரு வாடிக்கையாளர் இன்னொருவரின் தரவைப் பார்க்க முடியுமா?
- யாராவது password-ஐ மறந்தால் என்ன நடக்கும்?
இவை எல்லாவற்றிலும் ஒரு ஆப் தோல்வியடைந்தும் முழுவதும் பாதுகாப்பாகத் தோன்றலாம். நகரும் பகுதிகளைப் புரிந்துகொண்டால், சரியான கேள்விகளைக் கேட்கவும் சரியானவற்றைச் சோதிக்கவும் முடியும்.
ஒரு அன்றாட உவமை
ஒரு ஹோட்டலில் தங்கச் செல்வதாக நினையுங்கள்.
முன்பக்க மேசையில் அடையாள அட்டையைக் காட்டுகிறீர்கள். அதுதான் authentication: நீங்கள் யார் என்பதை நிரூபிப்பது. வரவேற்பாளர் உங்களுக்கு ஒரு key card கொடுக்கிறார். அந்த card தான் உங்கள் session: தங்கும் காலம் முழுவதும் மீண்டும் அடையாள அட்டை காட்டத் தேவையில்லை; card-ஐத் தட்டினால் போதும்.
அந்த card உங்கள் அறையையும், ஜிம்மையும், உங்கள் தளத்திற்கான லிஃப்டையும் திறக்கும் — மற்ற விருந்தினர்களின் அறைகளையோ ஊழியர் அலுவலகத்தையோ அல்ல. அதுதான் authorization: உங்கள் அடையாளம் எதை அணுக அனுமதிக்கப்பட்டுள்ளது. Card தொலைந்தால் வரவேற்பு மேசையில் அதை செயலிழக்கச் செய்யலாம் (session ரத்து). நீங்கள் வெளியேறும்போது அது வேலை செய்வதை நிறுத்துகிறது (logout அல்லது காலாவதி).
“Google மூலம் உள்நுழை” என்பது ஒரு நம்பகமான கூட்டாளியிடமிருந்து “இவர் இவர்தான்” என்ற கடிதத்தை ஹோட்டல் ஏற்றுக்கொள்வது போல; உங்கள் அடையாள அட்டையை ஹோட்டல் நேரடியாகச் சரிபார்ப்பதில்லை.
முக்கிய உள்நுழைவு முறைகள்
| முறை | எப்படி வேலை செய்கிறது | நன்மைகள் | குறைகள் |
|---|---|---|---|
| Email + password | பயனர் ஒரு password தேர்ந்தெடுக்கிறார்; ஆப் அதன் hash-ஐச் சேமிக்கிறது | பழக்கமானது, வெளிப்புறச் சார்பு இல்லை | Hashes-ஐப் பாதுகாப்பாகச் சேமித்து, reset-ஐக் கையாள வேண்டும் |
| Magic link / ஒரு முறை code | ஆப் ஒரு link அல்லது code-ஐ email செய்கிறது; அது பயனரை உள்நுழைக்கிறது | கசியவோ மறக்கவோ passwords இல்லை | Email delivery-ஐச் சார்ந்தது; உள்நுழைவு மெதுவானது |
| Social login (OAuth / OpenID Connect) | Google, Apple, GitHub போன்றவற்றால் பயனர் உள்நுழைகிறார் | பயனர்களுக்கு வேகம்; password-ஐ நீங்கள் சேமிப்பதில்லை | ஒவ்வொரு வழங்குநருக்கும் அமைப்பு; அந்தக் கணக்குகள் இல்லாத பயனர்கள் |
| Hosted auth provider | Clerk, Auth0 அல்லது Supabase Auth போன்ற சேவை sign-up, login, reset ஆகியவற்றைக் கையாள்கிறது | உங்களுக்குப் பாதுகாப்பு வேலை குறைவு | அளவு பெரிதானால் மாதக் கட்டணம்; இன்னொரு சார்பு |
| Multi-factor (MFA / 2FA) | முதல் சரிபார்ப்புக்குப் பின் இரண்டாவது சரிபார்ப்பு, உதாரணமாக authenticator ஆப்பின் code | உடைப்பது மிகக் கடினம் | சிறிது கூடுதல் சிரமம் |
Passwords எப்படிச் சேமிக்கப்பட வேண்டும்
பாதுகாப்பான ஆப் உங்கள் உண்மையான password-ஐ ஒருபோதும் சேமிப்பதில்லை. அதற்குப் பதிலாக அது hash-ஐச் சேமிக்கிறது: password-ஐ ஒரு நிலையான சரமாக மாற்றும் ஒருவழிச் செயல்பாட்டின் வெளியீடு. நீங்கள் உள்நுழையும்போது, ஆப் நீங்கள் தட்டச்சு செய்ததை hash செய்து சேமித்த hash-உடன் ஒப்பிடுகிறது.
இதைப் பாதுகாப்பாக்கும் இரண்டு விவரங்கள்:
- Salt — ஒவ்வொரு password-உடனும் hash செய்வதற்கு முன் சேர்க்கப்படும் ஒரு சீரற்ற மதிப்பு; ஒரே password உள்ள இருவருக்கு வெவ்வேறு hashes கிடைக்கும், முன்பே கணக்கிடப்பட்ட lookup tables பயனற்றவை.
- Passwords-க்காக வடிவமைக்கப்பட்ட மெதுவான algorithm — Argon2, bcrypt அல்லது scrypt போன்றவை. MD5 அல்லது SHA-256 போன்ற பொது நோக்க hashes தனியாகவே மிக வேகமானவை; தாக்குபவர்கள் பில்லியன் கணக்கான யூகங்களை முயற்சிக்கலாம்.
Hashing என்பது encryption அல்ல. Encrypt செய்யப்பட்ட தரவை ஒரு key மூலம் மீண்டும் படிக்கலாம்; password hash மீளக்கூடியதாக இருக்காதபடி வடிவமைக்கப்பட்டது.
Sessions vs tokens
உள்நுழைந்த பின், ஒவ்வொரு கோரிக்கையிலும் உங்களை ஆப் அடையாளம் காண வேண்டும். இதற்கு இரண்டு பொதுவான அணுகுமுறைகள் உள்ளன.
| Session (cookie) | Token (எ.கா. JWT) | |
|---|---|---|
| Browser-இல் இருப்பது | Cookie-இல் ஒரு சீரற்ற session ID | பயனர் தகவலும் காலாவதி நேரமும் கொண்ட கையொப்பமிட்ட token |
| உள்நுழைவு நிலை எங்கே இருக்கிறது | Server-இல், database அல்லது store-இல் | Token-க்கு உள்ளேயே |
| எல்லா இடங்களிலிருந்தும் ஒருவரை வெளியேற்றுவது | எளிது: server-இல் session-ஐ நீக்கு | கடினம்: block-list வைக்காவிட்டால் காலாவதியாகும் வரை token செல்லுபடியாகும் |
| வழக்கமான பயன்பாடு | பாரம்பரிய web ஆப்கள் | APIs, மொபைல் ஆப்கள், சேவைகளுக்கிடையிலான தொடர்பு |
Cookies-க்கு மூன்று அமைப்புகள் முக்கியம்: HttpOnly (பக்கத்தின் JavaScript cookie-ஐப் படிக்க முடியாது), Secure (HTTPS வழியாக மட்டும் அனுப்பப்படும்) மற்றும் SameSite (பிற தளங்களிலிருந்து வரும் கோரிக்கைகளில் அனுப்புவதைக் கட்டுப்படுத்தும்). Browser-இன் localStorage-இல் tokens சேமிப்பது பொதுவானது, ஆனால் பக்கத்தில் இயங்கும் எந்த script-க்கும் அவை வெளிப்படும்.
OAuth மற்றும் “Google மூலம் உள்நுழை”
OAuth 2.0 என்பது delegated authorization-க்கான தரநிலை: உங்கள் Google password-ஐ ஒருபோதும் பார்க்காமல், வேறொரு சேவையில் உங்கள் கணக்கிற்கு ஒரு ஆப் வரையறுக்கப்பட்ட அணுகலைப் பெற இது அனுமதிக்கிறது — எடுத்துக்காட்டாக உங்கள் Google Calendar-ஐப் படிப்பது. நீங்கள் Google-க்கு அனுப்பப்படுகிறீர்கள், குறிப்பிட்ட அனுமதிகளை (scopes எனப்படும்) ஏற்கிறீர்கள், Google அந்த அனுமதிகளுக்கு மட்டும் ஒரு token-ஐ ஆப்புக்குத் தருகிறது.
OAuth தனியாகப் பயன்படும்போது அணுகல் வழங்குவதற்காக வடிவமைக்கப்பட்டது, நீங்கள் யார் என்று சொல்வதற்காக அல்ல. OpenID Connect (OIDC) என்பது OAuth 2.0-இன் மேல் அடையாளத்தைச் சேர்க்கும் ஒரு அடுக்கு; “Google மூலம் உள்நுழை” அல்லது “Apple மூலம் உள்நுழை” பயன்படுத்துவது இதுவே. அமைக்க, உங்கள் ஆப்பை வழங்குநரிடம் பதிவு செய்து client ID மற்றும் client secret-ஐப் பெற வேண்டும்; secret உங்கள் server-இலேயே இருக்க வேண்டும்.
ஒரு செயல்முறை எடுத்துக்காட்டு: ஒரு client portal-க்கான login
ஒரு வடிவமைப்பு நிறுவனத்தின் வாடிக்கையாளர்கள் தங்கள் projects மற்றும் invoices-ஐப் பார்க்கும் portal ஒன்றை உருவாக்குகிறீர்கள் என்று வைத்துக்கொள்ளுங்கள்.
- Authentication: வாடிக்கையாளர்கள் email மற்றும் magic link மூலம் உள்நுழைகின்றனர், அதனால் நிர்வகிக்க passwords இல்லை. நிறுவன ஊழியர்கள் Google Workspace கணக்குகளால் உள்நுழைகின்றனர்.
- Roles: ஒவ்வொரு பயனருக்கும் ஒரு role உண்டு —
clientஅல்லதுstaff. - Authorization விதிகள்:
| செயல் | Client | Staff |
|---|---|---|
| தங்கள் நிறுவனத்தின் projects-ஐப் பார்ப்பது | ஆம் | ஆம் |
| மற்ற நிறுவனங்களின் projects-ஐப் பார்ப்பது | இல்லை | ஆம் |
| ஒரு project-க்குக் கோப்பு பதிவேற்றுவது | சொந்த projects மட்டும் | ஆம் |
| ஒரு invoice-ஐ paid என்று குறிப்பது | இல்லை | ஆம் |
- அமலாக்கம் எங்கே: ஒவ்வொரு கோரிக்கைக்கும், server-இல். Server உள்நுழைந்த பயனரைத் தேடி,
project.company_idபயனரின் நிறுவனத்துடன் பொருந்தும் projects-ஐ மட்டுமே திருப்பித் தரும். “Mark paid” பொத்தானை மறைப்பது போதாது — endpoint தானே மறுக்க வேண்டும்.
பொதுவான சொற்களின் விளக்கம்
| சொல் | பொருள் |
|---|---|
| Authentication (AuthN) | ஒருவர் யார் என்பதை உறுதிசெய்தல். |
| Authorization (AuthZ) | அவர் என்ன செய்யலாம் என்பதைத் தீர்மானித்தல். |
| Session | கோரிக்கைகளுக்கு இடையே நீங்கள் உள்நுழைந்திருப்பதை ஆப் நினைவில் வைத்திருத்தல். |
| Cookie | ஒவ்வொரு கோரிக்கையுடனும் browser தளத்திற்கு மீண்டும் அனுப்பும் சிறிய தரவுத் துண்டு. |
| JWT | JSON Web Token: user ID, காலாவதி போன்ற claims-ஐ சுமக்கும், கையொப்பமிட்ட சிறிய token. |
| Role / permission | admin அல்லது member போன்ற, அணுகலைத் தீர்மானிக்கும் பெயர்கள். |
| MFA / 2FA | authenticator ஆப்பின் code போன்ற இரண்டாவது சான்று கேட்பது. |
| SSO | Single sign-on: பல ஆப்களுக்கு ஒரே login (பெரும்பாலும் நிறுவனக் கணக்கு). |
| 401 vs 403 | “நீங்கள் யார்?” (உறுதிசெய்யப்படவில்லை) எதிராக “உங்களால் அதைச் செய்ய முடியாது” (அனுமதி இல்லை). |
பொதுவான தவறுகள் மற்றும் தவறான புரிதல்கள்
- பக்கத்தில் மட்டும் அனுமதிகளைச் சரிபார்த்தல். Browser ஒரு பொத்தானை மறைத்தாலும் API சரிபார்க்கவில்லை என்றால், யார் வேண்டுமானாலும் API-ஐ நேரடியாக அழைக்கலாம்.
- URL-இலிருந்து வரும் IDs-ஐ நம்புதல்.
/invoices/1042என்பது invoice 1042 உள்நுழைந்த பயனருக்குச் சொந்தமா என்று சரிபார்க்க வேண்டும். - சொந்த crypto-வை உருவாக்குதல். நன்கு அறியப்பட்ட libraries அல்லது வழங்குநர்களைப் பயன்படுத்துங்கள்; AI ஒரு hashing முறையைக் கண்டுபிடிக்க விடாதீர்கள்.
- பலவீனமான password reset. Reset links ஒருமுறை மட்டும் பயன்படக்கூடியதாகவும், விரைவில் காலாவதியாகக்கூடியதாகவும், email-க்கு கணக்கு உள்ளதா என்பதை வெளிப்படுத்தாததாகவும் இருக்க வேண்டும்.
- உங்கள் login-ஐ உங்கள் builder-இன் login-உடன் குழப்புதல். உங்கள் ஆப்பின் பயனர்கள், நீங்கள் உருவாக்கும் கருவியில் உள்ள உங்கள் கணக்கிலிருந்து வேறானவர்கள்.
- Login-க்கு rate limiting இல்லாதது. அது இல்லாவிட்டால், தாக்குபவர்கள் passwords-ஐ முடிவில்லாமல் முயற்சிக்கலாம்.
உங்கள் AI builder-இடம் கேட்க வேண்டியவை
- “[நன்கு அறியப்பட்ட library அல்லது வழங்குநர்] மூலம் sign-up மற்றும் login சேர். சொந்த password hashing எழுத வேண்டாம்.”
- “Passwords-ஐ bcrypt அல்லது Argon2 மூலம் hash செய்து சேமி.”
- “Session-க்கு HttpOnly, Secure cookies பயன்படுத்து.”
- “Roles சேர்: admin மற்றும் member. ஒவ்வொரு endpoint-ஐயும், அதை அழைக்கக்கூடிய roles-ஐயும் பட்டியலிடு.”
- “பயனர்கள் தங்கள் சொந்த பதிவுகளை மட்டுமே படிக்கவும் திருத்தவும் முடியும் என்பதை server-இல் அமல்படுத்து. பின்னர் எப்படிச் சரிபார்த்தாய் என்று காட்டு.”
- “ஒரு மணி நேரத்தில் காலாவதியாகும் ஒருமுறை link-களுடன் password reset சேர்.”
- “Login முயற்சிகளுக்கு rate-limit வை.”
பிறகு நீங்களே சோதியுங்கள்: இரண்டு கணக்குகளை உருவாக்கி, ஒருவர் உள்நுழைந்திருக்கும்போது மற்றவரின் தரவை அடைய முயலுங்கள். login சேர்ப்பது பற்றிய வழிகாட்டி மற்றும் பாதுகாப்புச் சரிபட்டியல் மேலும் விவரிக்கின்றன.
Mythex-இல் Authentication
Mythex உங்கள் ஆப்பின் பயனர்களுக்கென எந்த உள்ளமைந்த auth தயாரிப்பையும் வழங்குவதில்லை; ஒரு அணுகுமுறையைத் தேர்ந்தெடுக்கிறீர்கள் — உங்கள் project-இன் database-இல் சேமிக்கப்படும் email மற்றும் password, அல்லது hosted வழங்குநரின் SDK — பின்னர் அதைச் சேர்க்கும்படி agent-இடம் கேளுங்கள். வழங்குநர் keys-ஐ project secrets-இல் வையுங்கள், chat-இல் அல்ல. இது Mythex-இலேயே நீங்கள் உள்நுழைவதிலிருந்து வேறானது. உங்கள் ஆப்பில் login சேர்ப்பது பற்றிய docs recipe-இல் நீங்கள் மாற்றிக்கொள்ளக்கூடிய தொடக்க prompt உள்ளது; server பக்கச் சரிபார்ப்புகள் எங்கே வாழ்கின்றன என்பதை API என்றால் என்ன விளக்குகிறது.
கேள்விகள்
Authentication-க்கும் authorization-க்கும் என்ன வேறுபாடு?
Authentication நீங்கள் யார் என்பதைச் சரிபார்க்கிறது, உதாரணமாக உங்கள் password-ஐ உறுதிசெய்வதன் மூலம். Authorization உங்களை அறிந்த பின் நீங்கள் என்ன செய்யலாம் என்பதைத் தீர்மானிக்கிறது, உதாரணமாக admin பக்கத்தைப் பார்க்கலாமா அல்லது வேறொருவரின் booking-ஐத் திருத்தலாமா. ஆப்புகளுக்கு இரண்டும் தேவை.
OAuth என்றால் என்ன?
OAuth 2.0 என்பது ஒரு தரநிலை; இது உங்கள் password-ஐப் பார்க்காமல், வேறொரு சேவையில் உள்ள உங்கள் கணக்கிற்கு ஒரு ஆப் வரையறுக்கப்பட்ட அணுகலைப் பெற அனுமதிக்கிறது. “Google மூலம் உள்நுழை” OpenID Connect-ஐப் பயன்படுத்துகிறது — OAuth 2.0-இன் மேல் கட்டப்பட்ட identity அடுக்கு — அதனால் ஆப் Google-இடமிருந்து நீங்கள் யார் என்பதை அறிகிறது.
என் ஆப் passwords-ஐ சேமிக்கலாமா?
படிக்கக்கூடிய வடிவத்தில் ஒருபோதும் கூடாது. Email மற்றும் password login பயன்படுத்தினால், passwords salted hashes-ஆகச் சேமிக்கப்பட வேண்டும், passwords-க்காக வடிவமைக்கப்பட்ட மெதுவான algorithm மூலம் — Argon2 அல்லது bcrypt போன்றவை. பல ஆப்கள் hosted auth provider, social login அல்லது email magic links பயன்படுத்தி இந்தச் சிக்கலைத் தவிர்க்கின்றன.
Sessions அல்லது tokens — என் ஆப் எதைப் பயன்படுத்த வேண்டும்?
இரண்டும் வேலை செய்யும். Session உள்நுழைவு நிலையை server-இல் சேமித்து, browser-க்கு cookie-இல் ஒரு சீரற்ற ID தருகிறது; அதை ரத்து செய்வது எளிது. JWT போன்ற token தன்னுள்ளேயே கையொப்பமிட்ட தகவலைக் கொண்டிருக்கும்; இது APIs மற்றும் மொபைல் clients-க்குப் பொருந்தும், ஆனால் காலாவதியாகும் முன் ரத்து செய்வது கடினம். வழக்கமான web ஆப்புக்கு cookie-அடிப்படையிலான sessions ஒரு நல்ல இயல்புநிலை.