// docs / baas security / auth0 hardening

Sigurnosna checklista za Auth0: 22 stavke

Auth0 je identity-as-a-service platforma s ogromnom površinom — aplikacije, API-ji (resource serveri), tenanti, akcije, rules (legacy), konekcije i grantovi. Pogrešna konfiguracija bilo kojeg od njih je auth bypass. Ova checklista je audit od 22 stavke kroz aplikacije, allowliste za callback / logout, tokene i rotaciju refresha, custom akcije, RBAC, detekciju anomalija i tekući monitoring. Svaka stavka je provjerljiva u Auth0 dashboardu u manje od 10 minuta.

Za ekvivalentnu checklistu za Clerk, pogledajte Sigurnosnu checklistu za Clerk. Za pozadinu zašto su pogrešne konfiguracije na sloju identiteta slijepe točke AI alata, pogledajte Zašto AI alati za kodiranje ostavljaju sigurnosne propuste.

Tip aplikacije i tipovi grantova

Tip aplikacije i omogućeni tipovi grantova su postavke s najvišim utjecajem u Auth0. Pogrešno ih postaviti otvara klase napada koje nijedan frontend kod neće zatvoriti.

Koristite Application Type = Single Page Application za aplikacije samo u pregledniku i Regular Web Application za aplikacije renderirane na serveru. Pogrešan tip dopušta pogrešne tipove grantova — npr. Regular Web App s SPA grantom omogućuje Implicit flow bez PKCE-a, koji propušta tokene preko URL fragmenata.
Onemogućite Implicit grant tip na svakoj aplikaciji. Dashboard → Application → Advanced Settings → Grant Types → odznačite Implicit. Implicit flow vraća tokene u URL fragmentima, gdje se logiraju u povijest preglednika i analitiku. Umjesto toga koristite Authorization Code s PKCE-om.
Onemogućite Password grant osim ako imate dokumentiranu potrebu. Resource Owner Password Credentials (ROPC) grant zahtijeva da sami rukujete korisničkim lozinkama — porazujući većinu razloga zbog kojih ste kupili Auth0. Onemogućite ga osim ako ne integrirate legacy sustav.
Omogućite Authorization Code s PKCE-om na svakom javnom klijentu. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = omogućeno. PKCE je obvezan za mobilne aplikacije i SPA-ove da spriječi prisluškivanje koda.

Allowliste za callback i logout URL-ove

Open redirecti na OAuth callback putanji su primitiva za krađu tokena. Auth0 allowlist je vaša jedina obrana.

Postavite Allowed Callback URLs na točnu produkcijsku callback putanju — bez wildcardova. https://yourapp.com/callback, a ne https://yourapp.com/*. Wildcard callbacks dopuštaju napadačima da preusmjere tokene na proizvoljne podputanje na vašoj domeni.
Postavite Allowed Logout URLs na konačan popis. Isto pravilo: samo eksplicitni URL-ovi. Otvoren logout redirect dopušta napadačima da naprave phishing stranice koje izgledaju kao vaše post-logout stanje.
Postavite Allowed Web Origins samo na vaš produkcijski origin. Koristi se za tihu autentifikaciju (obnavljanje tokena preko skrivenog iframea). Wildcard origin dopušta napadačevim stranicama da vrše tihu autentifikaciju prema vašem tenantu.
Postavite Allowed CORS origine za API endpointove, a ne aplikaciju. Tenant Settings → Advanced → Allowed CORS origins. Default je prazno (restriktivno); dodajte samo eksplicitne origine koje kontrolirate.

Tokeni i rotacija refresha

Životni vijek tokena, rotacija refresha i algoritam potpisivanja odlučuju o radijusu udara svakog curenja tokena.

