Razvoj sistema za autentifikaciju: OAuth, JWT i SSO

Razvoj Sistema je tema ovog članka, od ograničenja koje koči do predaje posla.

Sadržaj

Sistem za autentifikaciju odlučuje ko ulazi u vašu aplikaciju, šta smije da radi kad uđe i koliko brzo možete nekome ukinuti pristup kad nešto krene po zlu. Prijava spolja izgleda kao riješen problem – forma, lozinka, dugme „Sign in with Google” – ali iza nje stoje trajanje tokena, rotacija ključeva, oznake na cookieju, provjera redirect adresa i opoziv sesije. Svaki od tih detalja ili je urađen kako treba, ili postaje prvo slabo mjesto koje napadač traži.

U CodeWizu dizajniramo i gradimo autentifikaciju i autorizaciju za web aplikacije, API-je, mobilne aplikacije i interne alate: OAuth 2.0 i OpenID Connect tokove, pristup API-ju preko JWT-a, single sign-on za timove i enterprise klijente, te serverske sesije koje izdrže stvarnu upotrebu. Radimo sa upravljanim identity platformama, self-hosted open-source identity providerima i auth mehanizmima ugrađenim u framework, i biramo ono što odgovara vašem proizvodu, budžetu i zahtjevima usklađenosti.

Kod teme razvoj sistema alati otvorenog koda su prvi izbor kada odgovaraju poslu.

Usluga je namijenjena SaaS proizvodima kojima SSO treba da potpišu veće klijente, firmama u kojima svaka interna aplikacija ima zasebnu lozinku, timovima na mobilnim aplikacijama i SPA-ovima koji nisu sigurni gdje token treba da živi, i svima koji su naslijedili domaći sistem prijave koji niko ne želi da dira.

Razvoj Sistema kreće od sistema koji već radi, a ne od praznog šablona.

Razvoj Sistema: Ruke kucaju na tastaturi laptopa tokom prijave u aplikaciju

Implementacija OAuth 2.0 i OpenID Connecta

OAuth 2.0 je okvir za delegiranu autorizaciju: aplikaciji daje access token kojim zove API u ime korisnika, a da lozinku nikada ne vidi. OpenID Connect (OIDC) na to dodaje sloj identiteta – ID token koji vašoj aplikaciji kaže ko je korisnik. Zajedno pokreću prijavu preko društvenih mreža, „Sign in with Microsoft” za poslovne aplikacije, prijavu u mobilnim aplikacijama i siguran pristup tuđim API-jima.

Rad na temi razvoj sistema ostaje u vašem repozitoriju i na vašoj infrastrukturi.

Izbor pravog OAuth toka

Većina sigurnosnih problema sa OAuthom nastaje jer je za tip klijenta odabran pogrešan tok. Trenutne preporuke, sabrane u OAuth 2.0 Security Best Current Practice (RFC 9700) i u nadolazećem OAuth 2.1, izbor znatno sužavaju:

CodeWiz provjerava razvoj sistema u produkciji, ne samo na demonstraciji.

Tok	Koristite ga za	Napomene
Authorization Code + PKCE	Server-rendered web aplikacije, SPA, mobilne i desktop aplikacije	Podrazumijevani izbor kad god postoji korisnik. PKCE je obavezan u OAuth 2.1, čak i za povjerljive klijente.
Client Credentials	Pozive između servisa, pozadinske poslove, integracije	Nema korisnika. Tokeni su kratkog vijeka i uskog scopea, a umjesto dijeljene tajne bolji je private-key JWT.
Device Authorization	Smart TV, CLI i IoT uređaje bez browsera	Korisnik potvrđuje na drugom uređaju unosom kratkog koda.
Implicit i Password (ROPC)	Ništa novo	Zastarjeli. Tokeni cure kroz URL i ostaju u pregledniku, a ROPC uči korisnike da lozinku kucaju u tuđe aplikacije.

Kako izgleda ispravan authorization zahtjev

Kod javnog klijenta, poput SPA ili mobilne aplikacije, aplikacija generiše nasumični code_verifier, šalje njegov SHA-256 hash kao code_challenge, a kasnije dokazuje da posjeduje verifier kad kod mijenja za tokene. Presretnuti authorization code bez toga ne vrijedi ništa:

Odluke o temi razvoj sistema vežu se za ograničenje koje stvarno koči poslovanje.

