// docs / baas security / auth0 hardening

Auth0-Sicherheits-Checkliste: 22 Punkte

Auth0 ist eine Identity-as-a-Service-Plattform mit enormer Oberfläche — Applications, APIs (Resource Servers), Tenants, Actions, Rules (Legacy), Connections und Grants. Eine Fehlkonfiguration eines beliebigen davon ist ein Auth-Bypass. Diese Checkliste ist ein 22-Punkte-Audit über Applications, Callback-/Logout-Allowlists, Tokens und Refresh-Rotation, benutzerdefinierte Actions, RBAC, Anomalieerkennung und laufendes Monitoring. Jeder Punkt ist im Auth0-Dashboard in unter 10 Minuten verifizierbar.

Für die äquivalente Checkliste zu Clerk siehe Clerk-Sicherheits-Checkliste. Für Hintergrund, warum Fehlkonfigurationen auf Identity-Ebene blinde Flecken von KI-Tools sind, siehe Warum KI-Coding-Tools Sicherheitslücken hinterlassen.

Application-Type und Grant-Types

Der Application-Type und die aktivierten Grant-Types sind die Einstellungen mit dem größten Impact in Auth0. Sie falsch zu setzen, öffnet Angriffsklassen, die keine Menge Frontend-Code schließt.

Verwende Application Type = Single Page Application für reine Browser-Apps und Regular Web Application für serverseitig gerenderte Apps. Der falsche Typ erlaubt die falschen Grant-Types — z.B. eine Regular Web App mit dem SPA-Grant aktiviert den PKCE-losen Implicit-Flow, der Tokens via URL-Fragmenten leakt.
Deaktiviere den Implicit-Grant-Type in jeder Application. Dashboard → Application → Advanced Settings → Grant Types → entferne Implicit. Implicit-Flow gibt Tokens in URL-Fragmenten zurück, wo sie in Browser-History und Analytics geloggt werden. Verwende Authorization Code mit PKCE stattdessen.
Deaktiviere Password-Grant, sofern du nicht einen dokumentierten Bedarf hast. Resource Owner Password Credentials (ROPC) Grant verlangt, dass du Nutzerpasswörter selbst handhabst — was das meiste, wofür du Auth0 gekauft hast, zunichte macht. Deaktiviere es, sofern du kein Legacy-System integrierst.
Aktiviere Authorization Code mit PKCE auf jedem öffentlichen Client. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = aktiviert. PKCE ist für Mobile-Apps und SPAs erforderlich, um Code-Abfangen zu verhindern.

Callback- und Logout-URL-Allowlists

Offene Redirects auf dem OAuth-Callback-Pfad sind eine Token-Diebstahl-Primitive. Die Allowlist von Auth0 ist deine einzige Verteidigung.

Setze Allowed Callback URLs auf deinen exakten Produktions-Callback-Pfad — keine Wildcards. https://yourapp.com/callback, nicht https://yourapp.com/*. Wildcard-Callbacks erlauben Angreifern, Tokens auf beliebige Subpfade deiner Domain umzuleiten.
Setze Allowed Logout URLs auf eine endliche Liste. Gleiche Regel: nur explizite URLs. Ein offener Logout-Redirect erlaubt Angreifern, Phishing-Seiten zu bauen, die wie dein Post-Logout-Zustand aussehen.
Setze Allowed Web Origins nur auf deinen Produktions-Origin. Wird für stille Authentifizierung (Token-Erneuerung via verstecktem iframe) verwendet. Ein Wildcard-Origin erlaubt Angreiferseiten, stille Auth gegen deinen Tenant durchzuführen.
Setze Allowed CORS origins für die API-Endpunkte, nicht für die Application. Tenant Settings → Advanced → Allowed CORS origins. Default ist leer (restriktiv); füge nur explizite Origins hinzu, die du kontrollierst.

Tokens und Refresh-Rotation

Token-Lebensdauer, Refresh-Rotation und Signaturalgorithmus entscheiden den Wirkungsradius jeglichen Token-Leaks.

