Autentifikacija i autorizacija: tehnički vodič za 2026.

Autentifikacija (AuthN) odgovara na pitanje „ko si ti?“, a autorizacija (AuthZ) odgovara na pitanje „šta smeš da radiš?“ Prema modernim arhitekturama, to su dva odvojena procesa: AuthN potvrđuje identitet, AuthZ donosi odluku o dozvolama. Najčešća greška u praksi je tretiranje autentifikovanog korisnika kao automatski autorizovanog za sve operacije, što direktno vodi do „broken access control“ ranjivosti.

Tri stvari koje treba uraditi odmah:

• Odvojiti dobavljača identiteta (IdP) od servisa koji procenjuje prava pristupa.

• Ukloniti SMS kao primarnu MFA metodu i zameniti je WebAuthn/passkeys metodom.

• Primeniti Authorization Code + PKCE tok za sve OAuth 2.0 integracije.

Profesionalni savet: Ako vaša aplikacija koristi isti servis za prijavu i za proveru dozvola, to je arhitektonski dug koji raste sa svakim novim resursom. Razdvajanje tih odgovornosti od početka štedi mesece refaktorisanja.

Sadržaj

• Koja je razlika između autentifikacije i autorizacije?

• Koje metode autentifikacije treba koristiti u 2026.?

• Koji model autorizacije odabrati za vaš sistem?

• Kako funkcionišu OAuth 2.0, OpenID Connect i SAML?

• Kako sigurno upravljati JWT tokenima?

• Koje su najčešće sigurnosne greške pri implementaciji?

• Implementacioni vodič korak po korak za 2026.

• Ključne spoznaje

• Zašto je arhitektonska odvojenost AuthN i AuthZ važnija nego što izgleda

• Neonvoidcode gradi sigurne AuthN/AuthZ sisteme po meri

• Korisni linkovi i referentna dokumentacija

Koja je razlika između autentifikacije i autorizacije?

Autentifikacija i autorizacija su odvojeni procesi koji se odvijaju u različitim trenucima i na različitim mestima u sistemu. Mešanje ta dva koncepta je jedan od najčešćih uzroka sigurnosnih propusta.

AuthN se dešava jednom, na ulaznoj tački sistema. Korisnik predaje dokaz identiteta (lozinka, biometrija, hardverski ključ), sistem ga verifikuje i izdaje token ili sesiju. Od tog trenutka sistem zna ko je korisnik.

AuthZ se dešava pri svakom zahtevu prema resursu. Sistem proverava da li autentifikovani korisnik ima pravo da izvrši konkretnu operaciju nad konkretnim resursom. Nije dovoljno proveriti jednom pri prijavi.

Minimalni tok izgleda ovako:

1. Korisnik šalje kredencijale IdP-u.

2. IdP verifikuje identitet i izdaje access token (JWT ili referentni token).

3. Korisnik šalje zahtev resursu uz token.

4. API Gateway ili edge servis verifikuje potpis tokena.

5. Ciljni servis proverava da li korisnik ima pravo na tu konkretnu operaciju.

HTTP statusi: 401 vs 403

Razlika između ova dva koda nije kozmetička. 401 Unauthorized znači da sistem ne zna ko šalje zahtev, tj. autentifikacija nije uspela ili token nedostaje. 403 Forbidden znači da sistem zna ko šalje zahtev, ali taj korisnik nema pravo na tu operaciju.

Ova distinkcija je ključna za dijagnostiku. Ako logovi pokazuju mnogo 403 grešaka od autentifikovanih korisnika, problem je u konfiguraciji dozvola. Ako se pojavljuje 401, problem je u tokenu ili sesiji. Nikad ne vraćati 403 kada token nije prisutan, jer to otkriva informaciju o tome da resurs postoji.

Profesionalni savet: Uvek logovati deny odluke sa kontekstom: korisnik, resurs, operacija, razlog odbijanja. Bez tog konteksta, incident response postaje nagađanje.

Koje metode autentifikacije treba koristiti u 2026.?

Izbor metode autentifikacije direktno određuje koliko je sistem otporan na phishing, krađu sesije i napade grubom silom. Nije svaka metoda jednako sigurna.

Pregled metoda i preporuke

