// docs / baas security / auth0 hardening

Kontrolni seznam varnosti Auth0: 22 točk

Auth0 je platforma identitete kot storitev z ogromno površino — Applications, API-ji (Resource Servers), Tenants, Actions, Rules (Legacy), Connections in Grants. Napačna konfiguracija katerega koli izmed njih je obhod avtentikacije. Ta kontrolni seznam je 22-točkovni pregled v aplikacijah, seznamih dovoljenih povratnih klicev / odjav, žetonih in rotaciji osvežitve, lastnih akcijah, RBAC, zaznavanju anomalij in tekočem spremljanju. Vsaka točka je v nadzorni plošči Auth0 preverljiva v manj kot 10 minutah.

Za enakovreden kontrolni seznam za Clerk glejte Kontrolni seznam varnosti Clerk. Za ozadje, zakaj so napačne konfiguracije na ravni identitete slepa pega UI-orodij, glejte Zakaj UI-orodja za kodiranje puščajo varnostne vrzeli.

Tip aplikacije in vrste odobritev

Tip aplikacije in omogočene vrste odobritev so najvplivnejše nastavitve v Auth0. Če jih nastavite narobe, odprete razrede napadov, ki jih ne zapre nobena količina frontend-kode.

Za aplikacije, ki tečejo samo v brskalniku, uporabite Application Type = Single Page Application, za strežniško izrisane aplikacije pa Regular Web Application. Napačen tip dovoli napačne vrste odobritev — npr. Regular Web App s SPA-odobritvijo omogoči implicitni tok brez PKCE, ki žetone odteka prek URL-fragmentov.
V vsaki aplikaciji onemogočite vrsto odobritve Implicit. Dashboard → Application → Advanced Settings → Grant Types → odkljukajte Implicit. Implicitni tok žetone vrne v URL-fragmentih, kjer se zabeležijo v zgodovini brskalnika in analitiki. Namesto tega uporabite Authorization Code s PKCE.
Onemogočite Password-odobritev, razen če imate dokumentirano potrebo. Odobritev Resource Owner Password Credentials (ROPC) zahteva, da uporabniška gesla obravnavate sami — kar izniči večino tega, zakaj ste kupili Auth0. Onemogočite jo, razen če integrirate starejši sistem.
Na vsakem javnem odjemalcu omogočite Authorization Code s PKCE. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = omogočeno. PKCE je za mobilne aplikacije in SPA potreben za preprečevanje prestrezanja kode.

Seznami dovoljenih URL-jev za povratne klice in odjavo

Odprti preusmerjevalniki na OAuth-poti povratnega klica so primitiv za krajo žetonov. Seznam Auth0 je vaša edina obramba.

Allowed Callback URLs nastavite na natančno pot produkcijskega povratnega klica — brez nadomestnih znakov. https://yourapp.com/callback, ne https://yourapp.com/*. Nadomestni povratni klici omogočajo napadalcem preusmeritev žetonov na poljubne podpoti vaše domene.
Allowed Logout URLs nastavite na končen seznam. Isto pravilo: samo izrecni URL-ji. Odprt preusmerjevalnik odjave omogoča napadalcem izdelavo lažnih strani, ki izgledajo kot vaše stanje po odjavi.
Allowed Web Origins nastavite samo na svoj produkcijski izvor. Uporablja se za tiho avtentikacijo (obnavljanje žetona prek skritega iframe). Nadomestni izvor omogoča napadalskim stranem izvedbo tihe avtentikacije proti vašemu najemniku.
Allowed CORS origins nastavite za API-končne točke, ne za aplikacijo. Tenant Settings → Advanced → Allowed CORS origins. Privzeto je prazno (omejeno); dodajte le izrecne izvore, ki jih nadzorujete.

Žetoni in rotacija osvežitve

Življenjska doba žetona, rotacija osvežitve in algoritem podpisa odločajo o radiju eksplozije katerega koli odtekanja žetona.

