// docs / baas security / auth0 hardening

Auth0-beveiligingschecklist: 22 punten

Auth0 is een identity-as-a-service-platform met een enorm oppervlak — applicaties, API's (resource-servers), tenants, acties, regels (legacy), connecties en grants. Een verkeerde configuratie van een ervan is een auth-bypass. Deze checklist is een audit met 22 punten over applicaties, callback- / logout-allowlists, tokens en refresh-rotatie, aangepaste acties, RBAC, anomaliedetectie en doorlopende monitoring. Elk item is verifieerbaar in het Auth0-dashboard in minder dan 10 minuten.

Voor de equivalente checklist op Clerk, zie Clerk-beveiligingschecklist. Voor achtergrond over waarom identity-laag-misconfiguraties blinde vlekken zijn voor AI-tools, zie Waarom AI-codeertools beveiligingsgaten achterlaten.

Applicatietype en grant-typen

Het applicatietype en de ingeschakelde grant-typen zijn de instellingen met de grootste impact in Auth0. Het verkeerd doen opent aanvalsklassen die geen enkele hoeveelheid frontend-code zal sluiten.

Gebruik Applicatietype = Single Page Application voor alleen-browser-apps en Regular Web Application voor server-rendered apps. Het verkeerde type staat de verkeerde grant-typen toe — bijv. een Regular Web App met de SPA-grant maakt PKCE-loze Implicit-flow mogelijk, die tokens lekt via URL-fragmenten.
Schakel het Implicit-grant-type uit op elke applicatie. Dashboard → Applicatie → Geavanceerde instellingen → Grant-typen → vink Implicit uit. Implicit-flow retourneert tokens in URL-fragmenten, waar ze worden gelogd in browsergeschiedenis en analytics. Gebruik Authorization Code met PKCE in plaats daarvan.
Schakel Password-grant uit tenzij je een gedocumenteerde behoefte hebt. Resource Owner Password Credentials (ROPC)-grant vereist dat je gebruikerswachtwoorden zelf afhandelt — wat het meeste verslaat waarvoor je Auth0 hebt gekocht. Schakel het uit tenzij je een legacy-systeem integreert.
Schakel Authorization Code met PKCE in op elke openbare client. Dashboard → Geavanceerde instellingen → OAuth → JsonWebToken-handtekeningsalgoritme = RS256, OIDC-conform = ingeschakeld. PKCE is vereist voor mobiele apps en SPA's om code-onderschepping te voorkomen.

Callback- en logout-URL-allowlists

Open redirects op het OAuth-callbackpad zijn een token-diefstal-primitief. De allowlist van Auth0 is je enige verdediging.

Stel Toegestane Callback-URL's in op je exacte productie-callbackpad — geen wildcards. https://yourapp.com/callback, niet https://yourapp.com/*. Wildcard-callbacks laten aanvallers tokens omleiden naar willekeurige subpaden op je domein.
Stel Toegestane Logout-URL's in op een eindige lijst. Dezelfde regel: alleen expliciete URL's. Een open logout-redirect laat aanvallers phishing-pagina's maken die eruit zien als je post-logout-status.
Stel Toegestane Web Origins in op alleen je productie-origin. Gebruikt voor stille authenticatie (tokenvernieuwing via verborgen iframe). Een wildcard-origin laat aanvallerspagina's stille auth uitvoeren tegen je tenant.
Stel Toegestane CORS-origins in voor de API-endpoints, niet de applicatie. Tenant-instellingen → Geavanceerd → Toegestane CORS-origins. Standaard is leeg (beperkt); voeg alleen expliciete origins toe die je controleert.

Tokens en refresh-rotatie

Tokenlevensduur, refresh-rotatie en handtekeningsalgoritme bepalen de blast radius van elke token-lek.

