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

Autentifikacija je način na koji aplikacija potvrđuje tko je korisnik — obično provjerom nečega što zna (lozinke), nečega što posjeduje (koda poslanog na telefon ili e-poštu) ili identiteta iz drugog pouzdanog servisa (poput „Prijava putem Googlea”). Kad je korisnik autentificiran, aplikacija ga pamti pomoću sesije ili tokena pa se ne mora prijavljivati na svakoj stranici. Odlučivanje što taj poznati korisnik smije raditi zaseban je korak i zove se 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 onih koje je lako pogrešno napraviti. Stranicu za prijavu lako je generirati. Teško je sve oko nje:

• Jesu li lozinke sigurno pohranjene?
• Provjerava li svaka privatna stranica i svaki API endpoint tko je zapravo pita?
• Može li prijavljeni kupac vidjeti podatke drugog kupca mijenjajući broj u URL-u?
• Što se događa kad netko zaboravi lozinku?

Aplikacija može izgledati potpuno sigurno, a ipak zakazati na svim tim točkama. Razumijevanje pokretnih dijelova omogućuje vam da postavite prava pitanja i testirate prave stvari.

Svakodnevna analogija

Zamislite prijavu u hotel.

Na recepciji pokažete osobnu iskaznicu. To je autentifikacija: dokazivanje tko ste. Recepcionar vam zatim daje karticu za sobu. Ta kartica je vaša sesija: za cijeli boravak ne pokazujete osobnu iskaznicu ponovno; samo prislonite karticu.

Kartica otvara vašu sobu, teretanu i dizalo do vašeg kata — ali ne i sobe drugih gostiju ni ured osoblja. To je autorizacija: kakav pristup vaš identitet smije imati. Ako izgubite karticu, hotel je može deaktivirati na recepciji (opoziv sesije). Kad odjavite, prestaje raditi (odjava ili istek vremena).

„Prijava putem Googlea” je kao kad hotel prihvati pismo pouzdanog partnera koje kaže „ovo je ta osoba”, umjesto da sam provjerava vašu iskaznicu.

Glavne metode prijave

Kako lozinke trebaju biti pohranjene

Sigurna aplikacija nikad ne pohranjuje vašu stvarnu lozinku. Umjesto toga sprema hash: rezultat jednosmjerne funkcije koja lozinku pretvara u fiksni niz znakova. Kad se prijavite, aplikacija hashira ono što ste upisali i uspoređuje rezultat s pohranjenim hashom.

Dva detalja to čine sigurnim:

• Sol (salt) — slučajna vrijednost dodana svakoj lozinki prije hashiranja, pa dvije osobe s istom lozinkom dobivaju različite hashove, a unaprijed izračunate tablice pretraživanja postaju beskorisne.
• Spor algoritam namijenjen lozinkama — poput Argon2, bcrypt ili scrypt. Hashevi opće namjene, poput MD5 ili SHA-256, premalo su spori sami po sebi; napadači mogu isprobati milijarde pogađanja.

Hashiranje nije isto što i enkripcija. Šifrirani podaci mogu se dešifrirati ključem; hash lozinke je namjerno dizajniran da se uopće ne može vratiti.

Sesije naspram tokena

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

Za kolačiće su važne tri postavke: HttpOnly (JavaScript na stranici ne može čitati kolačić), Secure (šalje se samo preko HTTPS-a) i SameSite (ograničava slanje zahtjeva s drugih stranica). Spremanje tokena u localStorage preglednika je često, ali ih izlaže svakoj skripti koja se izvršava na stranici.

OAuth i „Prijava putem Googlea”

OAuth 2.0 je standard za delegiranu autorizaciju: omogućuje aplikaciji ograničen pristup vašem računu na drugoj usluzi — recimo čitanje vašeg Google kalendara — bez da ikad vidi vašu Google lozinku. Preusmjereni ste na Google, odobravate određena dopuštenja (zvana scopes), a Google aplikaciji daje token samo za ta dopuštenja.

