എന്താണ് ഓതന്റിക്കേഷൻ? ലോഗിൻ, സെഷനുകൾ, OAuth എന്നിവ വിശദീകരണം
ഒരു ആപ്പ് ഉപയോക്താവ് ആരാണെന്ന് ഉറപ്പാക്കുന്ന പ്രക്രിയയാണ് ഓതന്റിക്കേഷൻ. സാധാരണയായി അവർക്കറിയുന്ന ഒന്ന് (പാസ്‌വേഡ്), കൈവശമുള്ള ഒന്ന് (ഫോണിലോ ഇമെയിലിലോ അയച്ച കോഡ്), അല്ലെങ്കിൽ വിശ്വസനീയമായ മറ്റൊരു സേവനത്തിൽ നിന്നുള്ള ഐഡന്റിറ്റി (ഉദാഹരണത്തിന് “Google ഉപയോഗിച്ച് സൈൻ ഇൻ ചെയ്യുക”) എന്നിവ പരിശോധിച്ചാണ് ഇത് ചെയ്യുന്നത്. ഒരു ഉപയോക്താവ് ഓതന്റിക്കേറ്റ് ചെയ്തു കഴിഞ്ഞാൽ, ഓരോ പേജിലും വീണ്ടും ലോഗിൻ ചെയ്യേണ്ടതില്ലാത്ത വിധം ആപ്പ് സെഷനോ ടോക്കണോ വഴി അവരെ ഓർക്കുന്നു. ആ അറിയപ്പെട്ട ഉപയോക്താവിന് എന്ത് ചെയ്യാമെന്ന് തീരുമാനിക്കുന്നത് ഓതറൈസേഷൻ എന്ന പ്രത്യേക ഘട്ടമാണ്.
നിങ്ങൾ AI ഉപയോഗിച്ച് നിർമ്മിക്കുമ്പോൾ ഇത് പ്രധാനമായത് എന്തുകൊണ്ട്
ലോഗിൻ ചേർക്കുക എന്നത് ആളുകൾ AI ബിൽഡറിനോട് ഏറ്റവും സാധാരണമായി ആവശ്യപ്പെടുന്ന കാര്യങ്ങളിലൊന്നാണ്, അതേസമയം അത് സൂക്ഷ്മമായി തെറ്റാനുള്ള സാധ്യതയും ഏറ്റവും കൂടുതലാണ്. ഒരു ലോഗിൻ പേജ് ഉണ്ടാക്കുന്നത് എളുപ്പമാണ്. ബുദ്ധിമുട്ടുള്ളത് അതിന് ചുറ്റുമുള്ളതെല്ലാമാണ്:
- പാസ്‌വേഡുകൾ സുരക്ഷിതമായി സൂക്ഷിക്കുന്നുണ്ടോ?
- ഓരോ സ്വകാര്യ പേജും ഓരോ API എൻഡ്‌പോയിന്റും ആരാണ് ചോദിക്കുന്നതെന്ന് യഥാർത്ഥത്തിൽ പരിശോധിക്കുന്നുണ്ടോ?
- URL-ലെ ഒരു നമ്പർ മാറ്റിയാൽ ലോഗിൻ ചെയ്ത ഒരു customer-ന് മറ്റൊരു customer-ന്റെ ഡാറ്റ കാണാൻ കഴിയുമോ?
- ആരെങ്കിലും പാസ്‌വേഡ് മറന്നാൽ എന്ത് സംഭവിക്കും?
ഇവയിലെല്ലാം പരാജയപ്പെട്ടാലും ഒരു ആപ്പ് പൂർണ്ണമായും സുരക്ഷിതമായി തോന്നാം. ഭാഗങ്ങൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് മനസ്സിലാക്കിയാൽ ശരിയായ ചോദ്യങ്ങൾ ചോദിക്കാനും ശരിയായ കാര്യങ്ങൾ പരിശോധിക്കാനും കഴിയും.
ദൈനംദിന ഉദാഹരണം
ഒരു ഹോട്ടലിൽ ചെക്ക്-ഇൻ ചെയ്യുന്നത് ഓർക്കുക.
ഫ്രണ്ട് ഡെസ്കിൽ നിങ്ങൾ ID കാണിക്കുന്നു. അതാണ് ഓതന്റിക്കേഷൻ: നിങ്ങൾ ആരാണെന്ന് തെളിയിക്കുന്നു. തുടർന്ന് റിസപ്ഷനിസ്റ്റ് നിങ്ങൾക്ക് ഒരു കീ കാർഡ് നൽകുന്നു. ആ കാർഡാണ് നിങ്ങളുടെ സെഷൻ: താമസം മുഴുവൻ നിങ്ങൾ വീണ്ടും ID കാണിക്കേണ്ടതില്ല, കാർഡ് ടാപ്പ് ചെയ്താൽ മതി.
ആ കാർഡ് നിങ്ങളുടെ മുറി, ജിം, നിങ്ങളുടെ നിലയിലേക്കുള്ള ലിഫ്റ്റ് എന്നിവ തുറക്കുന്നു, പക്ഷേ മറ്റ് അതിഥികളുടെ മുറികളോ സ്റ്റാഫ് ഓഫീസോ തുറക്കില്ല. അതാണ് ഓതറൈസേഷൻ: നിങ്ങളുടെ ഐഡന്റിറ്റിക്ക് എന്തിലേക്കൊക്കെ പ്രവേശനമുണ്ട് എന്നത്. കാർഡ് നഷ്ടപ്പെട്ടാൽ ഹോട്ടലിന് ഡെസ്കിൽ വെച്ച് അത് നിർജ്ജീവമാക്കാം (സെഷൻ റദ്ദാക്കൽ). ചെക്ക്-ഔട്ട് ചെയ്താൽ അത് പ്രവർത്തിക്കാതാകുന്നു (ലോഗ്-ഔട്ട് അല്ലെങ്കിൽ കാലാവധി തീരൽ).
“Google ഉപയോഗിച്ച് സൈൻ ഇൻ ചെയ്യുക” എന്നത്, നിങ്ങളുടെ ID സ്വയം പരിശോധിക്കുന്നതിനു പകരം “ഇവർ ഇവരാണ്” എന്ന് പറയുന്ന വിശ്വസനീയ പങ്കാളിയുടെ കത്ത് ഒരു ഹോട്ടൽ സ്വീകരിക്കുന്നതുപോലെയാണ്.
പ്രധാന ലോഗിൻ രീതികൾ
| രീതി | എങ്ങനെ പ്രവർത്തിക്കുന്നു | ഗുണങ്ങൾ | ദോഷങ്ങൾ |
|---|---|---|---|
| ഇമെയിൽ + പാസ്‌വേഡ് | ഉപയോക്താവ് ഒരു പാസ്‌വേഡ് തിരഞ്ഞെടുക്കുന്നു; ആപ്പ് അതിന്റെ ഹാഷ് സൂക്ഷിക്കുന്നു | പരിചിതം, പുറത്തുള്ള ആശ്രിതത്വമില്ല | ഹാഷുകൾ സുരക്ഷിതമായി സൂക്ഷിക്കണം, റീസെറ്റുകൾ കൈകാര്യം ചെയ്യണം |
| മാജിക് ലിങ്ക് / ഒറ്റത്തവണ കോഡ് | ഉപയോക്താവിനെ ലോഗിൻ ചെയ്യിക്കുന്ന ലിങ്കോ കോഡോ ആപ്പ് ഇമെയിൽ ചെയ്യുന്നു | ചോരാനോ മറക്കാനോ പാസ്‌വേഡുകളില്ല | ഇമെയിൽ ഡെലിവറിയെ ആശ്രയിക്കുന്നു; ലോഗിൻ കുറച്ചുകൂടി വൈകും |
| സോഷ്യൽ ലോഗിൻ (OAuth / OpenID Connect) | Google, Apple, GitHub മുതലായവ ഉപയോഗിച്ച് സൈൻ ഇൻ | ഉപയോക്താക്കൾക്ക് വേഗത; നിങ്ങൾ പാസ്‌വേഡ് സൂക്ഷിക്കേണ്ടതില്ല | ഓരോ ദാതാവിനും സെറ്റപ്പ്; ആ അക്കൗണ്ടുകളില്ലാത്ത ഉപയോക്താക്കൾ |
| ഹോസ്റ്റ് ചെയ്ത ഓതൻ പ്രൊവൈഡർ | Clerk, Auth0 അല്ലെങ്കിൽ Supabase Auth പോലുള്ള സേവനം സൈൻ-അപ്പ്, ലോഗിൻ, റീസെറ്റ് കൈകാര്യം ചെയ്യുന്നു | നിങ്ങൾക്ക് സുരക്ഷാ ജോലി കുറവ് | വലുതാകുമ്പോൾ പ്രതിമാസ ചെലവ്; മറ്റൊരു ആശ്രിതത്വം |
| മൾട്ടി-ഫാക്ടർ (MFA / 2FA) | ആദ്യത്തേതിന് ശേഷം രണ്ടാമതൊരു പരിശോധന, ഉദാഹരണത്തിന് ഒരു authenticator ആപ്പ് കോഡ് | അകത്തുകടക്കാൻ വളരെ പ്രയാസം | അല്പം കൂടുതൽ ബുദ്ധിമുട്ട് |
പാസ്‌വേഡുകൾ എങ്ങനെ സൂക്ഷിക്കണം
സുരക്ഷിതമായ ആപ്പ് നിങ്ങളുടെ യഥാർത്ഥ പാസ്‌വേഡ് ഒരിക്കലും സൂക്ഷിക്കുന്നില്ല. പകരം അത് ഹാഷ് സൂക്ഷിക്കുന്നു: പാസ്‌വേഡിനെ ഒരു നിശ്ചിത സ്ട്രിങ്ങാക്കി മാറ്റുന്ന ഒരു വൺ-വേ ഫംഗ്ഷന്റെ ഔട്ട്‌പുട്ട്. നിങ്ങൾ ലോഗിൻ ചെയ്യുമ്പോൾ, ടൈപ്പ് ചെയ്തതിനെ ആപ്പ് ഹാഷ് ചെയ്ത് സൂക്ഷിച്ചിരിക്കുന്ന ഹാഷുമായി താരതമ്യം ചെയ്യുന്നു.
ഇത് സുരക്ഷിതമാക്കുന്ന രണ്ട് കാര്യങ്ങൾ:
- സാൾട്ട്: ഹാഷ് ചെയ്യുന്നതിന് മുമ്പ് ഓരോ പാസ്‌വേഡിലും ചേർക്കുന്ന റാൻഡം മൂല്യം. അതുകൊണ്ട് ഒരേ പാസ്‌വേഡുള്ള രണ്ടുപേർക്ക് വ്യത്യസ്ത ഹാഷുകൾ കിട്ടുന്നു, മുൻകൂട്ടി കണക്കാക്കിയ ലുക്ക്അപ്പ് പട്ടികകൾ ഉപയോഗശൂന്യമാകുന്നു.
- പാസ്‌വേഡുകൾക്കായി നിർമ്മിച്ച മന്ദഗതിയുള്ള അൽഗോരിതം: Argon2, bcrypt അല്ലെങ്കിൽ scrypt പോലുള്ളവ. MD5 അല്ലെങ്കിൽ SHA-256 പോലുള്ള പൊതു ആവശ്യത്തിനുള്ള ഹാഷുകൾ സ്വയം തന്നെ വളരെ വേഗമുള്ളവയാണ്; ആക്രമികൾക്ക് ബില്യൺ കണക്കിന് ഊഹങ്ങൾ പരീക്ഷിക്കാം.
ഹാഷിംഗ് എൻക്രിപ്ഷൻ പോലെയല്ല. എൻക്രിപ്റ്റ് ചെയ്ത ഡാറ്റ ഒരു കീ ഉപയോഗിച്ച് ഡീക്രിപ്റ്റ് ചെയ്യാം; പാസ്‌വേഡ് ഹാഷ് ഒരിക്കലും തിരിച്ചെടുക്കാനാകാത്ത വിധമാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്.
സെഷനുകളും ടോക്കണുകളും
ലോഗിന് ശേഷം, ഓരോ അഭ്യർത്ഥനയിലും ആപ്പിന് നിങ്ങളെ തിരിച്ചറിയേണ്ടതുണ്ട്. ഇതിന് രണ്ട് സാധാരണ രീതികളുണ്ട്.
| സെഷൻ (കുക്കി) | ടോക്കൺ (ഉദാ. JWT) | |
|---|---|---|
| ബ്രൗസർ സൂക്ഷിക്കുന്നത് | കുക്കിയിലെ ഒരു റാൻഡം സെഷൻ ID | ഉപയോക്തൃ വിവരവും കാലാവധിയും അടങ്ങിയ ഒപ്പിട്ട ടോക്കൺ |
| ലോഗിൻ അവസ്ഥ എവിടെ | സെർവറിൽ, ഒരു ഡാറ്റാബേസിലോ സ്റ്റോറിലോ | ടോക്കണിനുള്ളിൽ തന്നെ |
| എല്ലായിടത്തുനിന്നും ഒരാളെ ലോഗ്-ഔട്ട് ചെയ്യൽ | എളുപ്പം: സെർവറിൽ സെഷൻ ഡിലീറ്റ് ചെയ്യുക | പ്രയാസം: ബ്ലോക്ക്-ലിസ്റ്റ് സൂക്ഷിച്ചില്ലെങ്കിൽ കാലാവധി തീരുന്നതുവരെ ടോക്കൺ സാധുവായിരിക്കും |
| സാധാരണ ഉപയോഗം | പരമ്പരാഗത വെബ് ആപ്പുകൾ | API-കൾ, മൊബൈൽ ആപ്പുകൾ, പരസ്പരം സംസാരിക്കുന്ന സേവനങ്ങൾ |
കുക്കികൾക്ക് മൂന്ന് ക്രമീകരണങ്ങൾ പ്രധാനമാണ്: HttpOnly (പേജിലെ JavaScript-ന് കുക്കി വായിക്കാനാവില്ല), Secure (HTTPS വഴിമാത്രം അയക്കുന്നു), SameSite (മറ്റ് സൈറ്റുകളിൽ നിന്നുള്ള അഭ്യർത്ഥനകളിൽ അയക്കുന്നത് പരിമിതപ്പെടുത്തുന്നു). ബ്രൗസറിന്റെ localStorage-ൽ ടോക്കൺ സൂക്ഷിക്കുന്നത് സാധാരണമാണ്, പക്ഷേ പേജിൽ പ്രവർത്തിക്കുന്ന ഏത് സ്ക്രിപ്റ്റിനും അത് തുറന്നുകിട്ടും.
OAuth, ‘Google ഉപയോഗിച്ച് സൈൻ ഇൻ ചെയ്യുക’
OAuth 2.0 എന്നത് ഡെലിഗേറ്റഡ് ഓതറൈസേഷന് വേണ്ടിയുള്ള സ്റ്റാൻഡേർഡാണ്: നിങ്ങളുടെ Google പാസ്‌വേഡ് കാണാതെ, മറ്റൊരു സേവനത്തിലെ നിങ്ങളുടെ അക്കൗണ്ടിലേക്ക് പരിമിതമായ പ്രവേശനം നേടാൻ ആപ്പിനെ അനുവദിക്കുന്നു, ഉദാഹരണത്തിന് നിങ്ങളുടെ Google Calendar വായിക്കാൻ. നിങ്ങളെ Google-ലേക്ക് അയക്കുന്നു, നിങ്ങൾ നിർദ്ദിഷ്ട അനുമതികൾ (scopes) അംഗീകരിക്കുന്നു, ആ അനുമതികൾക്ക് മാത്രമുള്ള ടോക്കൺ Google ആപ്പിന് നൽകുന്നു.
OAuth സ്വയം നിങ്ങൾ ആരാണെന്ന് പറയാനല്ല, പ്രവേശനം അനുവദിക്കാനാണ് രൂപകൽപ്പന ചെയ്തത്. OpenID Connect (OIDC) എന്നത് OAuth 2.0-ന് മുകളിലുള്ള ഒരു ലെയറാണ്, അത് ഐഡന്റിറ്റി ചേർക്കുന്നു; “Google ഉപയോഗിച്ച് സൈൻ ഇൻ ചെയ്യുക” അല്ലെങ്കിൽ “Apple ഉപയോഗിച്ച് സൈൻ ഇൻ ചെയ്യുക” എന്നിവ ഉപയോഗിക്കുന്നത് ഇതാണ്. ഇത് സെറ്റ് ചെയ്യാൻ ദാതാവിനൊപ്പം നിങ്ങളുടെ ആപ്പ് രജിസ്റ്റർ ചെയ്ത് ക്ലയന്റ് ID, ക്ലയന്റ് സീക്രട്ട് എന്നിവ നേടണം; സീക്രട്ട് നിങ്ങളുടെ സെർവറിൽ തന്നെ നിൽക്കണം.
ഒരു ഉദാഹരണം: ക്ലയന്റ് പോർട്ടലിനുള്ള ലോഗിൻ
ഒരു ഡിസൈൻ ഏജൻസിയുടെ ക്ലയന്റുകൾക്ക് അവരുടെ പ്രോജക്റ്റുകളും ഇൻവോയ്സുകളും കാണാൻ കഴിയുന്ന ഒരു പോർട്ടൽ നിർമ്മിക്കുകയാണെന്ന് കരുതുക.
- ഓതന്റിക്കേഷൻ: ക്ലയന്റുകൾ ഇമെയിലും മാജിക് ലിങ്കും ഉപയോഗിച്ച് ലോഗിൻ ചെയ്യുന്നു, അതിനാൽ നിയന്ത്രിക്കാൻ പാസ്‌വേഡുകളില്ല. ഏജൻസി ജീവനക്കാർ Google Workspace അക്കൗണ്ടുകൾ ഉപയോഗിച്ച് ലോഗിൻ ചെയ്യുന്നു.
- റോളുകൾ: ഓരോ ഉപയോക്താവിനും ഒരു റോൾ ഉണ്ട് —
clientഅല്ലെങ്കിൽstaff. - ഓതറൈസേഷൻ നിയമങ്ങൾ:
| പ്രവർത്തനം | ക്ലയന്റ് | ജീവനക്കാർ |
|---|---|---|
| സ്വന്തം കമ്പനിയുടെ പ്രോജക്റ്റുകൾ കാണുക | അതെ | അതെ |
| മറ്റ് കമ്പനികളുടെ പ്രോജക്റ്റുകൾ കാണുക | ഇല്ല | അതെ |
| ഒരു പ്രോജക്റ്റിലേക്ക് ഫയൽ അപ്‌ലോഡ് ചെയ്യുക | സ്വന്തം പ്രോജക്റ്റുകൾ മാത്രം | അതെ |
| ഒരു ഇൻവോയ്സ് പണമടച്ചതായി അടയാളപ്പെടുത്തുക | ഇല്ല | അതെ |
- എവിടെയാണ് നടപ്പാക്കുന്നത്: ഓരോ അഭ്യർത്ഥനയ്ക്കും സെർവറിൽ. സെർവർ ലോഗിൻ ചെയ്ത ഉപയോക്താവിനെ കണ്ടെത്തുന്നു, തുടർന്ന്
project.company_idഉപയോക്താവിന്റെ കമ്പനിയുമായി യോജിക്കുന്ന പ്രോജക്റ്റുകൾ മാത്രം തിരികെ നൽകുന്നു. “Mark paid” ബട്ടൺ മറയ്ക്കുന്നത് മതിയാകില്ല — എൻഡ്‌പോയിന്റ് തന്നെ നിരസിക്കണം.
പൊതുവായ പദങ്ങൾ വിശദീകരണം
| പദം | അർത്ഥം |
|---|---|
| ഓതന്റിക്കേഷൻ (AuthN) | ആരാണെന്ന് ഉറപ്പാക്കൽ. |
| ഓതറൈസേഷൻ (AuthZ) | അവർക്ക് എന്ത് ചെയ്യാമെന്ന് തീരുമാനിക്കൽ. |
| സെഷൻ | അഭ്യർത്ഥനകൾക്കിടയിൽ നിങ്ങൾ ലോഗിൻ ചെയ്തിട്ടുണ്ടെന്ന് ആപ്പ് ഓർക്കുന്നത്. |
| കുക്കി | ഓരോ അഭ്യർത്ഥനയിലും ബ്രൗസർ സൈറ്റിലേക്ക് തിരികെ അയക്കുന്ന ചെറിയ ഡാറ്റ. |
| JWT | JSON Web Token: user ID, കാലാവധി പോലുള്ള ക്ലെയിമുകൾ വഹിക്കുന്ന ഒപ്പിട്ട, ചെറിയ ടോക്കൺ. |
| റോൾ / അനുമതി | പ്രവേശനം തീരുമാനിക്കുന്ന admin അല്ലെങ്കിൽ member പോലുള്ള ലേബലുകൾ. |
| MFA / 2FA | authenticator ആപ്പിൽ നിന്നുള്ള കോഡ് പോലെ രണ്ടാമതൊരു തെളിവ് ആവശ്യപ്പെടൽ. |
| SSO | സിംഗിൾ സൈൻ-ഓൺ: പല ആപ്പുകൾക്കായി ഒരൊറ്റ ലോഗിൻ (പലപ്പോഴും ഒരു കമ്പനി അക്കൗണ്ട്). |
| 401 vs 403 | “നിങ്ങൾ ആരാണ്?” (ഓതന്റിക്കേറ്റ് ചെയ്തിട്ടില്ല) vs “അത് ചെയ്യാൻ കഴിയില്ല” (ഓതറൈസ്ഡ് അല്ല). |
സാധാരണ തെറ്റുകളും തെറ്റിദ്ധാരണകളും
- പേജിൽ മാത്രം അനുമതികൾ പരിശോധിക്കുന്നത്. ബ്രൗസർ ഒരു ബട്ടൺ മറച്ചാലും API പരിശോധിക്കുന്നില്ലെങ്കിൽ, ആർക്കും API നേരിട്ട് വിളിക്കാം.
- URL-ലെ IDകളെ വിശ്വസിക്കുന്നത്.
/invoices/1042ഇൻവോയ്സ് 1042 ലോഗിൻ ചെയ്ത ഉപയോക്താവിന്റേതാണോ എന്ന് പരിശോധിക്കണം. - സ്വന്തം ക്രിപ്റ്റോ ഉണ്ടാക്കുന്നത്. അറിയപ്പെട്ട ലൈബ്രറികളോ ദാതാക്കളോ ഉപയോഗിക്കുക; AI ഒരു ഹാഷിംഗ് രീതി കണ്ടുപിടിക്കാൻ അനുവദിക്കരുത്.
- ദുർബലമായ പാസ്‌വേഡ് റീസെറ്റ്. റീസെറ്റ് ലിങ്കുകൾ ഒരുതവണ മാത്രം ഉപയോഗിക്കാവുന്നതും വേഗം കാലഹരണപ്പെടുന്നതും ഇമെയിലിന് അക്കൗണ്ടുണ്ടോ എന്ന് വെളിപ്പെടുത്താത്തതും ആയിരിക്കണം.
- നിങ്ങളുടെ ലോഗിനും ബിൽഡറിന്റെ ലോഗിനും കൂട്ടിക്കുഴയ്ക്കുന്നത്. നിങ്ങളുടെ ആപ്പിന്റെ ഉപയോക്താക്കൾ, നിങ്ങൾ നിർമ്മിക്കാൻ ഉപയോഗിക്കുന്ന ടൂളിലെ നിങ്ങളുടെ അക്കൗണ്ടിൽ നിന്ന് വേറിട്ടവരാണ്.
- ലോഗിനിൽ റേറ്റ് ലിമിറ്റിംഗ് ഇല്ലാത്തത്. അത് ഇല്ലെങ്കിൽ ആക്രമികൾക്ക് പാസ്‌വേഡുകൾ അനന്തമായി പരീക്ഷിക്കാം.
നിങ്ങളുടെ AI ബിൽഡറിനോട് ആവശ്യപ്പെടേണ്ടത്
- “[അറിയപ്പെട്ട ഒരു ലൈബ്രറി അല്ലെങ്കിൽ ദാതാവ്] ഉപയോഗിച്ച് സൈൻ-അപ്പും ലോഗിനും ചേർക്കൂ. കസ്റ്റം പാസ്‌വേഡ് ഹാഷിംഗ് എഴുതരുത്.”
- “പാസ്‌വേഡുകൾ bcrypt അല്ലെങ്കിൽ Argon2 ഉപയോഗിച്ച് ഹാഷ് ചെയ്ത് സൂക്ഷിക്കൂ.”
- “സെഷന് HttpOnly, Secure കുക്കികൾ ഉപയോഗിക്കൂ.”
- “റോളുകൾ ചേർക്കൂ: admin, member. ഓരോ എൻഡ്‌പോയിന്റും ഏത് റോളുകൾക്ക് വിളിക്കാം എന്ന് പട്ടികപ്പെടുത്തൂ.”
- “ഉപയോക്താക്കൾക്ക് സ്വന്തം റെക്കോർഡുകൾ മാത്രം വായിക്കാനും എഡിറ്റ് ചെയ്യാനും കഴിയുമെന്ന് സെർവറിൽ ഉറപ്പാക്കൂ. പിന്നെ എങ്ങനെ പരിശോധിച്ചു എന്ന് കാണിക്കൂ.”
- “ഒരു മണിക്കൂറിൽ കാലഹരണപ്പെടുന്ന ഒരുതവണ മാത്രം ഉപയോഗിക്കാവുന്ന ലിങ്കുകളോടെ പാസ്‌വേഡ് റീസെറ്റ് ചേർക്കൂ.”
- “ലോഗിൻ ശ്രമങ്ങൾക്ക് റേറ്റ് ലിമിറ്റ് ചേർക്കൂ.”
അതിനുശേഷം സ്വയം പരിശോധിക്കുക: രണ്ട് അക്കൗണ്ടുകൾ ഉണ്ടാക്കി, ഒരാളായി ലോഗിൻ ചെയ്തിരിക്കുമ്പോൾ മറ്റൊരാളുടെ ഡാറ്റ എത്താൻ ശ്രമിക്കുക. ലോഗിൻ ചേർക്കുന്നതിനുള്ള ഗൈഡ്, സുരക്ഷാ ചെക്ക്‌ലിസ്റ്റ് എന്നിവ കൂടുതൽ വിശദമാക്കുന്നു.
Mythex-ൽ ഓതന്റിക്കേഷൻ
നിങ്ങളുടെ ആപ്പിലെ ഉപയോക്താക്കൾക്കായി Mythex ബിൽറ്റ്-ഇൻ ഓതന്റിക്കേഷൻ ഉൽപ്പന്നം നൽകുന്നില്ല; നിങ്ങൾ ഒരു രീതി തിരഞ്ഞെടുക്കുന്നു — പ്രോജക്റ്റിന്റെ ഡാറ്റാബേസിൽ സൂക്ഷിക്കുന്ന ഇമെയിലും പാസ്‌വേഡും, അല്ലെങ്കിൽ ഒരു ഹോസ്റ്റ് ചെയ്ത ദാതാവിന്റെ SDK — എന്നിട്ട് ഏജന്റിനോട് അത് ചേർക്കാൻ ആവശ്യപ്പെടുന്നു. ദാതാവിന്റെ കീകൾ പ്രോജക്റ്റ് സീക്രട്ടുകളിൽ വെക്കണം, ചാറ്റിൽ അല്ല. ഇത് Mythex-ലേക്ക് നിങ്ങൾ സൈൻ ഇൻ ചെയ്യുന്ന രീതിയിൽ നിന്ന് വേറിട്ടതാണ്. നിങ്ങളുടെ ആപ്പിൽ ലോഗിൻ ചേർക്കുന്നത് എന്ന ഡോക്സ് റെസിപ്പിയിൽ നിങ്ങൾക്ക് മാറ്റം വരുത്താവുന്ന ഒരു സ്റ്റാർട്ടർ പ്രോംപ്റ്റ് ഉണ്ട്, സെർവർ വശത്തെ പരിശോധനകൾ എവിടെയാണെന്ന് എന്താണ് API വിശദീകരിക്കുന്നു.
ചോദ്യങ്ങൾ
ഓതന്റിക്കേഷനും ഓതറൈസേഷനും തമ്മിലുള്ള വ്യത്യാസം എന്താണ്?
ഓതന്റിക്കേഷൻ നിങ്ങൾ ആരാണെന്ന് പരിശോധിക്കുന്നു, ഉദാഹരണത്തിന് പാസ്‌വേഡ് ഉറപ്പാക്കി. ഓതറൈസേഷൻ നിങ്ങൾ അറിയപ്പെട്ടു കഴിഞ്ഞാൽ എന്ത് ചെയ്യാമെന്ന് തീരുമാനിക്കുന്നു, ഉദാഹരണത്തിന് അഡ്മിൻ പേജ് കാണാമോ അല്ലെങ്കിൽ മറ്റൊരാളുടെ ബുക്കിംഗ് എഡിറ്റ് ചെയ്യാമോ. ആപ്പുകൾക്ക് രണ്ടും വേണം.
എന്താണ് OAuth?
മറ്റൊരു സേവനത്തിലെ നിങ്ങളുടെ അക്കൗണ്ടിലേക്ക് നിങ്ങളുടെ പാസ്‌വേഡ് കാണാതെ പരിമിതമായ പ്രവേശനം നേടാൻ ഒരു ആപ്പിനെ അനുവദിക്കുന്ന സ്റ്റാൻഡേർഡാണ് OAuth 2.0. ‘Google ഉപയോഗിച്ച് സൈൻ ഇൻ ചെയ്യുക’ OAuth 2.0-ന് മുകളിൽ നിർമ്മിച്ച ഒരു ഐഡന്റിറ്റി ലെയറായ OpenID Connect ഉപയോഗിക്കുന്നു, അതിനാൽ നിങ്ങൾ ആരാണെന്ന് ആപ്പ് Google-ൽ നിന്ന് അറിയുന്നു.
എന്റെ ആപ്പ് പാസ്‌വേഡുകൾ സൂക്ഷിക്കണമോ?
വായിക്കാവുന്ന രൂപത്തിൽ ഒരിക്കലും വേണ്ട. ഇമെയിലും പാസ്‌വേഡും ഉപയോഗിച്ചുള്ള ലോഗിൻ ആണെങ്കിൽ, Argon2 അല്ലെങ്കിൽ bcrypt പോലെ പാസ്‌വേഡുകൾക്കായി രൂപകൽപ്പന ചെയ്ത മന്ദഗതിയുള്ള അൽഗോരിതം ഉപയോഗിച്ച് സാൾട്ട് ചേർത്ത ഹാഷുകളായി മാത്രം സൂക്ഷിക്കണം. പല ആപ്പുകളും ഹോസ്റ്റ് ചെയ്ത ഓതൻ പ്രൊവൈഡർ, സോഷ്യൽ ലോഗിൻ, അല്ലെങ്കിൽ ഇമെയിൽ മാജിക് ലിങ്കുകൾ ഉപയോഗിച്ച് ഈ പ്രശ്നം ഒഴിവാക്കുന്നു.
സെഷനോ ടോക്കണോ — എന്റെ ആപ്പ് ഏതാണ് ഉപയോഗിക്കേണ്ടത്?
രണ്ടും പ്രവർത്തിക്കും. സെഷൻ ലോഗിൻ അവസ്ഥ സെർവറിൽ സൂക്ഷിക്കുകയും ബ്രൗസറിന് കുക്കിയിൽ ഒരു റാൻഡം ID നൽകുകയും ചെയ്യുന്നു, അത് എളുപ്പത്തിൽ റദ്ദാക്കാം. JWT പോലുള്ള ടോക്കൺ ഒപ്പിട്ട വിവരങ്ങൾ തന്നെ വഹിക്കുന്നു, അത് API-കൾക്കും മൊബൈൽ ക്ലയന്റുകൾക്കും യോജിക്കുന്നു, പക്ഷേ കാലാവധി തീരുന്നതിന് മുമ്പ് റദ്ദാക്കാൻ പ്രയാസമാണ്. സാധാരണ വെബ് ആപ്പിന് കുക്കി അടിസ്ഥാനമാക്കിയ സെഷനുകൾ നല്ല ഡിഫോൾട്ടാണ്.