Kaj je avtentikacija? Prijave, seje in OAuth pojasnjeni

Avtentikacija je način, kako aplikacija potrdi, kdo je uporabnik – običajno s preverjanjem nečesa, kar uporabnik ve (geslo), nečesa, kar ima (kodo, poslano na telefon ali e-pošto), ali identitete pri drugi zaupanja vredni storitvi (na primer »Prijava z Googlom«). Ko je uporabnik avtenticiran, ga aplikacija zapomni prek seje ali žetona, da se ne bi moral prijaviti na vsaki strani. Odločitev, kaj ta znani uporabnik sme početi, je ločen korak, imenovan avtorizacija.

Zakaj je to pomembno, ko gradite z AI

Dodajanje prijave je ena najpogostejših prošenj graditeljem z AI in ena, pri kateri je zlahka nekaj subtilno narobe. Stran za prijavo je preprosta za generiranje. Težko je vse okoli nje:

• Ali so gesla shranjena varno?
• Ali vsaka zasebna stran in vsaka točka API-ja res preveri, kdo sprašuje?
• Ali lahko prijavljena stranka vidi podatke druge stranke, če spremeni številko v URL-ju?
• Kaj se zgodi, ko nekdo pozabi geslo?

Aplikacija je lahko videti popolnoma varna, pa ob tem pade na vseh teh vprašanjih. Če razumete gibljive dele, lahko postavite prava vprašanja in preverite prave stvari.

Vsakdanja primerjava

Pomislite na prijavo v hotel.

Na recepciji pokažete osebni dokument. To je avtentikacija: dokazovanje, kdo ste. Recepcionist vam nato da kartico za sobo. Ta kartica je vaša seja: za preostanek bivanja ne pokazujete več dokumenta, samo kartico.

Kartica odpre vašo sobo, fitnes in dvigalo do vašega nadstropja – ne pa sob drugih gostov ali pisarne osebja. To je avtorizacija: do česa vaša identiteta sme dostopati. Če kartico izgubite, jo lahko recepcija deaktivira (preklic seje). Ob odjavi preneha delovati (odjava ali potek).

»Prijava z Googlom« je kot da hotel sprejme pismo zaupanja vredne partnerske ustanove, ki pravi »to je ta oseba«, namesto da bi sam preveril vaš osebni dokument.

Glavne metode prijave

Kako je treba shranjevati gesla

Varna aplikacija nikoli ne shrani vašega dejanskega gesla. Namesto tega shrani zgoščeno vrednost (hash): rezultat enosmerne funkcije, ki geslo spremeni v fiksen niz. Ko se prijavite, aplikacija zgosti, kar ste vtipkali, in primerja rezultat s shranjeno zgoščeno vrednostjo.

Dve podrobnosti naredita to varno:

• Sol – naključna vrednost, dodana vsakemu geslu pred zgoščevanjem, tako da imata dva človeka z enakim geslom različni zgoščeni vrednosti, predizračunane tabele iskanja pa so neuporabne.
• Počasen algoritem, narejen za gesla – na primer Argon2, bcrypt ali scrypt. Splošne zgoščevalne funkcije, kot sta MD5 ali SHA-256, so same po sebi preveč hitre; napadalci lahko preizkusijo milijarde ugibanj.

Zgoščevanje ni isto kot šifriranje. Šifrirane podatke lahko z ključem dešifriramo; zgoščena vrednost gesla je zasnovana tako, da je sploh ne moremo obrniti.

Seje proti žetonom

Po prijavi mora aplikacija pri vsaki zahtevi prepoznati, kdo ste. Obstajata dva pogosta pristopa.

Za piškotke so pomembne tri nastavitve: HttpOnly (JavaScript na strani ne more brati piškotka), Secure (pošlje se samo prek HTTPS) in SameSite (omeji pošiljanje zahtevkov z drugih spletnih mest). Shranjevanje žetonov v localStorage brskalnika je pogosto, vendar jih izpostavi vsaki skripti, ki teče na strani.

OAuth in »Prijava z Googlom«