Omogočite rotacijo osvežitvenih žetonov. Application → Refresh Token Settings → Rotation. Vsaka osvežitev izda nov osvežitveni žeton in razveljavi starega. V kombinaciji z absolutno veljavnostjo to omejuje krajo žetona.
Refresh Token Reuse Interval nastavite na 0 (ali tako nizko, kot dopušča vaša toleranca do ponovitev). Interval ponovne uporabe omogoča, da je žeton uporabljen dvakrat v istem oknu — izklopite ga, razen če imate poseben razlog za ohranitev.
Absolute Refresh Token Expiry nastavite na 14–30 dni, ne na neskončno. Application → Refresh Token Expiration → Absolute Expiration. Auth0 privzeto nastavi le na Inactivity, kar pomeni, da lahko nedejavna seja vztraja leta.
JWT Signature Algorithm nastavite na RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 uporablja asimetrični podpis, tako da odjemalec ne more ponarediti žetonov. Za aplikacije, obrnjene k odjemalcu, nikoli ne uporabljajte HS256.
Preverite zahtevka aud in iss na vsakem JWT-ju, ki ga prejme vaš API. Na strani strežnika uporabite uradni Auth0-SDK — ta jih preveri samodejno. Lastnoročno razčlenjevanje JWT-ja običajno preskoči preverjanje občinstva, kar je obhod avtentikacije.

Akcije in lastna koda

Auth0 Actions (in starejša Rules) tečejo na strani strežnika ob prijavi in drugih življenjskih dogodkih. Imajo dostop do celotnega konteksta zahteve. Nevarna koda tukaj je ranljivost na ravni celotnega najemnika.

Nikoli ne beležite event.user ali event.transaction kot celotnega objekta. Ti vsebujejo e-poštne naslove, IP-naslove in drugo PII. Uporabljajte samo beleženje na ravni polja in beležite le, kar potrebujete.
Za vsak API-ključ ali URL webhooka uporabite shrambo skrivnosti. Actions → Edit → Secrets. API-ključa nikoli ne vstavljajte kot niz neposredno v kodo akcije — koda je vidna vsem z urejevalnim dostopom do akcij na najemniku.
Vnose preverite, preden jih shranite kot user_metadata ali app_metadata. Samopostrežna akcija, ki event.body.name zapiše v user.user_metadata.display_name, je vektor shranjenega XSS, če vaš frontend to polje izrisuje brez ubežnih znakov.

RBAC in viri-strežniki

Če uporabljate Auth0 RBAC, je preslikava vloge v dovoljenja vaša avtorizacijska plast. Če jo zafrknete, lahko vsak avtenticirani uporabnik doseže skrbniške končne točke.

Definirajte Resource Servers (API-je) izrecno v nadzorni plošči Auth0, ne sproti. Vsak API ima identifikator (audience), obsege in nastavitve podpisa. Brez registriranega API-ja se vsi žetoni izdajo za implicitni „Auth0 Management API" — napačno občinstvo.
Konfigurirajte dovoljenja na API in jih v svoji kodi zahtevajte z zahtevkom scope. V aplikacijski logiki ne preverjajte članstva v vlogi; preverite obsege v dostopnem žetonu. Obsegi so OAuth-domorodni mehanizem avtorizacije.
Preizkusite, da avtenticiran uporabnik brez zahtevane vloge / obsega ne more doseči privilegiranih končnih točk. Prijavite se kot navaden uporabnik, poskusite klicati POST /api/admin/users/delete. Odziv mora biti 403.

Zaznavanje anomalij in dnevniki najemnika

Auth0 oddaja močne signalne dogodke. Nastavite jih tako, da opozarjajo vašo ekipo, ne da samo sedijo v dnevniškem medpomnilniku.

Omogočite Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Vsako je v brezplačnih paketih privzeto izklopljeno; vse vklopite za produkcijo.
Pretočite dnevnike najemnika v SIEM ali svoje dnevnike aplikacije. Dashboard → Monitoring → Streams. Auth0 dnevnike na večini paketov hrani 30 dni; dolgoročna hramba zahteva pretok v vaš lasten sistem.
Alarmirajte ob skokih fcoa (failed cross-origin auth) in fp (failed login). Salva tega v kratkem času je napad s polnjenjem poverilnic. Usmerite v svoj kanal pripravljenosti.

Naslednji koraki

Zaženite FixVibe-pregled proti svojemu produkcijskemu URL-ju — pregled baas.clerk-auth0 označuje skrivnosti odjemalca Auth0, pakirane v JavaScriptu, in druge razrede izpostavljenosti ponudnika identitete. Za enakovredno pri Clerk glejte Kontrolni seznam varnosti Clerk. Za krovni pregled BaaS-ponudnikov preberite Skener napačnih konfiguracij BaaS.