FixVibe

// docs / baas security / auth0 hardening

Auth0-sikkerhedstjekliste: 22 punkter

Auth0 er en identity-as-a-service-platform med en enorm overflade — applikationer, API'er (resource servers), tenants, actions, regler (legacy), connections og grants. Fejlkonfiguration af nogen af dem er en auth-bypass. Denne tjekliste er en 22-punkts revision på tværs af applikationer, callback-/logout-allowlists, tokens og refresh-rotation, custom actions, RBAC, anomaliopdagelse og igangværende overvågning. Hvert punkt er verificerbart i Auth0 Dashboard på under 10 minutter.

For den tilsvarende tjekliste på Clerk, se Clerk-sikkerhedstjekliste. For baggrund om, hvorfor identitetslag-fejlkonfigurationer er blinde punkter for AI-værktøjer, se Hvorfor AI-kodeværktøjer efterlader sikkerhedshuller.

Applikationstype og grant-typer

Applikationstypen og de aktiverede grant-typer er de højeste-impact-indstillinger i Auth0. At få dem forkert åbner klasser af angreb, som ingen mængde af frontend-kode vil lukke.

  1. Brug Application Type = Single Page Application for browser-kun-apps og Regular Web Application for server-renderede apps. Den forkerte type tillader de forkerte grant-typer — fx en Regular Web App med SPA-grant aktiverer PKCE-løs Implicit flow, som lækker tokens via URL-fragmenter.
  2. Deaktiver Implicit grant-typen på hver applikation. Dashboard → Application → Advanced Settings → Grant Types → fjern markeringen af Implicit. Implicit flow returnerer tokens i URL-fragmenter, hvor de logges i browserhistorik og analyser. Brug Authorization Code med PKCE i stedet.
  3. Deaktiver Password grant, medmindre du har et dokumenteret behov. Resource Owner Password Credentials (ROPC)-grant kræver, at du håndterer brugeradgangskoder selv — hvilket overflødiggør det meste af det, du købte Auth0 til. Deaktiver det, medmindre du integrerer et ældre system.
  4. Aktiver Authorization Code med PKCE på hver offentlig klient. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = aktiveret. PKCE er påkrævet for mobilapps og SPA'er for at forhindre kodeaflytning.

Callback- og logout-URL-allowlists

Åbne omdirigeringer på OAuth-callback-stien er en token-tyveri-primitiv. Auth0's allowlist er dit eneste forsvar.

  1. Sæt Allowed Callback URLs til din nøjagtige produktions-callback-sti — ingen wildcards. https://yourapp.com/callback, ikke https://yourapp.com/*. Wildcard-callbacks lader angribere omdirigere tokens til vilkårlige understier på dit domæne.
  2. Sæt Allowed Logout URLs til en endelig liste. Samme regel: kun eksplicitte URL'er. En åben logout-omdirigering lader angribere udforme phishing-sider, der ligner din post-logout-tilstand.
  3. Sæt Allowed Web Origins til din produktionsoprindelse kun. Bruges til silent authentication (token-fornyelse via skjult iframe). En wildcard-oprindelse lader angriber-sider udføre silent auth mod din tenant.
  4. Sæt Allowed CORS origins for API-endpoints, ikke applikationen. Tenant Settings → Advanced → Allowed CORS origins. Standarden er tom (begrænset); tilføj kun eksplicitte oprindelser, du kontrollerer.

Tokens og refresh-rotation

Token-levetid, refresh-rotation og signeringsalgoritme bestemmer eksplosionsradius for enhver token-lækage.

  1. Aktiver Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Hver refresh udsteder et nyt refresh-token og ugyldiggør det gamle. Kombineret med absolut udløb begrænser dette token-tyveri.
  2. Sæt Refresh Token Reuse Interval til 0 (eller så lavt som din genafspilningstolerance tillader). Genbrugsintervallet lader et token blive brugt to gange i samme vindue — slå det fra, medmindre du har en specifik grund til at beholde det.
  3. Sæt Absolute Refresh Token Expiry til 14-30 dage, ikke uendelig. Application → Refresh Token Expiration → Absolute Expiration. Auth0 standardiserer til Inactivity-kun, hvilket betyder, at en inaktiv session kan vare i årevis.
  4. Sæt JWT Signature Algorithm til RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 bruger asymmetrisk signering, så klienten ikke kan forfalske tokens. Brug aldrig HS256 til klient-vendte applikationer.
  5. Verificer aud- og iss-claims på hver JWT, dit API modtager. Brug den officielle Auth0 SDK på serversiden — den verificerer disse automatisk. Håndrullet JWT-parsing springer normalt audience-validering over, hvilket er en auth-bypass.