Schakel Refresh Token Rotation in. Applicatie → Refresh Token-instellingen → Rotatie. Elke refresh geeft een nieuw refresh-token uit en maakt het oude ongeldig. Gecombineerd met absolute vervaltijd bevat dit token-diefstal.
Stel Refresh Token Reuse Interval in op 0 (of zo laag als je replay-tolerantie toestaat). Het reuse-interval laat een token tweemaal in hetzelfde venster worden gebruikt — schakel het uit tenzij je een specifieke reden hebt om het te houden.
Stel Absolute Refresh Token-vervaltijd in op 14-30 dagen, niet oneindig. Applicatie → Refresh Token-vervaltijd → Absolute vervaltijd. Auth0 staat standaard op alleen Inactiviteit, wat betekent dat een inactieve sessie jaren kan voortduren.
Stel JWT-handtekeningsalgoritme in op RS256. Applicatie → Geavanceerd → OAuth → JsonWebToken-handtekeningsalgoritme. RS256 gebruikt asymmetrische ondertekening, zodat de client geen tokens kan vervalsen. Gebruik nooit HS256 voor client-gerichte applicaties.
Verifieer aud- en iss-claims op elke JWT die je API ontvangt. Gebruik de officiële Auth0-SDK aan de serverzijde — het verifieert deze automatisch. Handgemaakte JWT-parsing slaat meestal audience-validatie over, wat een auth-bypass is.

Acties en aangepaste code

Auth0 Actions (en legacy Rules) draaien server-side bij login en andere levenscyclusgebeurtenissen. Ze hebben toegang tot de hele aanvraagcontext. Onveilige code hier is een tenant-brede kwetsbaarheid.

Log nooit event.user of event.transaction als een heel object. Deze bevatten e-mailadressen, IP-adressen en andere PII. Gebruik alleen veld-niveau-logging en log alleen wat je nodig hebt.
Gebruik de geheimen-opslag voor elke API-sleutel of webhook-URL. Acties → Bewerken → Geheimen. Inline nooit een API-sleutel als een stringliteraal in actiecode — de code is zichtbaar voor iedereen met Action-editor-toegang op de tenant.
Valideer invoer voordat je ze persisteert als user_metadata of app_metadata. Een self-service-actie die event.body.name naar user.user_metadata.display_name schrijft, is een stored-XSS-vector als je frontend dat veld rendert zonder te escapen.

RBAC en resource-servers

Als je Auth0 RBAC gebruikt, is de rol-naar-permissie-mapping je autorisatielaag. Doe het verkeerd en elke geauthenticeerde gebruiker kan admin-endpoints raken.

Definieer Resource-servers (API's) expliciet in het Auth0-dashboard, niet on-the-fly. Elke API heeft een identifier (de audience), scopes en handtekeninginstellingen. Zonder een geregistreerde API worden alle tokens uitgegeven voor de impliciete "Auth0 Management API" — verkeerde audience.
Configureer Permissies per API en vereis ze in je code met de scope-claim. Controleer geen rol-lidmaatschap in je applicatielogica; controleer scopes in het access-token. Scopes zijn het OAuth-native autorisatiemechanisme.
Test dat een geauthenticeerde gebruiker zonder de vereiste rol / scope geprivilegieerde endpoints niet kan raken. Log in als een gewone gebruiker, probeer POST /api/admin/users/delete aan te roepen. Antwoord moet 403 zijn.

Anomaliedetectie en tenant-logs

Auth0 zendt hoge-signaal-gebeurtenissen uit. Stel ze in om je team te alarmeren, niet om gewoon in een logbuffer te zitten.

Schakel Aanvalsbescherming in: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Beveiliging → Aanvalsbescherming. Elk staat standaard uit op gratis tiers; zet ze allemaal aan voor productie.
Stream tenant-logs naar een SIEM of je applicatielogs. Dashboard → Monitoring → Streams. Auth0 bewaart logs 30 dagen op de meeste plannen; langetermijnbewaring vereist een stream naar je eigen systeem.
Alert bij fcoa (mislukte cross-origin auth) en fp (mislukte login) pieken. Een burst van deze in een kort venster is credential-stuffing. Route naar je on-call-kanaal.

Volgende stappen

Voer een FixVibe-scan uit tegen je productie-URL — de baas.clerk-auth0-check markeert Auth0 client-secrets gebundeld in JavaScript en andere identity-provider-blootstellingsklassen. Voor de equivalent op Clerk, zie Clerk-beveiligingschecklist. Voor het paraplu-overzicht over BaaS-providers, lees BaaS-misconfiguratiescanner.