GET /authorize?response_type=code
  &client_id=web-app
  &redirect_uri=https://app.example.com/callback
  &scope=openid%20profile%20email
  &state=7f3c1a9e2b
  &nonce=d41d8cd98f
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

Na serveru provjeravamo da se redirect URI poklapa u potpunosti, state upoređujemo zbog CSRF-a, nonce provjeravamo u ID tokenu i scopeove sužavamo po klijentu. Za prijavu preko društvenih mreža povezujemo Google, Microsoft, Apple i GitHub, a naloge spajamo samo preko potvrđenog emaila – slijepo povezivanje naloga je klasičan put do preuzimanja tuđeg računa.

Predaja teme razvoj sistema uključuje uputstvo koje tim može koristiti.

Kada vam treba vlastiti authorization server

Ako vaš API zove samo vaš frontend, sesija je jednostavnija od punog OAuth servera. Server vam treba kad se treće strane integrišu sa vašom platformom ili više aplikacija dijeli korisnike – i tada postavljamo provjeren server (Keycloak, Zitadel, Ory Hydra, Laravel Passport), umjesto da izdavanje tokena pišemo od nule.

Za razvoj sistema CodeWiz prvo mjeri ograničenje, pa bira alat.

JWT autentifikacija urađena na siguran način

JSON Web Token (JWT) je potpisan, kompaktan skup claimova – ko je korisnik, kojoj publici je token namijenjen, kada ističe. Svaki servis koji ima javni ključ može ga provjeriti bez upita u bazu, što odgovara API-jima i mikroservisima. Mana: važeći JWT ostaje važeći dok ne istekne.

Razvoj Sistema ostaje prilagođen poslu, a ne obrnutno.

Ispravna provjera tokena

Provjera mora svaki put da obuhvati potpis, algoritam, izdavaoca, publiku i rok važenja. Ovako to radimo u Node.js-u uz biblioteku jose, uz preuzimanje javnih ključeva sa JWKS endpointa identity providera, tako da rotacija ključa ne traži novi deployment:

Razvoj Sistema je tema ovog članka, od ograničenja koje koči do predaje posla.

import { createRemoteJWKSet, jwtVerify } from "jose";

const JWKS = createRemoteJWKSet(
  new URL("https://auth.example.com/.well-known/jwks.json")
);

export async function verifyAccessToken(token) {
  const { payload } = await jwtVerify(token, JWKS, {
    issuer: "https://auth.example.com",
    audience: "api.example.com",
    algorithms: ["ES256"],
    clockTolerance: 30,
  });
  return payload;
}

Fiksiranje liste algorithms zaustavlja stare napade tipa „alg: none” i zabunu između RS i HS. U Laravelu, Gou i Pythonu iste provjere radimo provjerenim bibliotekama tog ekosistema.

CodeWiz dokumentuje kako razvoj sistema radi u produkciji i kako se predaje timu.

Ključevi za potpis, claimovi i trajanje

Asimetrični potpis: ES256 ili EdDSA (RS256 tamo gdje kompatibilnost to traži), tako da privatni ključ drži samo identity servis, a svaki API provjerava javnim.
Rotacija ključeva: zaglavlje kid na svakom tokenu i JWKS endpoint koji objavljuje trenutni i sljedeći ključ, pa je rotacija rutina, a ne vanredno stanje.
Škrti claimovi: sub, aud, exp, iat, scopeovi i ID tenanta – nikada lični podaci, jer je JWT kodiran, a ne enkriptovan.
Kratko trajanje: access token od 5 do 15 minuta, koji se obnavlja refresh tokenom.

Refresh tokeni i opoziv

Refresh tokeni traju dugo i zato su opasni. Čuvamo ih na serveru kao hash, rotiramo ih pri svakoj upotrebi i uvodimo detekciju ponovne upotrebe: ako se stari refresh token pojavi ponovo, cijela porodica tokena se opoziva i korisnik se mora ponovo prijaviti. Za trenutni opoziv access tokena – nakon promjene lozinke ili odlaska zaposlenog – dodajemo kratkotrajni denylist u Redisu, po ID-u tokena ili korisnika, koji provjeravaju samo servisi kojima to treba.

Kod teme razvoj sistema alati otvorenog koda su prvi izbor kada odgovaraju poslu.

Kolekcija starih metalnih ključeva poredanih na bijeloj podlozi

