Uthibitishaji ni Nini? Logins, Sessions na OAuth Zilivyoelezwa

Uthibitishaji ni jinsi app inavyothibitisha mtumiaji ni nani — kwa kawaida kwa kukagua kitu anachokijua (password), kitu alichonacho (msimbo unaotumwa kwenye simu au email), au utambulisho kutoka huduma nyingine inayoaminika (kama “Sign in with Google”). Mara mtumiaji anapothibitishwa, app inamkumbuka kwa session au token ili asilazimike kuingia kila ukurasa. Kuamua mtumiaji huyo anayejulikana anaruhusiwa kufanya nini ni hatua tofauti inayoitwa ruhusa (authorization).

Kwa nini ni muhimu unapojenga na AI

Kuongeza login ni mojawapo ya maombi ya kawaida kwa AI builder, na pia moja ya rahisi kukosea kwa hila. Ukurasa wa login ni rahisi kuzalisha. Kazi ngumu ni kila kitu kinachouzunguka:

• Je, passwords zinahifadhiwa kwa usalama?
• Je, kila ukurasa wa faragha na kila API endpoint kweli inakagua anayeomba?
• Je, mteja aliyeingia anaweza kuona data ya mteja mwingine kwa kubadilisha namba kwenye URL?
• Nini kinatokea mtu akisahau password yake?

App inaweza kuonekana salama kabisa huku ikishindwa katika yote hayo. Kuelewa sehemu zinazosonga kunakusaidia kuuliza maswali sahihi na kujaribu mambo sahihi.

Mfano wa kila siku

Fikiria kuingia hoteli.

Kwenye dawati la mapokezi unaonyesha kitambulisho. Hiyo ni uthibitishaji: kuthibitisha wewe ni nani. Mpokeaji kisha anakupa kadi ya ufunguo. Kadi hiyo ni session yako: kwa muda wote wa kukaa hutaonyesha kitambulisho tena; unagusa kadi tu.

Kadi inafungua chumba chako, gym na lifti ya ghorofa yako — lakini si vyumba vya wageni wengine wala ofisi ya wafanyakazi. Hiyo ni ruhusa: utambulisho wako unaruhusiwa kufikia nini. Ukipoteza kadi, hoteli inaweza kuizima kwenye dawati (kubatilisha session). Ukiondoka, inaacha kufanya kazi (kutoka au kuisha muda).

“Sign in with Google” ni kama hoteli inayokubali barua kutoka kwa mshirika anayeaminika ikisema “huyu ndiye mtu huyu,” badala ya kukukagua kitambulisho yenyewe.

Njia kuu za login

Passwords zinapaswa kuhifadhiwa vipi

App salama haihifadhi password yako halisi kamwe. Badala yake huhifadhi hash: matokeo ya kazi ya njia moja inayogeuza password kuwa mfuatano usiobadilika. Unapoingia, app inahash kile ulichoandika na kulinganisha matokeo na hash iliyohifadhiwa.

Mambo mawili yanaifanya iwe salama:

• Salt — thamani ya kubahatisha inayoongezwa kwenye kila password kabla ya kuhash, ili watu wawili wenye password moja wapate hashes tofauti, na majedwali ya kutafuta yaliyotayarishwa awali yasifae.
• Algorithm ya polepole iliyoundwa kwa passwords — kama Argon2, bcrypt au scrypt. Hashes za madhumuni ya jumla kama MD5 au SHA-256 ni za haraka mno peke yake; washambuliaji wanaweza kujaribu mabilioni ya makisio.

Hashing si sawa na encryption. Data iliyosimbwa inaweza kufunguliwa kwa key; hash ya password imeundwa isiweze kurudishwa kabisa.

Sessions dhidi ya tokens

Baada ya login, app inahitaji kukutambua kila ombi. Kuna njia mbili za kawaida.

Kwa cookies, mipangilio mitatu ni muhimu: HttpOnly (JavaScript kwenye ukurasa haiwezi kuisoma), Secure (inatumwa kupitia HTTPS pekee) na SameSite (inazuia kuituma kwenye maombi kutoka tovuti nyingine). Kuhifadhi tokens kwenye localStorage ya browser ni jambo la kawaida lakini linazifanya ziwe wazi kwa script yoyote inayoendeshwa kwenye ukurasa.

OAuth na “Sign in with Google”

