Ano ang Authentication? Logins, Sessions at OAuth, Ipinaliwanag

Ang authentication ay paraan ng app para kumpirmahin kung sino ang user. Kadalasan, tinitingnan nito ang alam ng user (password), ang hawak niya (code na ipinadala sa telepono o email), o ang identity mula sa mapagkakatiwalaang serbisyo (gaya ng “Sign in with Google”). Kapag na-authenticate na ang user, inaalala siya ng app gamit ang session o token para hindi na siya mag-log in sa bawat pahina. Hiwalay na hakbang ang pagpapasya kung ano ang puwedeng gawin ng kilalang user, at tinatawag itong authorization.

Bakit ito mahalaga kapag gumagawa ka gamit ang AI

Isa sa pinakakaraniwang hiling sa AI builder ang pagdagdag ng login, at isa rin sa pinakamadaling magkamali. Madaling i-generate ang login page. Ang mahirap ay ang lahat ng nasa paligid nito:

• Ligtas ba ang pag-iimbak ng passwords?
• Tinitingnan ba ng bawat pribadong pahina at bawat API endpoint kung sino ang humihiling?
• Makakakita ba ng data ng ibang customer ang naka-login na customer sa pamamagitan ng pagbago ng numero sa URL?
• Ano ang mangyayari kapag may nakalimutan ng password?

Puwedeng mukhang ligtas ang isang app kahit pumapalya ito sa lahat ng iyon. Ang pag-unawa sa mga gumagalaw na bahagi ay tutulong sa iyo na magtanong ng tamang tanong at subukan ang tamang bagay.

Isang halimbawang pang-araw-araw

Isipin ang pag-check in sa hotel.

Sa front desk, ipinapakita mo ang ID mo. Iyon ang authentication: pagpapatunay kung sino ka. Binibigyan ka ng receptionist ng key card. Ang card na iyon ang iyong session: sa buong pamamalagi mo, hindi mo na kailangang ipakita ang ID; i-tap mo lang ang card.

Binubuksan ng card mo ang kuwarto mo, ang gym at ang elevator papunta sa palapag mo, pero hindi ang kuwarto ng ibang bisita o ang opisina ng staff. Iyon ang authorization: kung ano ang pinapayagan mong i-access batay sa pagkakakilanlan mo. Kapag nawala ang card, puwedeng i-deactivate ito ng hotel sa desk (pagbawi ng session). Kapag nag-check out ka, hihinto itong gumana (logout o expiry).

Ang “Sign in with Google” ay parang hotel na tumatanggap ng sulat mula sa kasosyong mapagkakatiwalaan na nagsasabing “ito ang taong ito,” sa halip na sila mismo ang tumingin sa ID mo.

Mga pangunahing paraan ng login

Paano dapat i-store ang passwords

Hindi kailanman itinatago ng ligtas na app ang mismong password mo. Ang iniimbak nito ay hash: ang output ng one-way function na ginagawang nakapirmang string ang password. Kapag nag-log in ka, hina-hash ng app ang tinype mo at ikinukumpara ang resulta sa naka-store na hash.

Dalawang detalye ang nagpapaligtas nito:

• Isang salt, isang random na value na idinadagdag sa bawat password bago i-hash, para magkaiba ang hash ng dalawang taong may parehong password, at walang saysay ang mga precomputed lookup table.
• Mabagal na algorithm na ginawa para sa passwords, gaya ng Argon2, bcrypt o scrypt. Masyadong mabilis ang mga general-purpose hash gaya ng MD5 o SHA-256; kayang subukan ng attacker ang bilyon-bilyong hula.

Hindi pareho ang hashing at encryption. Puwedeng i-decrypt ang encrypted data gamit ang key; dinisenyo ang password hash na hindi na maibalik sa dating anyo.

Sessions vs tokens

Pagkatapos ng login, kailangang makilala ng app ka sa bawat request. May dalawang karaniwang paraan.

Para sa cookies, tatlong setting ang mahalaga: HttpOnly (hindi mababasa ng JavaScript sa pahina ang cookie), Secure (ipinapadala lang sa HTTPS) at SameSite (nililimitahan ang pagpapadala nito sa mga request mula sa ibang site). Karaniwan ang pag-iimbak ng tokens sa localStorage ng browser, pero nalalantad ang mga ito sa anumang script na tumatakbo sa pahina.

OAuth at “Sign in with Google”