Postavljanje single sign-on (SSO) preko OIDC-a i SAML-a

Single sign-on omogućava ljudima da jedan identitet – obično nalog firme u Microsoft Entra ID, Google Workspaceu ili Okti – koriste u mnogo aplikacija. Za interne alate to uklanja desetine lozinki i odjavu zaposlenog svodi na jedan klik. Za B2B SaaS, pitanje „Da li podržavate SSO?” često je tvrd uslov u procesu prodaje.

Razvoj Sistema kreće od sistema koji već radi, a ne od praznog šablona.

OIDC ili SAML?

OpenID Connect je savremen izbor: JSON, JWT, jednostavan discovery i dobra podrška u bibliotekama. SAML 2.0 je stariji i zasnovan na XML-u, ali ga mnoge kompanije i javne ustanove i dalje traže. Ozbiljan B2B proizvod u praksi podržava oba, najbolje preko brokera, tako da vaša aplikacija govori samo jedan protokol. Keycloak, Authentik i Zitadel mogu biti taj broker: federišu identity providere klijenata preko SAML-a ili OIDC-a i vašoj aplikaciji izdaju čiste OIDC tokene – raspon mogućnosti je u Keycloak dokumentaciji.

Rad na temi razvoj sistema ostaje u vašem repozitoriju i na vašoj infrastrukturi.

Šta kompletan SSO setup obuhvata

Konfiguraciju identity providera po tenantu, uz usmjeravanje korisnika na prijavu njihove firme prema email domenu.
Just-in-time otvaranje naloga pri prvoj prijavi, plus SCIM 2.0 za automatsko ukidanje pristupa kad neko ode.
Mapiranje grupa i uloga iz identity providera u dozvole vaše aplikacije.
Single logout ili, u najmanju ruku, kratke sesije i back-channel logout, tako da ugašen nalog brzo izgubi pristup.
Provjeru SAML potpisa i certifikata, uz podsjetnike prije nego što certifikati klijenata isteknu.

Upravljanje sesijama i sigurni cookieji

Upravljanje sesijama pokriva sve nakon prijave: kako korisnik ostaje prijavljen, koliko dugo i kako se sesija završava. Za web aplikacije i admin panele serverska sesija sa sigurnim cookiejem i dalje je najčvršće rješenje – može se odmah opozvati i JavaScript do nje ne može.

Sesije ili tokeni: koji model odabrati

Pristup	Opoziv	Najbolje za	Na šta paziti
Serverska sesija (cookie + Redis ili baza)	Trenutni	Web aplikacije, dashboarde i admin panele na jednom domenu	Treba zajednički session store pri horizontalnom skaliranju; CSRF zaštita
Stateless JWT access token	Tek po isteku, osim ako dodate denylist	API-je, mobilne backende, pozive između servisa	Krađu tokena, prevelike tokene, čuvanje tokena u `localStorage`
Opaque token + introspection	Trenutni	Pristup API-ju trećih strana i API-je visoke sigurnosti	Dodatni upit po zahtjevu (može se keširati na nekoliko sekundi)
Backend-for-frontend (BFF)	Trenutni	SPA koje zovu API-je zaštićene OAuthom	Još jedna komponenta za deploy, ali tokeni nikada ne stižu u browser

Ojačavanje cookieja i sesije

Set-Cookie: __Host-session=3q9Zk...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=1800

Prefiks __Host- nameće Secure, zabranjuje atribut Domain i fiksira Path=/, što sprečava poddomene da prepišu cookie. Osim samog cookieja:

ID sesije obnavljamo pri prijavi i pri promjeni privilegija, da spriječimo session fixation.
Uvodimo i timeout neaktivnosti i apsolutno trajanje, podešeno po ulozi – strože za administratore.
Sesije čuvamo u Redisu sa indeksom po korisniku, pa su „odjava sa svih uređaja” i vidljiva lista aktivnih sesija jednostavni za napraviti.
Tražimo ponovnu prijavu (ili svjež MFA upit) prije osjetljivih radnji poput promjene emaila, lozinke ili podataka za isplatu.
Dodajemo CSRF tokene za zahtjeve koji mijenjaju stanje tamo gdje sam SameSite nije dovoljan.

OWASP vodič za upravljanje sesijama je referenca prema kojoj provjeravamo svaku implementaciju.

Autorizacija: uloge, dozvole i više tenanata