• Lozinke: I dalje dominantne, ali NIST smernice (NIST 800-63B-4) su promenile pravila. Nema obavezne periodične rotacije, nema zahteva za složenošću sa specijalnim znakovima. Umesto toga, proveravati lozinke prema listama kompromitovanih vrednosti i dozvoliti dugačke fraze. Čuvati isključivo kao bcrypt, Argon2id ili scrypt heš.

• TOTP (vremenski jednokratni kodovi): Aplikacije poput Google Authenticator ili Authy. Bolje od SMS-a, ali podložne phishing napadima u realnom vremenu.

• SMS jednokratni kodovi: Koristiti samo kao poslednji rezervni kanal, nikad kao primarnu MFA metodu. SIM swap napadi i SS7 ranjivosti čine SMS nepouzdanim za sisteme visoke osetljivosti.

• WebAuthn / Passkeys: Phishing-otporna metoda zasnovana na kriptografiji javnog ključa. Korisnik se autentifikuje biometrijskim senzorima uređaja ili hardverskim ključem (YubiKey, Google Titan). Preporučena metoda za 2026, posebno za administrativne naloge.

• Hardverski ključevi (FIDO2): Najjača dostupna zaštita za privilegovane naloge.

• Magic link: Jednokratni link poslan na email. Prihvatljiv za niske rizike, ali zavisi od sigurnosti email naloga.

• Društvene mreže / SSO putem OIDC: Google, Microsoft, GitHub. Delegira autentifikaciju pouzdanom IdP-u uz OpenID Connect protokol.

Sesija ili token: kada šta koristiti

Server-strana sesija sa HttpOnly kolačićem je pravi izbor za tradicionalne web aplikacije gde server kontroliše ceo životni ciklus. JWT access token je bolji za API-je i mikroservise jer je bez stanja i skalabilan. Hibridni pristup kombinuje kratkotrajan access token (5–15 minuta) sa dugoročnim refresh tokenom koji se čuva u HttpOnly Secure kolačiću, nikad u localStorage.

Pseudokod za sigurnu prijavu:

POST /auth/login
  → verifikuj kredencijale
  → izvrši MFA proveru
  → izdaj access_token (exp: 15min, potpisan RS256)
  → postavi refresh_token u HttpOnly Secure SameSite=Strict kolačić
  → vrati access_token u telu odgovora

Profesionalni savet: Za jednostranične aplikacije (SPA) koristiti BFF (Backend-For-Frontend) obrazac: SPA komunicira sa BFF-om koji drži tokene na serveru. SPA nikad ne vidi refresh token.

Koji model autorizacije odabrati za vaš sistem?

Izbor modela autorizacije zavisi od toga koliko su pravila pristupa složena i koliko brzo se menjaju. Pogrešan izbor na početku projekta skupo košta.

RBAC, ABAC, ACL i ReBAC

RBAC (kontrola pristupa zasnovana na ulogama) dodeljuje dozvole ulogama, a uloge korisnicima. Jednostavan za implementaciju i razumevanje. Pravi izbor za sisteme sa stabilnim, predvidivim pravilima pristupa. Problem nastaje kada sistem raste: tim koji počne sa 12 uloga lako završi sa 287 uloga u 18 meseci, što čini upravljanje nepreglednim.

ABAC (kontrola pristupa zasnovana na atributima) evaluira politike na osnovu atributa korisnika, resursa i okruženja. Fleksibilniji od RBAC-a, ali teži za debugovanje i reviziju.

ACL (lista kontrole pristupa) definiše dozvole direktno na nivou resursa. Dobra za jednostavne sisteme sa malim brojem resursa, loša za skaliranje.

ReBAC (kontrola pristupa zasnovana na vezama) modeluje dozvole kroz grafove veza između entiteta. Pravi izbor za proizvode sa intenzivnim deljenjem podataka, kao što su sistemi za saradnju ili platforme sa složenim hijerarhijama. SpiceDB i OpenFGA su open-source implementacije Zanzibar principa koje omogućavaju primenu ovog modela izvan Google-a.

Gde izvršavati autorizaciju?

Autorizacija na edge nivou (API Gateway) brzo odbacuje neovlašćene zahteve pre nego što stignu do servisa. Ali to nije dovoljno. Svaki servis mora sam proveriti dozvole na nivou resursa, jer gateway ne zna kontekst konkretnog resursa. Ovo je princip „odbrane u dubinu“.

