// docs / baas security / auth0 hardening

Auth0-sikkerhetssjekkliste: 22 punkter

Auth0 er en identitets-som-tjeneste-plattform med en enorm flate — applikasjoner, API-er (resource servers), tenants, actions, rules (legacy), connections og grants. Feilkonfigurasjon av noen av dem er en auth-omgåelse. Denne sjekklisten er en 22-punkts gransking på tvers av applikasjoner, callback-/logout-allowlists, tokens og refresh-rotasjon, custom actions, RBAC, anomalideteksjon og løpende overvåking. Hvert punkt er verifiserbart i Auth0 Dashboard på under 10 minutter.

For den tilsvarende sjekklisten for Clerk, se Clerk-sikkerhetssjekkliste. For bakgrunn om hvorfor feilkonfigurasjoner i identitetslaget er blinde punkter for AI-verktøy, se Hvorfor AI-kodeverktøy etterlater sikkerhetshull.

Applikasjonstype og grant types

Applikasjonstypen og de aktiverte grant types er de mest virkningsfulle innstillingene i Auth0. Å få dem feil åpner angrepsklasser som ingen mengde frontend-kode vil lukke.

Bruk Application Type = Single Page Application for kun-nettleser-apper og Regular Web Application for server-rendrede apper. Feil type tillater feil grant types — f.eks. en Regular Web App med SPA-granten muliggjør PKCE-løs Implicit flow, som lekker tokens via URL-fragmenter.
Deaktiver Implicit grant type på hver applikasjon. Dashboard → Application → Advanced Settings → Grant Types → fjern haken på Implicit. Implicit flow returnerer tokens i URL-fragmenter, der de logges i nettleserhistorikk og analytics. Bruk Authorization Code med PKCE i stedet.
Deaktiver Password grant med mindre du har et dokumentert behov. Resource Owner Password Credentials (ROPC) grant krever at du håndterer brukerpassord selv — noe som motvirker det meste av hvorfor du kjøpte Auth0. Deaktiver med mindre du integrerer et legacysystem.
Aktiver Authorization Code med PKCE på hver offentlig klient. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = aktivert. PKCE er nødvendig for mobilapper og SPA-er for å forhindre code interception.

Callback- og logout-URL-allowlists

Åpne omdirigeringer på OAuth-callback-stien er en token-tyveri-primitiv. Auth0s allowlist er ditt eneste forsvar.

Sett Allowed Callback URLs til din eksakte produksjons-callback-sti — ingen wildcards. https://yourapp.com/callback, ikke https://yourapp.com/*. Wildcard-callbacks lar angripere omdirigere tokens til vilkårlige understier på domenet ditt.
Sett Allowed Logout URLs til en endelig liste. Samme regel: kun eksplisitte URL-er. En åpen logout-omdirigering lar angripere lage phishing-sider som ser ut som din post-logout-tilstand.
Sett Allowed Web Origins til kun produksjonsoriginen din. Brukes for silent authentication (token-fornyelse via skjult iframe). En wildcard-origin lar angripersider utføre silent auth mot tenanten din.
Sett Allowed CORS origins for API-endepunktene, ikke applikasjonen. Tenant Settings → Advanced → Allowed CORS origins. Standard er tom (begrenset); legg kun til eksplisitte origins du kontrollerer.

Tokens og refresh-rotasjon

Token-levetid, refresh-rotasjon og signeringsalgoritme bestemmer skadeomfanget av enhver token-lekkasje.

Aktiver Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Hver refresh utsteder et nytt refresh-token og invaliderer det gamle. Kombinert med absolutt utløp begrenser dette token-tyveri.
Sett Refresh Token Reuse Interval til 0 (eller så lavt som replay-toleransen din tillater). Reuse-intervallet lar et token brukes to ganger i samme vindu — slå det av med mindre du har en spesifikk grunn til å beholde det.
Sett Absolute Refresh Token Expiry til 14–30 dager, ikke uendelig. Application → Refresh Token Expiration → Absolute Expiration. Auth0 har som standard kun Inactivity, noe som betyr at en inaktiv økt kan vedvare i årevis.
Sett JWT Signature Algorithm til RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 bruker asymmetrisk signering så klienten ikke kan forfalske tokens. Bruk aldri HS256 for klientvendte applikasjoner.
Verifiser aud- og iss-claims på hver JWT API-et ditt mottar. Bruk den offisielle Auth0-SDK-en på serversiden — den verifiserer disse automatisk. Hjemmelaget JWT-parsing hopper vanligvis over audience-validering, noe som er en auth-omgåelse.

Actions og egen kode

Auth0 Actions (og legacy Rules) kjører serverside ved innlogging og andre livssyklushendelser. De har tilgang til hele request-konteksten. Usikker kode her er en tenant-omfattende sårbarhet.

Logg aldri event.user eller event.transaction som et helt objekt. Disse inneholder e-postadresser, IP-adresser og annen PII. Bruk kun felt-nivå logging, og logg kun det du trenger.
Bruk secrets-lageret for enhver API-nøkkel eller webhook-URL. Actions → Edit → Secrets. Inline aldri en API-nøkkel som en streng-literal i action-kode — koden er synlig for enhver med Action-editor-tilgang på tenanten.
Valider input før du persisterer dem som user_metadata eller app_metadata. En self-service-action som skriver event.body.name til user.user_metadata.display_name er en stored-XSS-vektor hvis frontenden din rendrer det feltet uten escaping.

RBAC og resource servers

Hvis du bruker Auth0 RBAC, er rolle-til-rettighet-mappingen din autorisasjonslag. Få det feil og enhver autentisert bruker kan treffe admin-endepunkter.

Definer Resource Servers (API-er) eksplisitt i Auth0 Dashboard, ikke på flyttende fot. Hvert API har en identifikator (audience), scopes og signeringsinnstillinger. Uten et registrert API utstedes alle tokens for det implisitte "Auth0 Management API" — feil audience.
Konfigurer Permissions per API og krev dem i koden din med scope-claimet. Ikke sjekk rollemedlemskap i applikasjonslogikken din; sjekk scopes i access-tokenet. Scopes er den OAuth-native autorisasjonsmekanismen.
Test at en autentisert bruker uten den nødvendige rollen / scope ikke kan treffe privilegerte endepunkter. Logg inn som vanlig bruker, prøv å kalle POST /api/admin/users/delete. Svaret må være 403.

Anomalideteksjon og tenant-logger

Auth0 sender hendelser med høy signalverdi. Sett dem opp til å varsle teamet ditt, ikke bare sitte i en loggbuffer.

Aktiver Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Hver er av som standard på gratisnivåer; slå alle på for produksjon.
Stream tenant-logger til en SIEM eller applikasjonsloggene dine. Dashboard → Monitoring → Streams. Auth0 beholder logger i 30 dager på de fleste planer; langsiktig oppbevaring krever en stream inn i ditt eget system.
Varsle om topper av fcoa (failed cross-origin auth) og fp (failed login). Et byge av disse i et kort vindu er credential stuffing. Rut til on-call-kanalen din.

Neste steg

Kjør en FixVibe-skanning mot produksjons-URL-en din — baas.clerk-auth0-sjekken flagger Auth0 client secrets bundlet i JavaScript og andre eksponeringsklasser for identitetsleverandører. For tilsvarende for Clerk, se Clerk-sikkerhetssjekkliste. For helhetsbildet på tvers av BaaS-leverandører, les BaaS-feilkonfigurasjonsskanner.