Autentifikacija odgovara na „ko ste vi?”; autorizacija odgovara na „da li smijete ovo da uradite?”. Ako je drugo pogrešno, nastaje slomljena kontrola pristupa – korisnik promijeni ID u URL-u i vidi tuđi račun.

RBAC (kontrola pristupa po ulogama) za većinu poslovnih aplikacija: uloge poput vlasnika, administratora, urednika i viewera, mapirane na precizne dozvole, a ne provjeravane po imenu uloge u kodu.
ABAC (po atributima) kad pravila zavise od podataka: „menadžeri mogu odobriti trošak ispod limita u svom sektoru”.
ReBAC (po odnosima, u stilu Google Zanzibara) za modele dijeljenja poput dokumenata i foldera, uz OpenFGA ili SpiceDB.
Izolacija tenanata na jednom mjestu – middleware, Laravel policyji i globalni scopeovi, ili row-level security u PostgreSQL-u – nikada prepuštena svakom kontroleru posebno.

Svako pravilo dobija automatizovane testove, uključujući negativne testove koji dokazuju da tenant A ne može da dira podatke tenanta B.

Lozinke, MFA i passkeys

Većini proizvoda i dalje trebaju vlastiti kredencijali za dio korisnika. Lozinke hešujemo Argon2id algoritmom, nove provjeravamo prema listama kompromitovanih lozinki preko k-anonymity Pwned Passwords API-ja i pratimo trenutne NIST preporuke: duge fraze, bez prisilne periodične promjene i bez proizvoljnih pravila o sastavu.

Višefaktorska autentifikacija: TOTP aplikacije za autentifikaciju, hešovani jednokratni kodovi za oporavak, a SMS samo kao rezerva zbog rizika od SIM-swap napada.
Passkeys (WebAuthn): prijava otporna na phishing, preko Face ID, Touch ID, Windows Hello ili hardverskog ključa, uz lozinku ili umjesto nje.
Zaštita od brute-force napada: limiti po nalogu i po IP adresi, progresivna kašnjenja i provjere botova na prijavi, registraciji i resetu lozinke – tehnike detaljno pokazuju naši vodiči o rate limitingu za API i rate limitingu u Node.js-u i Expressu.
Siguran oporavak naloga: jednokratni, kratkotrajni tokeni za reset, sačuvani kao hash, i identičan odgovor bez obzira na to da li email postoji.

Poluotvoren laptop sa osvijetljenim ekranom na stolu u mračnoj sobi

Razvoj sistema za autentifikaciju: graditi, kupiti ili self-host?

Vrlo malo proizvoda treba autentifikaciju da piše u potpunosti od nule. Prava odluka je na kojoj osnovi da se gradi:

Opcija	Primjeri	Prednosti	Kompromisi
Upravljana identity platforma	Auth0, Clerk, AWS Cognito, Microsoft Entra External ID	Brz početak, hostovani UI, MFA i SSO ugrađeni	Cijena po korisniku raste sa vama, vezanost za dobavljača, pitanja o tome gdje podaci stoje
Self-hosted open-source IdP	Keycloak, Authentik, Zitadel, Ory	Puna kontrola, nema naknade po korisniku, SAML i OIDC federacija uključeni	Vi ga pokrećete, ažurirate, nadgledate i radite backup
Auth u okviru frameworka	Laravel Fortify, Sanctum i Passport, Auth.js, Passport.js, Better Auth	Najjednostavnije za jednu aplikaciju, podaci ostaju u vašoj bazi	SSO između aplikacija i enterprise federacija traže dodatni rad

Podrazumijevano se oslanjamo na open-source: auth u okviru frameworka za jedan proizvod, Keycloak ili Zitadel čim se pojavi više aplikacija ili enterprise SSO. Kad upravljana platforma zaista štedi vrijeme i novac, preporučujemo je – i ostavljamo otvoren put za kasniju migraciju.

Česte greške u sistemu za autentifikaciju koje ispravljamo

Access tokeni i refresh tokeni u localStorage, čitljivi svakom ubačenom skriptu.
JWT koji nikada ne ističe, ili provjera koja prihvata bilo koji algoritam koji token sam navede.
Redirect URI sa wildcardom ili poređenjem po prefiksu, što OAuth pretvara u otvoreni redirect.
ID sesije koji se ne obnavlja nakon prijave, i odjava koja samo briše cookie u browseru.
Linkovi za reset lozinke koji ne ističu ili otkrivaju da li nalog postoji.
Provjere autorizacije samo na frontendu, dok API vjeruje svemu što klijent pošalje.