Aktiviere Refresh-Token-Rotation. Application → Refresh Token Settings → Rotation. Jeder Refresh stellt einen neuen Refresh-Token aus und invalidiert den alten. Kombiniert mit absoluter Ablaufzeit begrenzt das Token-Diebstahl.
Setze Refresh Token Reuse Interval auf 0 (oder so niedrig wie deine Replay-Toleranz erlaubt). Das Reuse-Interval erlaubt einem Token, zweimal im selben Fenster verwendet zu werden — schalte es aus, sofern du keinen spezifischen Grund hast, es zu behalten.
Setze Absolute Refresh Token Expiry auf 14-30 Tage, nicht unendlich. Application → Refresh Token Expiration → Absolute Expiration. Auth0 stellt nur Inactivity-Default, was bedeutet, dass eine inaktive Session jahrelang persistieren kann.
Setze JWT Signature Algorithm auf RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 nutzt asymmetrische Signatur, der Client kann also keine Tokens fälschen. Verwende niemals HS256 für client-zugewandte Applications.
Verifiziere aud- und iss-Claims auf jedem JWT, das deine API empfängt. Verwende das offizielle Auth0-SDK auf Serverseite — es verifiziert diese automatisch. Selbstgeschriebenes JWT-Parsing überspringt üblicherweise die Audience-Validierung, was ein Auth-Bypass ist.

Actions und benutzerdefinierter Code

Auth0 Actions (und Legacy Rules) laufen serverseitig beim Login und anderen Lifecycle-Ereignissen. Sie haben Zugriff auf den gesamten Request-Kontext. Unsicherer Code hier ist eine tenant-weite Verwundbarkeit.

Logge niemals event.user oder event.transaction als ganzes Objekt. Diese enthalten E-Mail-Adressen, IP-Adressen und andere PII. Verwende ausschließlich feldgenaues Logging und logge nur, was du brauchst.
Verwende den Secrets-Store für jeden API-Key oder jede Webhook-URL. Actions → Edit → Secrets. Inline niemals einen API-Key als Stringliteral im Action-Code — der Code ist für jeden mit Action-Editor-Zugriff auf den Tenant sichtbar.
Validiere Eingaben, bevor du sie als user_metadata oder app_metadata persistierst. Eine Self-Service-Action, die event.body.name in user.user_metadata.display_name schreibt, ist ein Stored-XSS-Vektor, wenn dein Frontend dieses Feld ohne Escape rendert.

RBAC und Resource Servers

Wenn du Auth0 RBAC verwendest, ist das Rolle-zu-Berechtigung-Mapping deine Autorisierungsschicht. Falsch gemacht, kann jeder authentifizierte Nutzer Admin-Endpunkte erreichen.

Definiere Resource Servers (APIs) explizit im Auth0-Dashboard, nicht spontan. Jede API hat einen Identifier (die audience), Scopes und Signatur-Einstellungen. Ohne registrierte API werden alle Tokens für die implizite „Auth0 Management API" ausgestellt — falsche Audience.
Konfiguriere Permissions pro API und fordere sie in deinem Code mit dem scope-Claim ein. Prüfe keine Rollen-Mitgliedschaft in deiner Anwendungslogik; prüfe Scopes im Access-Token. Scopes sind der OAuth-native Autorisierungsmechanismus.
Teste, dass ein authentifizierter Nutzer ohne die erforderliche Rolle / Scope keine privilegierten Endpunkte erreichen kann. Melde dich als normaler Nutzer an, versuche POST /api/admin/users/delete aufzurufen. Antwort muss 403 sein.

Anomalieerkennung und Tenant-Logs

Auth0 emittiert signalstarke Ereignisse. Konfiguriere sie so, dass sie dein Team alarmieren, nicht nur in einem Log-Puffer sitzen.

Aktiviere Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Jedes ist auf kostenlosen Tarifen standardmäßig aus; aktiviere alle für Produktion.
Streame Tenant-Logs an ein SIEM oder deine Application-Logs. Dashboard → Monitoring → Streams. Auth0 behält Logs auf den meisten Tarifen 30 Tage; Langzeitspeicherung erfordert einen Stream in dein eigenes System.
Alarmiere bei Spikes von fcoa (failed cross-origin auth) und fp (failed login). Eine Salve davon in kurzer Zeit ist Credential-Stuffing. Route an deinen On-Call-Channel.

Nächste Schritte

Lass einen FixVibe-Scan gegen deine Produktions-URL laufen — der baas.clerk-auth0-Check markiert Auth0-Client-Secrets, die in JavaScript gebündelt sind, und andere Identity-Provider-Offenlegungsklassen. Für das Äquivalent zu Clerk siehe Clerk-Sicherheits-Checkliste. Für den Gesamtüberblick über BaaS-Anbieter lies BaaS-Fehlkonfigurations-Scanner.