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

Autentifikacija je način na koji aplikacija potvrđuje ko je korisnik, obično provjerom nečega što on zna (lozinke), nečega što posjeduje (koda poslanog na telefon ili e-mail) ili identiteta iz druge pouzdane usluge (kao što je „Prijava preko Googlea“). Kada je korisnik autentifikovan, aplikacija ga pamti putem sesije ili tokena, pa se ne mora prijavljivati na svakoj stranici. Odlučivanje šta taj poznati korisnik smije raditi zaseban je korak koji se zove autorizacija.

Zašto je to važno kad gradite uz AI

Dodavanje prijave jedan je od najčešćih zahtjeva koje ljudi upućuju AI alatima za izradu, i jedan od najlakših za pogrešno uraditi. Stranicu za prijavu je lako generisati. Teški dio je sve oko nje:

• Jesu li lozinke sigurno pohranjene?
• Provjerava li svaka privatna stranica i svaki API endpoint ko pita?
• Može li prijavljeni kupac vidjeti podatke drugog kupca mijenjajući broj u URL-u?
• Šta se dešava kada neko zaboravi lozinku?

Aplikacija može izgledati potpuno sigurno, a pri tome pasti na svakoj od ovih provjera. Razumijevanje pokretnih dijelova pomaže vam da postavite prava pitanja i testirate prave stvari.

Svakodnevna analogija

Zamislite prijavu u hotel.

Na recepciji pokazujete ličnu kartu. To je autentifikacija: dokazivanje ko ste. Recepcionar vam zatim daje karticu za sobu. Ta kartica je vaša sesija: tokom boravka ne pokazujete ličnu kartu ponovo, samo prislonite karticu.

Kartica otvara vašu sobu, teretanu i lift do vašeg sprata, ali ne i sobe drugih gostiju ili kancelariju osoblja. To je autorizacija: kakav pristup vaš identitet smije imati. Ako izgubite karticu, hotel je može deaktivirati na recepciji (opoziv sesije). Kada odjavite, prestaje da radi (odjava ili istek).

„Prijava preko Googlea“ je kao kada hotel prihvati pismo od pouzdanog partnera koje kaže „ovo je ta osoba“, umjesto da sam provjerava vašu ličnu kartu.

Glavne metode prijave

Kako treba čuvati lozinke

Sigurna aplikacija nikada ne čuva vašu stvarnu lozinku. Umjesto toga čuva hash: rezultat jednosmjerne funkcije koja lozinku pretvara u fiksni niz. Kada se prijavite, aplikacija hashira ono što ste upisali i poredi rezultat sa sačuvanim hashom.

Dva detalja to čine sigurnim:

• So (salt): nasumična vrijednost dodana svakoj lozinki prije hashiranja, tako da dvije osobe s istom lozinkom imaju različite hashove, a unaprijed izračunate tabele postaju beskorisne.
• Spor algoritam namijenjen lozinkama: poput Argon2, bcrypt ili scrypt. Opšte hash funkcije poput MD5 ili SHA-256 su same po sebi previše brze; napadači mogu isprobati milijarde pokušaja.

Hashiranje nije isto što i enkripcija. Enkriptovani podaci se mogu dekriptovati ključem; hash lozinke je namijenjen da uopće nije reverzibilan.

Sesije vs tokeni

Nakon prijave, aplikacija vas mora prepoznati pri svakom zahtjevu. Postoje dva uobičajena pristupa.

Za kolačiće su važna tri podešavanja: HttpOnly (JavaScript na stranici ne može čitati kolačić), Secure (šalje se samo preko HTTPS-a) i SameSite (ograničava slanje na zahtjevima s drugih sajtova). Čuvanje tokena u localStorage-u browsera je često, ali ih izlaže svakom skriptu koji se izvršava na stranici.

OAuth i „Prijava preko Googlea“