Kako radimo

Upoznavanje i pregled: mapiramo korisnike, klijente (web, mobilni, API, partneri), identity providere i zahtjeve usklađenosti, i pregledamo postojeću implementaciju.
Arhitektura: biramo tokove, format tokena, strategiju sesija i identity platformu, i dokumentujemo kako se sve uklapa.
Implementacija: gradimo prijavu, MFA, SSO, rukovanje tokenima i provjere dozvola, a tajne držimo van koda.
Sigurnosno testiranje: automatizovani testovi za svaki tok i svaku dozvolu, plus ručne provjere zloupotrebe redirecta, ponavljanja tokena i rupa u kontroli pristupa.
Migracija i puštanje: postojeće korisnike selimo bez prisilnog reseta lozinke gdje je to moguće, i puštamo iza feature flagova.
Podrška: rotacija ključeva, ažuriranja identity providera i nadzor neuspjelih prijava.

Zašto CodeWiz

Full-stack pogled: sami razvijamo Laravel, Node.js i frontend kod u koji se autentifikacija uključuje, pa sigurnost ne staje na stranici za prijavu.
Open-source na prvom mjestu: Keycloak, Zitadel, Authentik i auth u okviru frameworka izbjegavaju naknadu po korisniku i vezanost za dobavljača kad god to ima smisla.
Rješenja po mjeri: jednostavna prijava sesijom za interni alat, puna SAML federacija za enterprise SaaS.
Sigurnost kao dio sistema: hardening servera, Cloudflare, rate limiting i sigurni API-ji su stvari na kojima radimo svaki dan.
Fer cijene: vrhunski razvoj bez vrhunskih cijena, od tima iz Banje Luke koji radi na daljinu sa klijentima iz regiona i svijeta – saznajte više o CodeWizu.

Često postavljana pitanja

Koliko košta izrada sistema za autentifikaciju?

Zavisi od obima: prijava emailom i lozinkom uz MFA za jednu aplikaciju je skroman projekat, dok je SSO za više tenanata, sa SAML federacijom, SCIM provisioningom i preciznim dozvolama, znatno veći posao. Izbor između upravljanog i self-hosted identiteta mijenja i tekuće troškove. Jasnu procjenu dajemo nakon kratkog upoznavanja.

Da li da koristim JWT ili sesije?

Za web aplikaciju koja se servira sa vašeg domena, serverske sesije sa sigurnim cookiejima su obično jednostavnije i sigurnije. JWT access tokeni imaju smisla za API-je koje koriste mobilne aplikacije, partneri ili mnogo backend servisa. Mnogi sistemi koriste oba: sesiju u browseru i kratkotrajne JWT-ove između servisa.

Da li je sigurno da autentifikaciju gradimo sami?

Graditi tokove oko provjerenih biblioteka i identity providera je sigurno i uobičajeno. Izmišljati vlastiti format tokena, heširanje lozinki ili kriptografiju nije. Mi slažemo dobro testirane komponente, a vlastiti rad usmjeravamo na vaša poslovna pravila i iskustvo korisnika.

Možete li dodati SSO u postojeću aplikaciju?

Možemo. Obično uvedemo identity broker poput Keycloaka ili povežemo upravljanu platformu, postojeće naloge spojimo preko potvrđenog emaila i prijavu lozinkom ostavimo dostupnom tokom prelaska, tako da niko ne ostane zaključan.

Moramo li sve korisnike natjerati da resetuju lozinku tokom migracije?

Obično ne. Ako su stari hashovi u poznatom formatu, provjerimo ih pri sljedećoj prijavi i transparentno prehešujemo Argon2id algoritmom. Reset treba samo kod slabog ili nepoznatog starog heširanja.

Spremni da osigurate prijavu i kontrolu pristupa?

Opišite nam aplikaciju, korisnike i mjesto gdje autentifikacija danas stvara trenje ili brigu, a mi ćemo predložiti arhitekturu koja je sigurna, a da ne bude komplikovana. Kontaktirajte nas da razgovaramo o projektu ili pogledajte naše usluge sistema za autentifikaciju.

Razvoj sistema za autentifikaciju: OAuth, JWT i SSO