ઑથેન્ટિકેશન શું છે? લૉગિન, સેશન અને OAuth સમજાવ્યું
ઑથેન્ટિકેશન એ રીત છે જેનાથી એપ ખાતરી કરે છે કે વપરાશકર્તા કોણ છે — સામાન્ય રીતે કંઈક જે તે જાણે છે (પાસવર્ડ) તે તપાસીને, કંઈક જે તેની પાસે છે (તેના ફોન અથવા ઇમેઇલ પર મોકલાયેલો કોડ), અથવા બીજી વિશ્વસનીય સેવા પરની ઓળખ (જેમ કે "Google સાથે સાઇન ઇન") દ્વારા. એકવાર વપરાશકર્તાની ઓળખ થઈ જાય, એપ તેને સેશન કે ટોકનથી યાદ રાખે છે, જેથી દરેક પેજ પર ફરી લૉગિન ન કરવું પડે. આ ઓળખાયેલો વપરાશકર્તા શું કરી શકે તે નક્કી કરવું એ અલગ પગલું છે, જેને ઑથોરાઇઝેશન કહેવાય છે.
AI સાથે બનાવતી વખતે તે કેમ મહત્વનું છે
લૉગિન ઉમેરવું એ લોકો AI બિલ્ડરને કરતા સૌથી સામાન્ય વિનંતીઓમાંની એક છે, અને તેમાં સૂક્ષ્મ રીતે ખોટું થવું સૌથી સરળ પણ છે. લૉગિન પેજ બનાવવું સરળ છે. મુશ્કેલ ભાગ તેની આસપાસની બધી વસ્તુઓ છે:
- શું પાસવર્ડ સુરક્ષિત રીતે સંગ્રહાય છે?
- શું દરેક ખાનગી પેજ અને દરેક API endpoint ખરેખર તપાસે છે કે કોણ વિનંતી કરે છે?
- શું લૉગિન કરેલો ગ્રાહક URLમાં નંબર બદલીને બીજા ગ્રાહકનો ડેટા જોઈ શકે?
- કોઈ પાસવર્ડ ભૂલી જાય ત્યારે શું થાય છે?
એક એપ આ બધામાં નિષ્ફળ જતી હોય છતાં સંપૂર્ણ સુરક્ષિત દેખાઈ શકે. ચાલતા ભાગો સમજવાથી તમે યોગ્ય પ્રશ્નો પૂછી શકો અને યોગ્ય વસ્તુઓ ચકાસી શકો.
રોજિંદા ઉદાહરણથી સમજ
હોટેલમાં ચેક-ઇન કરવાનો વિચાર કરો.
ફ્રન્ટ ડેસ્ક પર તમે ઓળખપત્ર બતાવો છો. એ ઑથેન્ટિકેશન છે: સાબિત કરવું કે તમે કોણ છો. રિસેપ્શનિસ્ટ પછી તમને કી કાર્ડ આપે છે. એ કાર્ડ તમારું સેશન છે: તમારા રોકાણના બાકીના સમય માટે તમારે ફરી ઓળખપત્ર બતાવવું પડતું નથી; તમે કાર્ડ ટૅપ કરો છો.
કાર્ડ તમારો રૂમ, જિમ અને તમારા ફ્લોરની લિફ્ટ ખોલે છે — પણ બીજા મહેમાનોના રૂમ કે સ્ટાફ ઑફિસ નહીં. એ ઑથોરાઇઝેશન છે: તમારી ઓળખ કઈ વસ્તુઓ સુધી પહોંચી શકે. કાર્ડ ખોવાઈ જાય તો હોટેલ ડેસ્ક પર તેને નિષ્ક્રિય કરી શકે (સેશન રદ કરવું). ચેક-આઉટ વખતે તે કામ કરવાનું બંધ કરે છે (લૉગઆઉટ અથવા સમાપ્તિ).
"Google સાથે સાઇન ઇન" એ એવું છે કે હોટેલ તમારો ઓળખપત્ર પોતે તપાસવાને બદલે વિશ્વસનીય ભાગીદાર તરફથી પત્ર સ્વીકારે કે "આ એ જ વ્યક્તિ છે."
મુખ્ય લૉગિન પદ્ધતિઓ
| પદ્ધતિ | તે કેવી રીતે કામ કરે છે | ફાયદા | ગેરફાયદા |
|---|---|---|---|
| ઇમેઇલ + પાસવર્ડ | વપરાશકર્તા પાસવર્ડ પસંદ કરે; એપ તેનો હૅશ સંગ્રહે | પરિચિત, બહારની નિર્ભરતા નહીં | હૅશને સુરક્ષિત રીતે સંગ્રહવા અને રીસેટ સંભાળવા પડે |
| મેજિક લિંક / એક વખતનો કોડ | એપ ઇમેઇલમાં લિંક અથવા કોડ મોકલે જે વપરાશકર્તાને લૉગિન કરાવે | લીક કે ભૂલાઈ જાય તેવા પાસવર્ડ નહીં | ઇમેઇલ ડિલિવરી પર આધાર; લૉગિન ધીમું |
| સોશિયલ લૉગિન (OAuth / OpenID Connect) | વપરાશકર્તા Google, Apple, GitHub વગેરેથી સાઇન ઇન કરે | વપરાશકર્તાઓ માટે ઝડપી; તમે પાસવર્ડ સંગ્રહતા નથી | દરેક પ્રદાતા સાથે સેટઅપ; જેમની પાસે એ ખાતાં નથી તેવા વપરાશકર્તાઓ |
| હોસ્ટેડ ઑથ પ્રદાતા | Clerk, Auth0 અથવા Supabase Auth જેવી સેવા સાઇન-અપ, લૉગિન અને રીસેટ સંભાળે | તમારા માટે ઓછું સુરક્ષા કામ | મોટા પાયે માસિક ખર્ચ; બીજી નિર્ભરતા |
| મલ્ટી-ફૅક્ટર (MFA / 2FA) | પ્રથમ પછી બીજી ચકાસણી, જેમ કે ઑથેન્ટિકેટર એપનો કોડ | તોડવું ઘણું મુશ્કેલ | થોડું વધુ ઘર્ષણ |
પાસવર્ડ કેવી રીતે સંગ્રહવા જોઈએ
સુરક્ષિત એપ તમારો વાસ્તવિક પાસવર્ડ ક્યારેય સંગ્રહતી નથી. તેના બદલે તે હૅશ સંગ્રહે છે: એક-માર્ગી ફંક્શનનું આઉટપુટ, જે પાસવર્ડને નિશ્ચિત લંબાઈની સ્ટ્રિંગમાં ફેરવે છે. તમે લૉગિન કરો ત્યારે એપ તમે લખેલું હૅશ કરે છે અને પરિણામને સંગ્રહેલા હૅશ સાથે સરખાવે છે.
બે વિગતો આને સુરક્ષિત બનાવે છે:
- સૉલ્ટ — હૅશ કરતાં પહેલાં દરેક પાસવર્ડમાં ઉમેરાતું રેન્ડમ મૂલ્ય, જેથી એક જ પાસવર્ડ ધરાવતા બે લોકોના હૅશ અલગ હોય, અને પહેલેથી ગણેલાં લૂકઅપ ટેબલ નકામાં થાય.
- પાસવર્ડ માટે બનાવેલું ધીમું અલ્ગોરિધમ — જેમ કે Argon2, bcrypt અથવા scrypt. MD5 અથવા SHA-256 જેવા સામાન્ય હેતુના હૅશ પોતે જ બહુ ઝડપી છે; હુમલાખોર અબજો અનુમાન અજમાવી શકે.
હૅશિંગ એ એન્ક્રિપ્શન જેવું નથી. એન્ક્રિપ્ટેડ ડેટા કી વડે ડિક્રિપ્ટ થઈ શકે; પાસવર્ડ હૅશ પાછું ફેરવી ન શકાય તે રીતે બનેલો છે.
સેશન વિરુદ્ધ ટોકન
લૉગિન પછી, એપે દરેક વિનંતી પર તમને ઓળખવું પડે. બે સામાન્ય અભિગમ છે.
| સેશન (કૂકી) | ટોકન (દા.ત. JWT) | |
|---|---|---|
| બ્રાઉઝર શું રાખે છે | કૂકીમાં એક રેન્ડમ સેશન ID | વપરાશકર્તાની માહિતી અને સમાપ્તિ ધરાવતો સહી કરેલો ટોકન |
| લૉગિન સ્થિતિ ક્યાં રહે છે | સર્વર પર, ડેટાબેઝ અથવા સ્ટોરમાં | ટોકનની અંદર જ |
| બધી જગ્યાએથી કોઈને લૉગઆઉટ કરવું | સરળ: સર્વર પર સેશન કાઢી નાખો | મુશ્કેલ: બ્લૉક-લિસ્ટ ન રાખો તો ટોકન સમાપ્ત થાય ત્યાં સુધી માન્ય રહે |
| સામાન્ય ઉપયોગ | પરંપરાગત વેબ એપ | API, મોબાઇલ એપ, એકબીજા સાથે વાત કરતી સેવાઓ |
કૂકી માટે ત્રણ સેટિંગ મહત્વના છે: HttpOnly (પેજ પરનો JavaScript કૂકી વાંચી ન શકે), Secure (ફક્ત HTTPS પર મોકલાય) અને SameSite (બીજી સાઇટ્સની વિનંતીઓમાં તેને મોકલવાને મર્યાદિત કરે). બ્રાઉઝરના localStorageમાં ટોકન રાખવું સામાન્ય છે, પણ તે પેજ પર ચાલતી કોઈપણ સ્ક્રિપ્ટને ખુલ્લા પાડે છે.
OAuth અને "Google સાથે સાઇન ઇન"
OAuth 2.0 સોંપાયેલ ઑથોરાઇઝેશન માટેનું માનક છે: તે એપને બીજી સેવા પર તમારા ખાતામાં મર્યાદિત પ્રવેશ આપવા દે છે — જેમ કે તમારું Google Calendar વાંચવું — તમારો Google પાસવર્ડ જોયા વગર. તમને Google પર મોકલાય છે, તમે ચોક્કસ પરવાનગીઓ (જેને scopes કહે છે) મંજૂર કરો છો, અને Google એપને ફક્ત એ પરવાનગીઓ માટેનો ટોકન આપે છે.
OAuth પોતે પ્રવેશ આપવા માટે બનાવાયું હતું, તમે કોણ છો તે કહેવા માટે નહીં. OpenID Connect (OIDC) એ OAuth 2.0 પર બનેલો સ્તર છે જે ઓળખ ઉમેરે છે, અને "Google સાથે સાઇન ઇન" અથવા "Apple સાથે સાઇન ઇન" એ જ વાપરે છે. તેને સેટ કરવા માટે તમે પ્રદાતા પર તમારી એપ નોંધાવો છો અને client ID તથા client secret મેળવો છો; સિક્રેટ તમારા સર્વર પર જ રહે છે.
કામ કરેલું ઉદાહરણ: ક્લાયન્ટ પોર્ટલ માટે લૉગિન
ધારો કે તમે એવું પોર્ટલ બનાવો છો જ્યાં એક ડિઝાઇન એજન્સીના ગ્રાહકો તેમના પ્રોજેક્ટ અને ઇન્વૉઇસ જુએ છે.
- ઑથેન્ટિકેશન: ગ્રાહકો ઇમેઇલ અને મેજિક લિંકથી લૉગિન કરે છે, એટલે સંભાળવા માટે કોઈ પાસવર્ડ નથી. એજન્સીનો સ્ટાફ Google Workspace ખાતાંથી લૉગિન કરે છે.
- રોલ: દરેક વપરાશકર્તાનો રોલ હોય છે —
clientઅથવાstaff. - ઑથોરાઇઝેશન નિયમો:
| ક્રિયા | ગ્રાહક | સ્ટાફ |
|---|---|---|
| પોતાની કંપનીના પ્રોજેક્ટ જોવા | હા | હા |
| બીજી કંપનીઓના પ્રોજેક્ટ જોવા | ના | હા |
| પ્રોજેક્ટમાં ફાઇલ અપલોડ કરવી | ફક્ત પોતાના પ્રોજેક્ટ | હા |
| ઇન્વૉઇસ ચુકવાયેલું ચિહ્નિત કરવું | ના | હા |
- ક્યાં લાગુ કરાય છે: દરેક વિનંતી માટે સર્વર પર. સર્વર લૉગિન કરેલા વપરાશકર્તાને શોધે છે, પછી ફક્ત એવા પ્રોજેક્ટ પાછા આપે છે જ્યાં
project.company_idવપરાશકર્તાની કંપની સાથે મેળ ખાય. "Mark paid" બટન છુપાવવું પૂરતું નથી — endpoint પોતે ના પાડવો જોઈએ.
સામાન્ય શબ્દોની સમજૂતી
| શબ્દ | અર્થ |
|---|---|
| ઑથેન્ટિકેશન (AuthN) | કોઈ કોણ છે તે ખાતરી કરવી. |
| ઑથોરાઇઝેશન (AuthZ) | તેઓ શું કરી શકે તે નક્કી કરવું. |
| સેશન | વિનંતીઓ વચ્ચે એપ યાદ રાખે કે તમે લૉગિન છો. |
| કૂકી | એક નાનો ડેટા ટુકડો જે બ્રાઉઝર દરેક વિનંતી સાથે સાઇટને પાછો મોકલે. |
| JWT | JSON Web Token: સહી કરેલો, નાનો ટોકન જેમાં વપરાશકર્તા ID અને સમાપ્તિ જેવી માહિતી હોય. |
| રોલ / પરવાનગી | admin કે member જેવા લેબલ જે પ્રવેશ નક્કી કરે. |
| MFA / 2FA | ઑથેન્ટિકેટર એપના કોડ જેવો બીજો પુરાવો માગવો. |
| SSO | સિંગલ સાઇન-ઑન: ઘણી એપ માટે એક લૉગિન (ઘણીવાર કંપનીનું ખાતું). |
| 401 વિરુદ્ધ 403 | "તમે કોણ છો?" (ઓળખ ન થઈ) વિરુદ્ધ "તમે એ નહીં કરી શકો" (અધિકૃત નથી). |
સામાન્ય ભૂલો અને ગેરસમજો
- ફક્ત પેજમાં પરવાનગીઓ તપાસવી. જો બ્રાઉઝર બટન છુપાવે પણ API તપાસે નહીં, તો કોઈપણ સીધો API કૉલ કરી શકે.
- URLમાંના IDને વિશ્વાસ કરવો.
/invoices/1042એ તપાસવું જોઈએ કે ઇન્વૉઇસ 1042 લૉગિન કરેલા વપરાશકર્તાનો છે. - પોતાની ક્રિપ્ટો બનાવવી. જાણીતી લાઇબ્રેરી અથવા પ્રદાતા વાપરો; AIને હૅશિંગ સ્કીમ શોધવા ન દો.
- નબળું પાસવર્ડ રીસેટ. રીસેટ લિંક એક વખત વાપરી શકાય તેવી, ઝડપથી સમાપ્ત થતી હોવી જોઈએ અને ઇમેઇલનું ખાતું છે કે નહીં તે જાહેર ન કરે.
- તમારા લૉગિનને બિલ્ડરના લૉગિન સાથે ભેળવવું. તમારી એપના વપરાશકર્તાઓ એ ટૂલ પરના તમારા ખાતાથી અલગ છે જેના પર તમે બનાવો છો.
- લૉગિન પર રેટ લિમિટ નહીં. તેના વગર હુમલાખોર અનંત વાર પાસવર્ડ અજમાવી શકે.
તમારા AI બિલ્ડરને શું માંગવું
- "[જાણીતી લાઇબ્રેરી અથવા પ્રદાતા] વાપરીને સાઇન-અપ અને લૉગિન ઉમેરો. કસ્ટમ પાસવર્ડ હૅશિંગ ન લખો."
- "પાસવર્ડ bcrypt અથવા Argon2 વડે હૅશ કરીને સંગ્રહો."
- "સેશન માટે HttpOnly, Secure કૂકી વાપરો."
- "રોલ ઉમેરો: admin અને member. દરેક endpoint અને કયા રોલ તેને કૉલ કરી શકે તેની યાદી આપો."
- "સર્વર પર ખાતરી કરો કે વપરાશકર્તાઓ ફક્ત પોતાના રેકૉર્ડ વાંચી અને બદલી શકે. પછી બતાવો કે તમે કેવી રીતે તપાસ્યું."
- "પાસવર્ડ રીસેટ ઉમેરો, એક વખતની લિંક સાથે જે એક કલાકમાં સમાપ્ત થાય."
- "લૉગિન પ્રયાસો પર રેટ લિમિટ લગાવો."
પછી જાતે ચકાસો: બે ખાતાં બનાવો અને એક લૉગિન હોય ત્યારે બીજાનો ડેટા સુધી પહોંચવાનો પ્રયાસ કરો. લૉગિન ઉમેરવાની માર્ગદર્શિકા અને સુરક્ષા ચેકલિસ્ટ વધુ વિગત આપે છે.
Mythex માં ઑથેન્ટિકેશન
Mythex તમારી એપના વપરાશકર્તાઓ માટે બિલ્ટ-ઇન ઑથ પ્રોડક્ટ આપતું નથી; તમે એક અભિગમ પસંદ કરો — તમારા પ્રોજેક્ટના ડેટાબેઝમાં સંગ્રહાતાં ઇમેઇલ અને પાસવર્ડ, અથવા હોસ્ટેડ પ્રદાતાનો SDK — અને એજન્ટને તે ઉમેરવા કહો. પ્રદાતાની કી પ્રોજેક્ટ સિક્રેટમાં જાય છે, ચેટમાં નહીં. આ Mythex પોતામાં કેવી રીતે સાઇન ઇન કરવું તેનાથી અલગ છે. તમારી એપમાં લૉગિન ઉમેરવા વિશેની docs રેસિપીમાં એક સ્ટાર્ટર પ્રોમ્પ્ટ છે જે તમે અનુકૂળ કરી શકો, અને API શું છે સમજાવે છે કે સર્વર-બાજુની એ તપાસો ક્યાં રહે છે.
પ્રશ્નો
ઑથેન્ટિકેશન અને ઑથોરાઇઝેશન વચ્ચે શો ફરક છે?
ઑથેન્ટિકેશન તપાસે છે કે તમે કોણ છો, જેમ કે તમારો પાસવર્ડ ચકાસીને. ઑથોરાઇઝેશન નક્કી કરે છે કે તમને ઓળખાઈ ગયા પછી તમે શું કરી શકો, જેમ કે તમે એડમિન પેજ જોઈ શકો કે કોઈ બીજાનું બુકિંગ બદલી શકો. એપને બંનેની જરૂર છે.
OAuth શું છે?
OAuth 2.0 એક માનક છે જે એપને બીજી સેવા પર તમારા ખાતામાં મર્યાદિત પ્રવેશ આપવા દે છે, તમારો પાસવર્ડ જોયા વગર. 'Google સાથે સાઇન ઇન' OpenID Connect વાપરે છે, જે OAuth 2.0 પર બનેલો ઓળખ સ્તર છે, એટલે એપ Google પરથી જાણે છે કે તમે કોણ છો.
શું મારી એપે પાસવર્ડ સંગ્રહવા જોઈએ?
વાંચી શકાય તેવા સ્વરૂપમાં ક્યારેય નહીં. જો તમે ઇમેઇલ અને પાસવર્ડ લૉગિન વાપરો, તો પાસવર્ડ સૉલ્ટેડ હૅશ તરીકે સંગ્રહવા જોઈએ, જે પાસવર્ડ માટે બનાવેલા ધીમા અલ્ગોરિધમથી બને, જેમ કે Argon2 અથવા bcrypt. ઘણી એપ હોસ્ટેડ ઑથ પ્રદાતા, સોશિયલ લૉગિન અથવા ઇમેઇલ મેજિક લિંક વાપરીને આ સમસ્યા ટાળે છે.
સેશન કે ટોકન — મારી એપે કયું વાપરવું?
બંને કામ કરે છે. સેશન લૉગિનની સ્થિતિ સર્વર પર સંગ્રહે છે અને બ્રાઉઝરને કૂકીમાં એક રેન્ડમ ID આપે છે, જે રદ કરવું સરળ છે. JWT જેવો ટોકન પોતે સહી કરેલી માહિતી ધરાવે છે, જે API અને મોબાઇલ ક્લાયન્ટ માટે યોગ્ય છે, પણ એક્સપાયર થતાં પહેલાં રદ કરવું મુશ્કેલ છે. સામાન્ય વેબ એપ માટે કૂકી-આધારિત સેશન સારો ડિફોલ્ટ છે.