// 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, allowlist-e 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 tač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 uticajem 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 renderovane na serveru. Pogrešan tip dozvoljava pogrešne tipove grantova — npr. Regular Web App s SPA grantom omogućava Implicit flow bez PKCE-a, koji curi 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 loguju u historiju preglednika i analitiku. Umjesto toga koristite Authorization Code s PKCE-om.
Onemogućite Password grant osim ako imate dokumentovanu 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 integrišete legacy sistem.
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 obavezan za mobilne aplikacije i SPA-ove da spriječi prisluškivanje koda.

Allowlist-e za callback i logout URL-ove

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

Postavite Allowed Callback URLs na tačnu produkcijsku callback putanju — bez wildcardova. https://yourapp.com/callback, ne https://yourapp.com/*. Wildcard callbacks dozvoljavaju napadačima da preusmjere tokene na proizvoljne podputanje na vašoj domeni.
Postavite Allowed Logout URLs na konačnu listu. Isto pravilo: samo eksplicitni URL-ovi. Otvoren logout redirect dozvoljava 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 dozvoljava napadačevim stranicama da vrše tihu autentifikaciju prema vašem tenantu.
Postavite Allowed CORS origine za API endpointove, ne aplikaciju. Tenant Settings → Advanced → Allowed CORS origins. Default je prazno (restriktivno); dodajte samo eksplicitne origine koje kontrolišete.

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ćava 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, 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.
Verifikujte claimove aud i iss na svakom JWT-u koji vaš API primi. Koristite zvanični Auth0 SDK na serverskoj strani — automatski ih verifikuje. 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 nivou cijelog tenanta.

Nikada ne logujte event.user ili event.transaction kao cijeli objekat. Oni sadrže email adrese, IP adrese i drugi PII. Koristite samo logiranje na nivou polja i logujte 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 ko 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 escape-ovanja.

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.

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

Detekcija anomalija i tenant logovi

Auth0 emituje događaje s visokim signalom. Postavite ih da upozoravaju vaš tim, 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.
Streamujte 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 sistem.
Upozorenje na skokove fcoa (failed cross-origin auth) i fp (failed login). Naval ovih u kratkom prozoru je credential stuffing. Rutirajte na svoj on-call kanal.

Sljedeći koraci

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