Googleov Zanzibar model pokazuje šta je moguće pri velikom obimu: velik broj zahteva u sekundi sa p95 latencijom ispod 10 ms. Za većinu projekata u Centralnoj Evropi to nije cilj, ali arhitektonski princip centralizovanog AuthZ servisa sa lokalnim keširanjem ostaje relevantan.

Profesionalni savet: Nikad ne tretirati autentifikovanog korisnika kao automatski autorizovanog. To je vodeća greška prema OWASP-u i direktan put do „broken access control“ ranjivosti.

Kako funkcionišu OAuth 2.0, OpenID Connect i SAML?

Ovo je oblast gde se najčešće prave arhitektonske greške, uglavnom zbog mešanja uloga protokola.

OAuth 2.0 je okvir za delegiranu autorizaciju. Omogućava aplikaciji da dobije ograničen pristup resursima u ime korisnika, bez da korisnik predaje lozinku toj aplikaciji. OAuth 2.0 sam po sebi ne govori ništa o identitetu korisnika.

OpenID Connect (OIDC) je identitetski sloj izgrađen na vrhu OAuth 2.0. Dodaje ID token koji nosi informacije o korisniku. Za prijavu korisnika uvek koristiti OIDC, nikad čist OAuth 2.0.

SAML 2.0 je XML-baziran protokol za enterprise SSO. Dominira u korporativnim okruženjima sa postojećom Active Directory infrastrukturom. Za nove projekte, OIDC je lakši za implementaciju i bolje se uklapa u moderne API arhitekture.

Preporučeni tokovi

• Web i mobilne aplikacije: Authorization Code + PKCE. PKCE (Proof Key for Code Exchange) sprečava napad presretanjem authorization koda, što je posebno važno za mobilne klijente koji ne mogu sigurno čuvati tajne.

• Server-to-server komunikacija: Client Credentials tok, bez korisničkog konteksta.

• Enterprise SSO sa nasleđenim sistemima: SAML 2.0, uz plan migracije ka OIDC.

Tok Authorization Code + PKCE u kratkim crtama: klijent generiše code_verifier i code_challenge, šalje code_challenge uz zahtev za autorizacijom, dobija authorization code, pa ga zamenjuje za token uz originalni code_verifier. Server verifikuje da se vrednosti poklapaju.

Profesionalni savet: Nikad ne koristiti Implicit tok. Depreciran je upravo zbog toga što access token putuje kroz URL fragment, gde ga browser history i referrer zaglavlja mogu otkriti.

Kako sigurno upravljati JWT tokenima?

JWT (JSON Web Token) je popularan, ali ga mnogi timovi koriste pogrešno. Struktura je jednostavna: zaglavlje, telo sa klaimovima i potpis. Problem nije u formatu, nego u tome šta se u token stavlja i gde se čuva.

Dizajn klaimova

Minimalni skup klaimova uključuje sub (identifikator korisnika), iss (izdavalac), aud (primalac), i exp (vreme isteka). Ne stavljati osetljive podatke u JWT jer je telo base64-kodirano, ne enkriptovano. Ne stavljati ni previše uloga ili dozvola, jer to otežava revokaciju i povećava veličinu tokena.

Skladištenje i rotacija

• Access token: kratkotrajan, 5–15 minuta, može biti u memoriji JavaScript aplikacije.

• Refresh token: dugotrajan, čuvati isključivo u HttpOnly Secure SameSite=Strict kolačiću.

• Rotacija refresh tokena: svaki put kada se koristi refresh token, izdati novi i poništiti stari.

• Revokacija: voditi listu poništenih tokena ili koristiti referentne tokene koji se proveravaju u bazi pri svakom zahtevu.

Pseudokod za validaciju JWT:

function validateToken(token):
  header = decode(token.header)
  if header.alg not in ALLOWED_ALGORITHMS:
    throw InvalidAlgorithm  // nikad ne dozvoliti 'none'
  
  jwks = fetchJWKS(issuer.jwks_uri)
  verifySignature(token, jwks)
  
  claims = decode(token.payload)
  assert claims.iss == EXPECTED_ISSUER
  assert claims.aud == THIS_SERVICE_AUDIENCE
  assert claims.exp > now()
  
  return claims