Ang OAuth 2.0 ay standard para sa delegated authorization: pinapayagan nitong makakuha ang app ng limitadong access sa account mo sa ibang serbisyo, halimbawa para basahin ang Google Calendar mo, nang hindi nakikita ang Google password mo. Ipapadala ka sa Google, aaprubahan mo ang mga partikular na pahintulot (tinatawag na scopes), at magbibigay ang Google ng token sa app para lang sa mga pahintulot na iyon.

Noong idinisenyo ang OAuth, pangunahing pagbibigay ng access ang layunin nito, hindi ang pagsasabi kung sino ka. Ang OpenID Connect (OIDC) ay layer sa ibabaw ng OAuth 2.0 na nagdaragdag ng identity, at ito ang ginagamit ng “Sign in with Google” o “Sign in with Apple.” Para i-set up ito, ipinaparehistro mo ang app sa provider at kumukuha ka ng client ID at client secret; nananatili sa server mo ang secret.

Isang halimbawang gawa: login para sa client portal

Isipin mong gumagawa ka ng portal kung saan nakikita ng mga kliyente ng isang design agency ang kanilang mga proyekto at invoice.

• Authentication: nag-log in ang mga kliyente gamit ang email at magic link, kaya walang passwords na kailangang pamahalaan. Ang staff ng agency ay nag-log in gamit ang Google Workspace accounts.
• Roles: may role ang bawat user, client o staff.
• Mga patakaran sa authorization:

• Saan ipinapatupad: sa server, para sa bawat request. Hahanapin ng server ang naka-log in na user, at ibabalik lang ang mga proyektong tugma ang project.company_id sa kumpanya ng user. Hindi sapat ang pagtatago ng “Mark paid” button; kailangang tanggihan ito ng endpoint mismo.

Mga karaniwang termino

Mga karaniwang pagkakamali at maling akala

• Pagsusuri ng permissions sa pahina lang. Kung itinatago ng browser ang button pero hindi sinusuri ng API, sinumang makakatawag nang direkta sa API ay makakagawa ng gusto niya.
• Pagtitiwala sa IDs mula sa URL. Dapat tiyakin ng /invoices/1042 na pag-aari ng naka-log in na user ang invoice 1042.
• Pag-imbento ng sariling crypto. Gumamit ng kilalang libraries o provider; huwag hayaang mag-imbento ng sariling hashing scheme ang AI.
• Mahinang password reset. Dapat isang beses lang magamit ang reset links, mabilis mag-expire, at hindi nagsasabi kung may account ang isang email.
• Paghahalo ng login mo sa login ng builder mo. Hiwalay ang mga user ng app mo sa account mo sa tool na ginagamit mo para gumawa nito.
• Walang rate limiting sa login. Kung walang ito, puwedeng sumubok nang walang katapusan ang attacker ng passwords.

Ano ang hihilingin sa AI builder mo

• “Magdagdag ng sign-up at login gamit ang [isang kilalang library o provider]. Huwag gumawa ng sariling password hashing.”
• “Mag-store ng passwords na naka-hash gamit ang bcrypt o Argon2.”
• “Gumamit ng HttpOnly at Secure na cookies para sa session.”
• “Magdagdag ng roles: admin at member. Ilista ang bawat endpoint at kung aling roles ang puwedeng tumawag dito.”
• “Ipatupad sa server na mababasa at mae-edit lang ng user ang sarili niyang records. Pagkatapos, ipakita kung paano mo ito chineck.”
• “Magdagdag ng password reset na may single-use links na nag-e-expire sa loob ng isang oras.”
• “Limitahan ang bilang ng login attempts.”

Pagkatapos, subukan mo mismo: gumawa ng dalawang account at tingnan kung makakapunta ka sa data ng isa habang naka-log in bilang isa pa. Mas marami pang detalye sa gabay sa pagdagdag ng login at security checklist.

Authentication sa Mythex

Hindi nagbibigay ang Mythex ng built-in na auth product para sa mga user ng app mo. Pumipili ka ng paraan, gaya ng email at password na naka-store sa database ng project mo, o SDK ng hosted provider, at hihilingin mo sa agent na idagdag ito. Ang provider keys ay nasa project secrets, hindi sa chat. Hiwalay ito sa kung paano ka nag-sa-sign in sa Mythex mismo. Ang docs recipe tungkol sa pagdagdag ng login sa app mo ay may starter prompt na puwede mong baguhin, at ipinapaliwanag ng ano ang API kung saan nakatira ang mga server-side check na iyon.

Mga tanong