Omogućite Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Svaki refresh izdaje novi refresh token i poništava stari. U kombinaciji s apsolutnim istekom, ovo ograničava krađu tokena.
Postavite Refresh Token Reuse Interval na 0 (ili koliko god dopušta vaša tolerancija na replay). Interval ponovne upotrebe omogućuje da se token iskoristi dvaput u istom prozoru — isključite ga osim ako nemate specifičan razlog da ga zadržite.
Postavite Absolute Refresh Token Expiry na 14-30 dana, a ne na beskonačno. Application → Refresh Token Expiration → Absolute Expiration. Auth0 po defaultu koristi samo Inactivity, što znači da neaktivna sesija može trajati godinama.
Postavite JWT Signature Algorithm na RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 koristi asimetrično potpisivanje tako da klijent ne može falsificirati tokene. Nikada ne koristite HS256 za aplikacije usmjerene prema klijentima.
Verificirajte claimove aud i iss na svakom JWT-u koji vaš API primi. Koristite službeni Auth0 SDK na serverskoj strani — automatski ih verificira. Ručno parsiranje JWT-a obično preskoči validaciju audience, što je auth bypass.

Akcije i custom kod

Auth0 akcije (i legacy rules) izvršavaju se na serverskoj strani pri prijavi i drugim događajima životnog ciklusa. Imaju pristup cijelom kontekstu zahtjeva. Nesiguran kod ovdje je ranjivost na razini cijelog tenanta.

Nikada ne logirajte event.user ili event.transaction kao cijeli objekt. Oni sadrže email adrese, IP adrese i drugi PII. Koristite samo logiranje na razini polja i logirajte samo ono što vam treba.
Koristite secrets store za bilo koji API ključ ili webhook URL. Actions → Edit → Secrets. Nikada ne ugrađujte API ključ kao string literal u kod akcije — kod je vidljiv svakome tko ima pristup uređivanju akcija na tenantu.
Validirajte inpute prije nego što ih perzistirate kao user_metadata ili app_metadata. Self-service akcija koja piše event.body.name u user.user_metadata.display_name je vektor za stored XSS ako vaš frontend prikazuje to polje bez escapeanja.

RBAC i resource serveri

Ako koristite Auth0 RBAC, mapiranje role-u-dozvolu je vaš autorizacijski sloj. Pogrešno ga postavite i bilo koji autenticirani korisnik može pogoditi admin endpointove.

Definirajte resource servere (API-je) eksplicitno u Auth0 dashboardu, a ne u letu. Svaki API ima identifikator (audience), scopeove i postavke potpisivanja. Bez registriranog API-ja, svi tokeni se izdaju za implicitni "Auth0 Management API" — pogrešan audience.
Konfigurirajte dozvole po API-ju i zahtijevajte ih u kodu sa scope claimom. Ne provjeravajte članstvo u ulozi u logici aplikacije; provjeravajte scopeove u access tokenu. Scopeovi su OAuth-nativan autorizacijski mehanizam.
Testirajte da autenticirani korisnik bez potrebne uloge / scopea ne može pogoditi privilegirane endpointove. Prijavite se kao normalan korisnik, pokušajte pozvati POST /api/admin/users/delete. Odgovor mora biti 403.

Detekcija anomalija i tenant logovi

Auth0 emitira događaje s visokim signalom. Postavite ih da upozoravaju vaš tim, a ne da samo sjede u buferu logova.

Omogućite Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Svaki je isključen po defaultu na besplatnim paketima; uključite ih sve za produkciju.
Streamajte tenant logove u SIEM ili svoje aplikacijske logove. Dashboard → Monitoring → Streams. Auth0 čuva logove 30 dana na većini paketa; dugoročno zadržavanje zahtijeva stream u vaš vlastiti sustav.
Upozorenje na skokove fcoa (failed cross-origin auth) i fp (failed login). Naval ovih u kratkom prozoru je credential stuffing. Usmjerite na svoj on-call kanal.

Sljedeći koraci

Pokrenite FixVibe sken prema svom produkcijskom URL-u — provjera baas.clerk-auth0 označava Auth0 client secrete bundleane u JavaScript i druge klase izlaganja identity providera. Za ekvivalent za Clerk, pogledajte Sigurnosnu checklistu za Clerk. Za pogled iz ptičje perspektive na BaaS providere, pročitajte Skener BaaS pogrešnih konfiguracija.