Autentifikacija je odgovor na pitanje: ko si ti? (dok je autorizacija odgovor na pitanje: šta smeš da radiš?). U modernim sistemima često vidiš pojmove Basic, Bearer, OAuth2, JWT i SSO pomešane u istoj rečenici, pa deluje kao da je sve isto. Nije — neki su format zaglavlja, neki protokol, neki tip tokena, a neki ceo “login ekosistem”.
U nastavku objašnjavam svaki pojam: šta je, gde se koristi, razlike, prednosti/mane i praktična pravila izbora.
1) Basic auth – najjednostavniji “ključ u bravi”
Šta je:
Basic authentication je najjednostavniji način da klijent pošalje kredencijale (korisničko ime i lozinku) preko HTTP-a.
Kako izgleda u praksi:
U HTTP zahtevu šalje se header:
-
Authorization: Basic base64(username:password)
Bitno: Base64 nije enkripcija, samo kodiranje. Zato Basic praktično mora da ide preko HTTPS-a.
Kada se koristi:
-
Interni servisi (zatvoren sistem), admin alati
-
Brzi prototipi
-
Integracije gde je “username/password” jedina opcija
-
Machine-to-machine u kontrolisanom okruženju (npr. interni API iza VPN-a)
Prednosti:
-
Ultra jednostavno
-
Svaki klijent i server podržava
Mane:
-
Šalje se lozinka u svakom zahtevu (loše za bezbednost i revokaciju)
-
Nema finu kontrolu sesije/tokena
-
Rotacija lozinke je “teška”
Pravilo: Basic koristi samo kad je okruženje strogo kontrolisano i HTTPS je obavezan, ili kad je to tehnički minimum koji moraš da podržiš.
2) Bearer auth – “token kao karta za ulaz”
Šta je:
Bearer nije protokol. To je standardni način slanja tokena: ko god poseduje token (bearer = nosilac), smatra se autentifikovanim.
Kako izgleda:
-
Authorization: Bearer <token>
Kada se koristi:
-
Moderni REST/GraphQL API-ji
-
Mobilne aplikacije
-
SPA web aplikacije
-
Microservices komunikacija
Prednosti:
-
Ne šalješ lozinku stalno, već token
-
Token može imati rok trajanja, scope/privilegije
-
Lakše “ukineš” pristup (revokacija) nego kad je lozinka u pitanju
Mane:
-
Ako token procure, napadač ga može koristiti dok ne istekne
-
Moraš pažljivo skladištiti token na klijentu (posebno u browseru)
-
Potrebna je priča oko osvežavanja (refresh)
Pravilo: Bearer koristi kad god radiš sa tokenima — a to je danas default za API.
3) OAuth2 – standard za dobijanje tokena i delegiranje pristupa
Šta je:
OAuth2 je okvir (framework) koji rešava problem:
“Kako aplikacija A može da dobije pristup resursima korisnika na servisu B, bez da korisnik daje lozinku aplikaciji A?”
Primer: aplikacija traži pristup Google kalendaru, GitHub repozitorijumu, Microsoft nalogu…
Zašto ljudi mešaju OAuth2 i autentifikaciju?
OAuth2 je primarno o autorizaciji (dozvolama), ali se u praksi često koristi i za “login” kada se doda sloj OpenID Connect (OIDC). Zato “Login with Google” najčešće znači: OAuth2 + OIDC.
Ključni pojmovi:
-
Client (tvoja aplikacija)
-
Resource Owner (korisnik)
-
Authorization Server (npr. Google)
-
Resource Server (API koji čuva resurse)
-
Access token (kratko traje, služi za API)
-
Refresh token (duže traje, služi za dobijanje novog access tokena)
Najčešći tokovi (flow):
-
Authorization Code Flow (najčešći i preporučen za web; uz PKCE za SPA/mobile)
-
Client Credentials (server-to-server, bez korisnika)
Kada se koristi:
-
Login preko Google/Microsoft/GitHub
-
Više aplikacija koje dele identitet
-
Kada želiš scope i kontrolu pristupa (read/write nivo)
Prednosti:
-
Korisnik ne deli lozinku trećoj aplikaciji
-
Standardizovan, robustan
-
Granularne dozvole (scopes)
Mane:
-
Kompleksniji za implementaciju i debug
-
Moraš razumeti redirect URI, PKCE, tokove i pravila provajdera
Pravilo: OAuth2 koristi kada imaš integraciju sa spoljnim identitetom ili ti treba standardizovan način izdavanja tokena i dozvola. Za “login” se najčešće dodaje OIDC.
4) JWT – format tokena, a ne metoda logovanja
Šta je:
JWT (JSON Web Token) je format tokena. Obično je to string podeljen na tri dela (header.payload.signature). U payload-u stoje informacije o korisniku i pravilima tokena (npr. kad ističe), a potpis garantuje da sadržaj nije menján.
Ključna ideja: JWT može da bude “samodovoljan” (self-contained). Server može da proveri potpis i veruje sadržaju bez pozivanja baze/sesije, što je korisno u distribuiranim sistemima.
Šta obično sadrži:
-
sub(ID korisnika) -
exp(datum isteka) -
iat(kada je izdat) -
iss(ko ga je izdao) -
Custom claim-ovi (role, scope…)
Kada se koristi:
-
SPA/mobile + API
-
Microservices (stateless verifikacija)
-
Sistemi gde želiš brzinu i skaliranje bez centralne sesije
Prednosti:
-
Skalabilno i brzo (nema obavezne centralne sesije)
-
Dobro za mikroservise i više API-jeva
-
Standardan format, biblioteke postoje svuda
Mane i česte greške:
-
JWT payload nije enkriptovan (čita se), samo potpisan → ne stavljaj tajne podatke unutra
-
Revokacija je teža: ukradeni JWT važi dok ne istekne
-
Token može postati prevelik ako ubacuješ previše claim-ova
Pravilo: JWT je odličan kao access token (Bearer), ali ga drži kratkim i kratkog trajanja. Za ozbiljne sisteme planiraj refresh mehanizam i politiku revokacije.
5) SSO – “jednom se uloguj, svuda radi”
Šta je:
SSO (Single Sign-On) je iskustvo i arhitektura: korisnik se prijavi jednom, a zatim pristupa više aplikacija bez ponovnog logovanja.
SSO obično stoji na standardima:
-
SAML 2.0 (češći u enterprise svetu, stariji ali prisutan)
-
OpenID Connect (OIDC) (moderniji, zasnovan na OAuth2, čest za web/mobile)
-
Nekad Kerberos/LDAP u internim domenima
Kako izgleda u praksi:
-
Firma ima centralni Identity Provider (IdP) tipa Entra ID (Azure AD), Okta, Keycloak…
-
Tvoje aplikacije veruju tom IdP-u
-
Korisnik se autentifikuje na IdP-u, aplikacije dobiju token/assertion
Kada se koristi:
-
Organizacije sa više aplikacija (CRM, ERP, helpdesk, intranet…)
-
Centralna kontrola naloga, MFA, politike lozinki
-
Brzo uključivanje/isključivanje korisnika (onboarding/offboarding)
Prednosti:
-
Bolji UX: jedna prijava
-
Centralizovana bezbednost (MFA, device policy, politike)
-
Manje lozinki, manje resetovanja
Mane:
-
Ako IdP ima problem, više aplikacija trpi (treba HA i dobar dizajn)
-
Integracije umeju da budu kompleksne (SAML posebno)
-
Potrebno jasno upravljanje sesijama i “logout” ponašanjem
Pravilo: SSO je najbolji izbor kad imaš više aplikacija ili enterprise klijente, jer dobijaš centralnu kontrolu i standardizovan login.
Najvažnije razlike (da ostane jasno)
-
Basic = šalješ username/password (jednostavno, ali nije idealno za javne moderne API-je)
-
Bearer = način slanja tokena u
Authorizationheader-u -
OAuth2 = okvir kako se token dobija i kako se upravlja dozvolama (često uz OIDC za login)
-
JWT = format tokena (često se šalje kao Bearer)
-
SSO = “jedna prijava za više aplikacija”, najčešće preko OIDC ili SAML
Kako izabrati u realnom projektu
Interni admin panel / mali sistem / brz start
-
Basic (strogo HTTPS) ili bolje Bearer sa jednostavnim tokenima
SPA ili mobilna aplikacija + API
-
Bearer + JWT access token (kratko traje) + refresh token
Login preko Google/Microsoft + standardni identitet
-
OAuth2 + OIDC (praktično dobijaš osnovu za SSO)
Enterprise klijenti i više aplikacija u firmi
-
SSO preko OIDC ili SAML uz centralni IdP (Okta/Entra/Keycloak)
Server-to-server bez korisnika
-
OAuth2 Client Credentials ili potpisani tokeni, zavisno od infrastrukture
Praktične napomene koje prave razliku
-
HTTPS je obavezan u svim varijantama koje nose kredencijale ili tokene
-
Access token neka traje kratko (npr. 5–15 minuta), a refresh token duže (po politici)
-
JWT nije autorizacija sam po sebi: i dalje proveravaš role/scope i pravila pristupa
-
U browser okruženju posebno pazi gde čuvaš token (XSS rizik); često se bira HttpOnly cookie + CSRF zaštita ili pažljiv token storage