OAuth 2.0 ni kiwango cha ruhusa iliyokabidhiwa: kinaruhusu app kupata ufikiaji mdogo wa akaunti yako kwenye huduma nyingine — kwa mfano, kusoma kalenda yako ya Google — bila kamwe kuona password yako ya Google. Unatumwa Google, unaidhinisha ruhusa maalum (zinaitwa scopes), na Google inaipa app token kwa ruhusa hizo tu.

OAuth peke yake iliundwa kutoa ufikiaji, si kusema wewe ni nani. OpenID Connect (OIDC) ni safu juu ya OAuth 2.0 inayoongeza utambulisho, ndicho kinachotumiwa na “Sign in with Google” au “Sign in with Apple”. Ili kuisanidi unasajili app yako kwa mtoa huduma na kupata client ID na client secret; secret inakaa kwenye server yako.

Mfano wa vitendo: login kwa portal ya wateja

Tuseme unajenga portal ambapo wateja wa wakala wa usanifu wanaona miradi na ankara zao.

• Uthibitishaji: wateja wanaingia kwa email na magic link, hivyo hakuna passwords za kusimamia. Wafanyakazi wa wakala wanaingia kwa akaunti za Google Workspace.
• Roles: kila mtumiaji ana role — client au staff.
• Kanuni za ruhusa:

• Mahali inapotekelezwa: kwenye server, kwa kila ombi. Server inamtafuta mtumiaji aliyeingia, kisha inarudisha miradi tu ambapo project.company_id inalingana na kampuni ya mtumiaji. Kuficha kitufe cha “Mark paid” haitoshi — endpoint yenyewe lazima ikatae.

Maneno ya kawaida yaliyofafanuliwa

Makosa ya kawaida na dhana potofu

• Kukagua ruhusa kwenye ukurasa tu. Ikiwa browser inaficha kitufe lakini API haikagui, mtu yeyote anaweza kuita API moja kwa moja.
• Kuamini IDs zilizo kwenye URL. /invoices/1042 lazima ikague kuwa ankara 1042 ni ya mtumiaji aliyeingia.
• Kuunda crypto yako mwenyewe. Tumia libraries au providers zinazojulikana; usimwache AI ibuni mpango wake wa hashing.
• Kuweka upya password dhaifu. Viungo vya kuweka upya vinapaswa kutumika mara moja, viishe haraka na visifichue kama email ina akaunti.
• Kuchanganya login yako na ya builder yako. Watumiaji wa app yako ni tofauti na akaunti yako kwenye zana unayojengea.
• Hakuna kikomo cha majaribio ya login. Bila hicho, washambuliaji wanaweza kujaribu passwords bila kikomo.

Uulize nini AI builder yako

• “Ongeza usajili na login kwa kutumia [library au provider inayojulikana]. Usiandike hashing ya password yako mwenyewe.”
• “Hifadhi passwords zikiwa zimehashiwa kwa bcrypt au Argon2.”
• “Tumia cookies za HttpOnly na Secure kwa session.”
• “Ongeza roles: admin na member. Orodhesha kila endpoint na roles zinazoruhusiwa kuiita.”
• “Lazimisha kwenye server kwamba watumiaji wanaweza kusoma na kuhariri rekodi zao tu. Kisha nionyeshe jinsi ulivyokagua.”
• “Ongeza kuweka upya password kwa viungo vya mara moja vinavyoisha baada ya saa moja.”
• “Weka kikomo cha majaribio ya login.”

Kisha jaribu mwenyewe: fungua akaunti mbili na ujaribu kufikia data ya mmoja ukiwa umeingia kama mwingine. Mwongozo wa kuongeza login na orodha ya ukaguzi wa usalama zinaenda mbali zaidi.

Uthibitishaji kwenye Mythex

Mythex haitoi bidhaa ya uthibitishaji iliyojengwa ndani kwa watumiaji wa app yako; unachagua mbinu — email na password zilizohifadhiwa kwenye database ya project yako, au SDK ya hosted provider — kisha unamwomba agent aiongeze. Keys za provider huwekwa kama project secrets, si kwenye chat. Hii ni tofauti na jinsi unavyoingia Mythex yenyewe. Recipe ya nyaraka kuhusu kuongeza login kwenye app yako ina starter prompt unayoweza kurekebisha, na API ni nini inaeleza mahali ukaguzi wa upande wa server unapoishi.

Maswali