OAuth 2.0 je standard za delegirano avtorizacijo: aplikaciji omogoča omejen dostop do vašega računa pri drugi storitvi – recimo branje vašega Google koledarja – brez da bi kdaj videla vaše Google geslo. Preusmerjeni ste k Googlu, odobrite določena dovoljenja (imenovana obsegi ali scopes), Google pa aplikaciji da žeton samo za ta dovoljenja.

OAuth sam po sebi je bil zasnovan za dodeljevanje dostopa, ne za to, da bi povedal, kdo ste. OpenID Connect (OIDC) je plast na vrhu OAuth 2.0, ki dodaja identiteto – to uporablja »Prijava z Googlom« ali »Prijava z Applom«. Za nastavitev aplikacijo registrirate pri ponudniku in dobite ID odjemalca ter skrivnost odjemalca; skrivnost ostane na vašem strežniku.

Praktičen primer: prijava za portal strank

Recimo, da gradite portal, kjer stranke oblikovalske agencije vidijo svoje projekte in račune.

• Avtentikacija: stranke se prijavijo z e-pošto in povezavo za prijavo, tako da ni gesel za upravljanje. Zaposleni v agenciji se prijavijo z računi Google Workspace.
• Vloge: vsak uporabnik ima vlogo – client ali staff.
• Pravila avtorizacije:

• Kje se uveljavlja: na strežniku, za vsako zahtevo. Strežnik poišče prijavljenega uporabnika in vrne samo projekte, kjer se project.company_id ujema s podjetjem uporabnika. Skrivanje gumba »Označi plačano« ni dovolj – končna točka sama mora zavrniti zahtevo.

Pogosti pojmi

Pogoste napake in zmote

• Preverjanje dovoljenj samo v vmesniku. Če brskalnik skrije gumb, API pa ne preveri, lahko vsak pokliče API neposredno.
• Zaupanje ID-jem iz URL-ja. /invoices/1042 mora preveriti, da račun 1042 pripada prijavljenemu uporabniku.
• Izumljanje lastne kriptografije. Uporabite dobro znane knjižnice ali ponudnike; AI naj ne izmišlja sheme zgoščevanja.
• Šibka ponastavitev gesla. Povezave za ponastavitev morajo veljati samo enkrat, hitro poteči in ne smejo razkriti, ali ima e-poštni naslov račun.
• Mešanje vaše prijave s prijavo graditelja. Uporabniki vaše aplikacije so ločeni od vašega računa pri orodju, s katerim gradite.
• Brez omejitve poskusov prijave. Brez nje lahko napadalci neskončno preizkušajo gesla.

Kaj zahtevati od svojega graditelja z AI

• »Dodaj registracijo in prijavo z [dobro znano knjižnico ali ponudnikom]. Ne piši lastnega zgoščevanja gesel.«
• »Shrani gesla zgoščena z bcrypt ali Argon2.«
• »Za sejo uporabi piškotke HttpOnly in Secure.«
• »Dodaj vloge: admin in member. Naštej vsako končno točko in katere vloge jo smejo klicati.«
• »Na strežniku uveljavi, da lahko uporabniki berejo in urejajo samo svoje zapise. Nato mi pokaži, kako si to preveril.«
• »Dodaj ponastavitev gesla z enkratnimi povezavami, ki potečejo v eni uri.«
• »Omeji število poskusov prijave.«

Nato preizkusite sami: ustvarite dva računa in poskusite dostopati do podatkov enega, medtem ko ste prijavljeni kot drugi. Naš vodnik za dodajanje prijave in kontrolni seznam varnosti gresta dlje.

Avtentikacija v Mythex

Mythex ne ponuja vgrajenega izdelka za avtentikacijo uporabnikov vaše aplikacije; izberete pristop – e-pošto in geslo, shranjena v bazi podatkov vašega projekta, ali SDK gostovanega ponudnika – in agenta prosite, naj ga doda. Ključi ponudnika gredo v tajnosti projekta, ne v klepet. To je ločeno od tega, kako se prijavljate v sam Mythex. Recept v dokumentaciji o dodajanju prijave v aplikacijo vsebuje začetni poziv, ki ga lahko prilagodite, kaj je API pa pojasni, kje živijo ta preverjanja na strežniku.

Vprašanja