Profesionalni savet: Uvek eksplicitno proveravati iss i aud klaimove. Napadač koji kontroliše jedan servis može pokušati da iskoristi token namenjen drugom servisu ako ove provere nedostaju.

Koje su najčešće sigurnosne greške pri implementaciji?

Greške u autentifikaciji i autorizaciji retko su slučajne. Uglavnom su posledica pritiska da se brzo isporuči, ili nerazumevanja razlike između protokola.

Anti-patterni koje treba odmah ispraviti

• „Validan JWT znači autorizovan“: Potpis tokena potvrđuje autentičnost, ne dozvole. Uvek proveriti dozvole za konkretan resurs i operaciju.

• Refresh token u localStorage: Svaki XSS napad ga krade. Premestiti u HttpOnly kolačić.

• SMS kao primarna MFA: Zameniti TOTP aplikacijom ili WebAuthn-om.

• Neproveravanje aud i iss: Otvara put za napade konfuzijom tokena između servisa.

• Wildcard CORS sa sesijskim kolačićima: Access-Control-Allow-Origin: * uz kolačiće je kontradikcija. Definisati eksplicitnu listu dozvoljenih izvora.

• Autorizacija samo pri prijavi: Dozvole se menjaju. Proveravati ih pri svakom zahtevu.

Prema OWASP-u, broken access control je vodeći problem u modernim aplikacijama, a neproveravanje aud/iss i greške u CORS konfiguraciji direktno doprinose kritičnim ranjivostima.

Kako detektovati problem u logovima

Pratiti:

1. Povećan broj 401 odgovora može ukazivati na istek tokena ili napad.

2. Povećan broj 403 odgovora od poznatih korisnika ukazuje na grešku u konfiguraciji dozvola ili promenu uloga.

3. Neuspeli pokušaji osvežavanja tokena u kratkim intervalima mogu biti znak krađe refresh tokena.

4. Pristup resursima van radnog vremena ili iz neočekivanih IP adresa zahteva alerting.

Profesionalni savet: Za incident response vezan za kompromitovane tokene: odmah rotirati JWKS ključeve, poništiti sve aktivne refresh tokene za pogođene naloge i prisiliti ponovnu prijavu. Imati ovaj playbook napisan pre nego što zatreba.

Implementacioni vodič korak po korak za 2026.

Ovo je operativni redosled za tim koji gradi novi sistem ili refaktoriše postojeći.

Checklist za implementaciju

1. Odabir IdP-a: Koristiti OIDC-kompatibilan IdP (Keycloak za on-premise, ili upravljani servis). Nikad ne graditi sopstveni sistem za upravljanje lozinkama od nule.

2. Konfiguracija Authorization Code + PKCE: Primeniti na sve web i mobilne klijente. Onemogućiti Implicit tok.

3. Strategija tokena: Kratkotrajan access token (5–15 min) + refresh token sa rotacijom. BFF obrazac za SPA aplikacije.

4. MFA konfiguracija: WebAuthn/passkeys za administrativne naloge. TOTP kao rezerva. SMS samo kao poslednji kanal.

5. CSRF zaštita: SameSite=Strict na sesijskim kolačićima. CSRF token za forme koje menjaju stanje.

6. CORS konfiguracija: Eksplicitna lista dozvoljenih izvora, nikad wildcard uz kolačiće.

7. Logovanje i revizija: Logovati sve autentifikacione događaje, deny odluke i promene dozvola sa vremenskom oznakom i kontekstom.

8. Testiranje: OWASP ZAP za automatizovano skeniranje, plus ručni penetracioni test pre puštanja u produkciju.

Referentna arhitektura Neonvoidcode

Za projekte u Centralnoj Evropi, Neonvoidcode primenjuje sledeći obrazac:

• API Gateway / BFF na edge nivou: verifikuje potpis JWT, odbacuje nevalidne zahteve pre nego što stignu do servisa.

• Centralizovani AuthZ servis (SpiceDB ili OpenFGA za složene sisteme): evaluira politike pristupa, odgovara na pitanje „da li korisnik X sme da uradi Y na resursu Z?“.

• Mikroservisi sa resource-level proverama: ne oslanjaju se slepo na gateway, već sami proveravaju dozvole za konkretne operacije.

