Šta je autentifikacija? Prijave, sesije i OAuth objašnjeni

Autentifikacija je način na koji aplikacija potvrđuje ko je korisnik, obično proverom nečega što zna (lozinka), nečega što ima (kod poslat na telefon ili imejl) ili identiteta iz drugog pouzdanog servisa (kao što je „Prijavi se preko Google-a“). Kada je korisnik autentifikovan, aplikacija ga pamti pomoću sesije ili tokena, pa se ne mora prijavljivati na svakoj stranici. Odlučivanje šta taj poznati korisnik sme da radi je poseban korak, koji se zove autorizacija.

Zašto je važno kada praviš aplikaciju uz AI

Dodavanje prijave je jedan od najčešćih zahteva koje ljudi postavljaju AI alatu, i jedan od onih koji se lako pogreše. Stranicu za prijavu je jednostavno generisati. Teško je sve ostalo oko nje:

• Da li se lozinke čuvaju bezbedno?
• Da li svaka privatna stranica i svaka API tačka zaista proverava ko pita?
• Može li prijavljeni kupac da vidi tuđe podatke ako promeni broj u URL-u?
• Šta se dešava kada neko zaboravi lozinku?

Aplikacija može izgledati potpuno bezbedno, a da ne ispunjava nijedan od tih uslova. Razumevanje pokretnih delova ti omogućava da postavljaš prava pitanja i testiraš prave stvari.

Svakodnevna analogija

Zamisli prijavu u hotel.

Na recepciji pokažeš lična dokumenta. To je autentifikacija: dokazivanje ko si. Recepcionar ti zatim daje karticu za sobu. Ta kartica je tvoja sesija: tokom boravka ne pokazuješ dokumenta ponovo, samo prisloniš karticu.

Kartica otvara tvoju sobu, teretanu i lift do tvog sprata, ali ne i sobe drugih gostiju ili kancelariju osoblja. To je autorizacija: šta tvoj identitet sme da pristupi. Ako izgubiš karticu, hotel je može deaktivirati na recepciji (opozivanje sesije). Kada odjaviš, prestaje da radi (odjava ili istek).

„Prijavi se preko Google-a“ je kao kada hotel prihvati pismo od pouzdanog partnera koje kaže „ovo je ta osoba“, umesto da sam proverava tvoja dokumenta.

Glavni načini prijave

Kako treba čuvati lozinke

Bezbedna aplikacija nikada ne čuva tvoju pravu lozinku. Umesto toga čuva heš: rezultat jednosmerne funkcije koja lozinku pretvara u fiksni niz znakova. Kada se prijaviš, aplikacija heširava ono što si uneo i poredi rezultat sa sačuvanim hešom.

Dva detalja to čine bezbednim:

• So (salt): nasumična vrednost dodata svakoj lozinki pre heširanja, tako da dve osobe sa istom lozinkom dobijaju različite heševe, a unapred izračunate tabele za pretragu postaju beskorisne.
• Spor algoritam namenjen lozinkama, kao što su Argon2, bcrypt ili scrypt. Opšti heševi poput MD5 ili SHA-256 su sami po sebi previše brzi; napadači mogu da probaju milijarde pogađanja.

Heširanje nije isto što i enkripcija. Šifrovani podaci mogu da se dešifruju ključem, dok je heš lozinke osmišljen tako da se uopšte ne može vratiti.

Sesije naspram tokena

Posle prijave aplikacija mora da te prepoznaje pri svakom zahtevu. Postoje dva česta pristupa.

Za kolačiće su važna tri podešavanja: HttpOnly (JavaScript na stranici ne može da pročita kolačić), Secure (šalje se samo preko HTTPS-a) i SameSite (ograničava slanje na zahteve sa drugih sajtova). Čuvanje tokena u localStorage pregledača je često, ali ih izlaže svakoj skripti koja se izvršava na stranici.

OAuth i „Prijavi se preko Google-a“