Actions og custom kode

Auth0 Actions (og legacy Rules) kører server-side ved login og andre livscyklushændelser. De har adgang til hele request-konteksten. Usikker kode her er en tenant-bred sårbarhed.

  1. Log aldrig event.user eller event.transaction som et helt objekt. Disse indeholder e-mailadresser, IP-adresser og andet PII. Brug kun feltniveau-logning, og log kun, hvad du har brug for.
  2. Brug secrets-storen til enhver API-nøgle eller webhook-URL. Actions → Edit → Secrets. Inline aldrig en API-nøgle som en streng-literal i action-kode — koden er synlig for enhver med Action-editor-adgang på tenanten.
  3. Valider input, før de persisteres som user_metadata eller app_metadata. En selvbetjenings-action, der skriver event.body.name til user.user_metadata.display_name, er en stored-XSS-vektor, hvis din frontend renderer dette felt uden at undslippe det.

RBAC og resource-servere

Hvis du bruger Auth0 RBAC, er rolle-til-rettigheds-mapningen dit autorisationslag. Gør det forkert, og enhver autentificeret bruger kan ramme admin-endpoints.

  1. Definer Resource Servers (API'er) eksplicit i Auth0 Dashboard, ikke i farten. Hvert API har en identifier (audience), scopes og signeringsindstillinger. Uden et registreret API udstedes alle tokens til den implicitte "Auth0 Management API" — forkert audience.
  2. Konfigurer Permissions per API, og kræv dem i din kode med scope-claimet. Tjek ikke rollemedlemskab i din applikationslogik; tjek scopes i access-tokenet. Scopes er den OAuth-native autorisationsmekanisme.
  3. Test, at en autentificeret bruger uden den krævede rolle / scope ikke kan ramme privilegerede endpoints. Log ind som en normal bruger, prøv at kalde POST /api/admin/users/delete. Svar skal være 403.

Anomaliopdagelse og tenant-logfiler

Auth0 udsender højt-signalerende hændelser. Sæt dem op til at alarmere dit team, ikke bare ligge i en logbuffer.

  1. Aktiver Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Hver er slået fra som standard på gratis tiers; slå dem alle til for produktion.
  2. Stream tenant-logfiler til et SIEM eller dine applikationslogfiler. Dashboard → Monitoring → Streams. Auth0 opbevarer logfiler i 30 dage på de fleste planer; langtidsopbevaring kræver en stream ind i dit eget system.
  3. Alarmér på fcoa (failed cross-origin auth)- og fp (failed login)-spidser. En byge af disse i et kort vindue er credential stuffing. Rut til din on-call-kanal.

Næste skridt

Kør en FixVibe-scanning mod din produktions-URL — baas.clerk-auth0-checken markerer Auth0-klienthemmeligheder bundlet i JavaScript og andre identitetsudbyder-eksponeringsklasser. For den tilsvarende på Clerk, se Clerk-sikkerhedstjekliste. For paraplyvisningen på tværs af BaaS-udbydere, læs BaaS-fejlkonfigurationsscanner.

// scan din baas-overflade

Find den åbne tabel, før nogen anden gør det.

Indsæt en produktions-URL. FixVibe opregner de BaaS-udbydere, din app taler med, fingeraftrykker deres offentlige endpoints og rapporterer, hvad en uautentificeret klient kan læse eller skrive. Gratis, ingen installation, intet kort.

  • Gratis niveau — 3 scanninger/måned, intet kort ved tilmelding.
  • Passiv BaaS-fingeraftrykning — ingen domæneverifikation påkrævet.
  • Supabase, Firebase, Clerk, Auth0, Appwrite og flere.
  • AI-fix-prompts på hvert fund — indsæt tilbage i Cursor / Claude Code.
Kør en gratis BaaS-scanning →

ingen tilmelding krævet

Auth0-sikkerhedstjekliste: 22 punkter — Docs · FixVibe