• Skladištenje refresh tokena: Enkriptovana baza sa TTL-om i revokacionom listom.

• Rotacija JWKS ključeva: Automatizovana, sa preklapajućim periodom validnosti da se izbegnu prekidi.

• Monitoring i alerting: Metrike za anomalije pristupa, automatski alarm pri naglom porastu 401/403 odgovora.

Za fazno uvođenje bez prekida usluge: početi sa edge validacijom, zatim dodati centralizovani AuthZ servis, pa postepeno prebacivati servise na resource-level provere. Nikad ne migrirati sve odjednom.

Profesionalni savet: Da biste izbegli „role explosion“ u RBAC-u, uvedite pravilo: nova uloga zahteva odobrenje arhitekte i dokumentovanu poslovnu potrebu. Ako se uloge množe brže nego resursi, vreme je za prelaz na ReBAC model.

Ključne spoznaje:

Autentifikacija i autorizacija moraju biti arhitektonski odvojeni procesi: AuthN potvrđuje identitet jednom, AuthZ proverava dozvole pri svakom zahtevu prema resursu.

Zašto je arhitektonska odvojenost AuthN i AuthZ važnija nego što izgleda

Većina razvojnih timova razume razliku između autentifikacije i autorizacije na papiru. Problem nastaje u implementaciji, kada vremenski pritisak navede tim da „privremeno“ spoji te dve odgovornosti u jedan servis. Ta privremena rešenja traju godinama.

Ono što me zaista brine u projektima koje vidim u Centralnoj Evropi nije neznanje o protokolima. JWT, OAuth 2.0, OIDC su dobro dokumentovani. Problem je u tome što timovi implementiraju autorizaciju kao proveru uloge pri prijavi, zatim pretpostavljaju da je to dovoljno. Nije. Dozvole se menjaju, uloge se dodeljuju i oduzimaju, a sistem koji proverava dozvole samo jednom pri prijavi to ne vidi.

Drugi problem koji se ponavlja je GDPR usklađenost. Uredba EU o zaštiti podataka zahteva da organizacije mogu dokazati ko je imao pristup kojim podacima i kada. Sistem bez granularnog logovanja autorizacijskih odluka ne može zadovoljiti taj zahtev. Revizorski trag nije opcija, to je zakonska obaveza za sisteme koji obrađuju lične podatke u Centralnoj Evropi.

Passkeys i WebAuthn su konačno dostigli tačku zrelosti gde ih je moguće uvesti bez frustriranja korisnika. Svaki sistem koji i dalje koristi SMS kao primarnu MFA metodu nosi rizik koji nije opravdan dostupnošću boljih alternativa.

Neonvoidcode gradi sigurne AuthN/AuthZ sisteme po meri

Kada arhitektura autentifikacije i autorizacije mora biti ispravna od prvog dana, generička rešenja retko su dovoljna. Neonvoidcode projektuje i implementira odvojene AuthN/AuthZ sisteme prilagođene konkretnim zahtevima projekta: od konfiguracije OIDC/PKCE tokova i WebAuthn integracije, do centralizovanih servisa za procenu prava pristupa zasnovanih na SpiceDB ili OpenFGA principima.

Usluge obuhvataju sigurnosni pregled postojećeg stanja, dizajn referentne arhitekture, implementaciju i dugoročno tehničko održavanje. Svaki projekat uključuje GDPR-usklađeno logovanje i revizorski trag koji zadovoljava regulatorne zahteve Centralne Evrope.

Za procenu vašeg sistema ili razgovor o arhitekturi, kontaktirajte Neonvoidcode i dogovorite tehnički razgovor bez obaveze.

Korisni linkovi i referentna dokumentacija

Za dalje proučavanje i tehničku implementaciju, ovo su najrelevantniji izvori:

7. Koja je razlika između autentifikacije i autorizacije? (EITCA akademija) — konceptualno objašnjenje za web aplikacije

• RFC 6749 (OAuth 2.0 Authorization Framework) i RFC 7636 (PKCE) su primarni standardi dostupni na tools.ietf.org.

• WebAuthn specifikacija dostupna na w3.org/TR/webauthn.

Preporučeno

• NeonVoid Code | Custom aplikacije i e-store rešenja | Zapadna Srbija