OAuth 2.0 je standard za delegirano autorizovanje: omogućava aplikaciji ograničen pristup vašem nalogu na drugoj usluzi, na primjer čitanje vašeg Google kalendara, bez da ikada vidi vašu Google lozinku. Preusmjere vas na Google, odobravate određene dozvole (zvane scope), a Google aplikaciji daje token samo za te dozvole.

OAuth je sam po sebi osmišljen da dodjeljuje pristup, a ne da kaže ko ste. OpenID Connect (OIDC) je sloj iznad OAuth 2.0 koji dodaje identitet, a upravo to koriste „Prijava preko Googlea“ ili „Prijava preko Applea“. Za podešavanje registrujete aplikaciju kod provajdera i dobijate client ID i client secret; secret ostaje na vašem serveru.

Praktičan primjer: prijava za portal klijenata

Recimo da gradite portal na kojem klijenti jedne dizajnerske agencije vide svoje projekte i fakture.

• Autentifikacija: klijenti se prijavljuju e-mailom i magic linkom, pa nema lozinki za upravljanje. Zaposleni u agenciji se prijavljuju Google Workspace nalozima.
• Uloge: svaki korisnik ima ulogu, client ili staff.
• Pravila autorizacije:

• Gdje se provodi: na serveru, za svaki zahtjev. Server pronalazi prijavljenog korisnika i vraća samo projekte gdje se project.company_id poklapa s kompanijom korisnika. Sakrivanje dugmeta „Označi plaćeno“ nije dovoljno; sam endpoint mora odbiti zahtjev.

Pojmovi objašnjeni

Česte greške i zablude

• Provjera dozvola samo na stranici. Ako browser sakrije dugme, ali API ne provjerava, svako može direktno pozvati API.
• Vjerovanje ID-jevima iz URL-a. /invoices/1042 mora provjeriti da faktura 1042 pripada prijavljenom korisniku.
• Pravljenje sopstvene kriptografije. Koristite poznate biblioteke ili provajdere; ne dozvolite AI-u da izmisli šemu hashiranja.
• Slabo resetovanje lozinke. Linkovi za resetovanje treba da se koriste jednom, brzo istječu i ne smiju otkrivati da li e-mail ima nalog.
• Mješanje vaše prijave s prijavom u alatu za izradu. Korisnici vaše aplikacije odvojeni su od vašeg naloga na alatu u kojem gradite.
• Nema ograničenja pokušaja prijave. Bez toga napadači mogu beskonačno isprobavati lozinke.

Šta tražiti od vašeg AI alata za izradu

• „Dodaj registraciju i prijavu koristeći [poznatu biblioteku ili provajdera]. Ne piši vlastito hashiranje lozinki.“
• „Čuvaj lozinke hashirane s bcrypt ili Argon2.“
• „Koristi HttpOnly, Secure kolačiće za sesiju.“
• „Dodaj uloge: admin i member. Navedi svaki endpoint i koje uloge ga smiju pozivati.“
• „Na serveru osiguraj da korisnici mogu čitati i mijenjati samo svoje zapise. Zatim mi pokaži kako si to provjerio.“
• „Dodaj resetovanje lozinke s jednokratnim linkovima koji istječu za sat vremena.“
• „Ograniči broj pokušaja prijave.“

Zatim sami testirajte: napravite dva naloga i pokušajte pristupiti podacima jednog dok ste prijavljeni kao drugi. Vodič za dodavanje prijave i sigurnosna lista idu dalje.

Autentifikacija u Mythexu

Mythex ne nudi ugrađen auth proizvod za korisnike vaše aplikacije. Vi birate pristup, bilo e-mail i lozinku pohranjene u bazi podataka vašeg projekta, bilo SDK hostovanog provajdera, i agenta zamolite da ga doda. Ključevi provajdera idu u tajne vrijednosti projekta, a ne u chat. Ovo je odvojeno od toga kako se prijavljujete na sam Mythex. Recept u dokumentaciji o dodavanju prijave u aplikaciju ima početni prompt koji možete prilagoditi, a šta je API objašnjava gdje žive te provjere na serveru.

Pitanja