OAuth 2.0 je standard za delegovanu autorizaciju: aplikaciji daje ograničen pristup tvom nalogu na drugom servisu, na primer čitanje tvog Google kalendara, a da ona nikada ne vidi tvoju Google lozinku. Preusmeri te na Google, odobriš određene dozvole (zvane scope), a Google aplikaciji daje token samo za te dozvole.

Sam OAuth je osmišljen da odobrava pristup, a ne da kaže ko si. OpenID Connect (OIDC) je sloj iznad OAuth 2.0 koji dodaje identitet, i to koriste „Prijavi se preko Google-a“ ili „Prijavi se preko Apple-a“. Da bi ga podesio, registruješ aplikaciju kod provajdera i dobijaš client ID i client secret; tajna ostaje na tvom serveru.

Praktičan primer: prijava za portal klijenata

Zamisli da praviš portal u kojem klijenti jedne dizajn agencije vide svoje projekte i fakture.

• Autentifikacija: klijenti se prijavljuju imejlom i magičnim linkom, pa nema lozinki za upravljanje. Zaposleni u agenciji se prijavljuju nalozima Google Workspace.
• Uloge: svaki korisnik ima ulogu, client ili staff.
• Pravila autorizacije:

• Gde se sprovodi: na serveru, za svaki zahtev. Server pronađe prijavljenog korisnika, pa vraća samo projekte čiji se project.company_id poklapa sa kompanijom korisnika. Sakrivanje dugmeta „Označi plaćeno“ nije dovoljno; sama tačka mora da odbije zahtev.

Pojmovi objašnjeni

Česte greške i zablude

• Provera dozvola samo na stranici. Ako pregledač sakrije dugme, ali API ne proverava, svako može da pozove API direktno.
• Verovanje ID-jevima iz URL-a. /invoices/1042 mora da proveri da faktura 1042 pripada prijavljenom korisniku.
• Pravljenje sopstvene kriptografije. Koristi dobro poznate biblioteke ili provajdere; ne dozvoli AI-ju da izmisli šemu heširanja.
• Slabo resetovanje lozinke. Linkovi za resetovanje treba da se koriste samo jednom, brzo isteknu i ne otkrivaju da li imejl ima nalog.
• Mešanje tvoje prijave sa prijavom na alat u kojem praviš aplikaciju. Korisnici tvoje aplikacije su odvojeni od tvog naloga na alatu za pravljenje.
• Bez ograničenja pokušaja prijave. Bez toga napadači mogu beskonačno da pokušavaju lozinke.

Šta tražiti od svog AI alata

• „Dodaj registraciju i prijavu koristeći [dobro poznatu biblioteku ili provajdera]. Ne piši sopstveno heširanje lozinki.“
• „Čuvaj lozinke heširane pomoću bcrypt-a ili Argon2.“
• „Koristi HttpOnly i Secure kolačiće za sesiju.“
• „Dodaj uloge: admin i member. Navedi svaku API tačku i koje uloge je smeju pozivati.“
• „Na serveru proveri da korisnici mogu da čitaju i menjaju samo svoje zapise. Zatim mi pokaži kako si to proverio.“
• „Dodaj resetovanje lozinke sa linkovima koji važe samo jednom i ističu za sat vremena.“
• „Ograniči broj pokušaja prijave.“

Zatim sam testiraj: napravi dva naloga i pokušaj da pristupiš podacima jednog dok si prijavljen kao drugi. Naš vodič za dodavanje prijave i lista za bezbednost idu dalje.

Autentifikacija u Mythex-u

Mythex ne nudi ugrađen proizvod za autentifikaciju korisnika tvoje aplikacije. Ti biraš pristup: imejl i lozinku koji se čuvaju u bazi tvog projekta ili SDK hostovanog provajdera, i zamoliš agenta da ga doda. Ključevi provajdera idu u tajne projekta, a ne u chat. Ovo je odvojeno od načina na koji se prijavljuješ u sam Mythex. Dokumentacioni recept o dodavanju prijave u aplikaciju ima početni prompt koji možeš prilagoditi, a šta je API objašnjava gde te provere na serveru žive.

Pitanja