OAuth sam po sebi osmišljen je za dodjelu pristupa, a ne za potvrdu tko ste. OpenID Connect (OIDC) je sloj iznad OAuth 2.0 koji dodaje identitet, a upravo ga koristi „Prijava putem Googlea” ili „Prijava putem Applea”. Za postavljanje registrirate aplikaciju kod pružatelja i dobivate client ID i client secret; tajna ostaje na vašem serveru.

Primjer: prijava za portal klijenata

Recimo da gradite portal na kojem klijenti dizajnerske agencije vide svoje projekte i račune.

• Autentifikacija: klijenti se prijavljuju e-adresom i magic linkom, pa nema lozinki za upravljanje. Zaposlenici agencije prijavljuju se s Google Workspace računima.
• Uloge: svaki korisnik ima ulogu — client ili staff.
• Pravila autorizacije:

• Gdje se provodi: na serveru, za svaki zahtjev. Server pronalazi prijavljenog korisnika, a zatim vraća samo projekte kojima se project.company_id podudara s tvrtkom korisnika. Skrivanje gumba „Označi plaćeno” nije dovoljno — endpoint sam mora odbiti zahtjev.

Objašnjenje čestih pojmova

Česte greške i zablude

• Provjera dopuštenja samo na stranici. Ako preglednik sakrije gumb, a API ne provjerava, svatko može pozvati API izravno.
• Vjerovanje ID-jevima iz URL-a. /invoices/1042 mora provjeriti pripada li račun 1042 prijavljenom korisniku.
• Vlastita kriptografija. Koristite poznate biblioteke ili pružatelje; ne dopustite AI-ju da izmisli shemu hashiranja.
• Slabo resetiranje lozinke. Linkovi za reset trebaju se moći koristiti samo jednom, brzo isteći i ne smiju otkriti postoji li račun s određenom e-adresom.
• Miješanje vaše prijave s prijavom alata za izradu. Korisnici vaše aplikacije odvojeni su od vašeg računa na alatu kojim gradite.
• Nema ograničenja broja pokušaja prijave. Bez toga napadači mogu beskonačno isprobavati lozinke.

Što zatražiti od AI alata za izradu

• „Dodaj registraciju i prijavu koristeći [poznatu biblioteku ili pružatelja]. Ne piši vlastito hashiranje lozinki.”
• „Pohranjuj lozinke hashirane s bcrypt ili Argon2.”
• „Za sesiju koristi HttpOnly i Secure kolačiće.”
• „Dodaj uloge: admin i member. Popiši svaki endpoint i koje uloge ga smiju pozivati.”
• „Na serveru osiguraj da korisnici mogu čitati i uređivati samo vlastite zapise. Zatim mi pokaži kako si to provjerio.”
• „Dodaj resetiranje lozinke s jednokratnim linkovima koji istječu nakon sat vremena.”
• „Ograniči broj pokušaja prijave.”

Zatim sami testirajte: napravite dva računa i pokušajte doći do podataka jednog dok ste prijavljeni kao drugi. Naš vodič za dodavanje prijave i sigurnosni popis za aplikacije izrađene uz AI idu dalje.

Autentifikacija u Mythexu

Mythex ne nudi ugrađeni proizvod za autentifikaciju korisnika vaše aplikacije; sami birate pristup — e-adresu i lozinku pohranjene u bazi podataka vašeg projekta ili SDK hostiranog pružatelja — i zamolite agenta da ga doda. Ključevi pružatelja idu u tajne projekta, ne u chat. Ovo je odvojeno od načina na koji se prijavljujete u sam Mythex. Recept u dokumentaciji o dodavanju prijave u aplikaciju ima početni prompt koji možete prilagoditi, a što je API objašnjava gdje se te provjere na serveru nalaze.

Pitanja