// docs / baas security / auth0 hardening

Auth0-säkerhetschecklista: 22 punkter

Auth0 är en identitet-som-tjänst-plattform med en enorm yta — applikationer, API:er (resource servers), tenants, actions, rules (legacy), connections och grants. Felkonfiguration av någon av dem är ett auth-kringgående. Den här checklistan är en 22-punkts granskning över applikationer, callback-/logout-allowlists, tokens och refresh-rotation, custom actions, RBAC, anomaliedetektion och löpande övervakning. Varje punkt är verifierbar i Auth0-dashboarden på under 10 minuter.

För motsvarande checklista för Clerk, se Clerk-säkerhetschecklista. För bakgrund till varför identitetslagrets felkonfigurationer är AI-verktygens blinda fläckar, se Varför AI-kodningsverktyg lämnar säkerhetsluckor.

Applikationstyp och grant types

Applikationstypen och de aktiverade grant types är de mest impactfulla inställningarna i Auth0. Att få dem fel öppnar attackklasser som ingen mängd frontend-kod kommer att stänga.

Använd Application Type = Single Page Application för endast-webbläsar-appar och Regular Web Application för server-renderade appar. Fel typ tillåter fel grant types — t.ex. en Regular Web App med SPA-granten möjliggör PKCE-lös Implicit flow, som läcker tokens via URL-fragment.
Inaktivera Implicit grant type på varje applikation. Dashboard → Application → Advanced Settings → Grant Types → kryssa av Implicit. Implicit flow returnerar tokens i URL-fragment, där de loggas i webbläsarhistorik och analytics. Använd Authorization Code med PKCE istället.
Inaktivera Password grant om du inte har ett dokumenterat behov. Resource Owner Password Credentials (ROPC) grant kräver att du hanterar användarlösenord själv — vilket motverkar det mesta av varför du köpte Auth0. Inaktivera om du inte integrerar ett legacysystem.
Aktivera Authorization Code med PKCE på varje publik klient. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = aktiverat. PKCE krävs för mobilappar och SPA:er för att förhindra code interception.

Callback- och logout-URL-allowlists

Öppna omdirigeringar på OAuth-callback-stigen är en token-stöld-primitiv. Auth0:s allowlist är ditt enda försvar.

Sätt Allowed Callback URLs till din exakta produktions-callback-sökväg — inga wildcards. https://yourapp.com/callback, inte https://yourapp.com/*. Wildcard-callbacks låter angripare omdirigera tokens till godtyckliga undersökvägar på din domän.
Sätt Allowed Logout URLs till en ändlig lista. Samma regel: endast explicita URL:er. En öppen logout-omdirigering låter angripare skapa phishing-sidor som ser ut som ditt post-logout-tillstånd.
Sätt Allowed Web Origins endast till din produktionsorigin. Används för silent authentication (token-förnyelse via dold iframe). En wildcard-origin låter angriparsidor utföra silent auth mot din tenant.
Sätt Allowed CORS origins för API-endpoints, inte applikationen. Tenant Settings → Advanced → Allowed CORS origins. Default är tomt (restriktivt); lägg endast till explicita origins du kontrollerar.

Tokens och refresh-rotation

Token-livslängd, refresh-rotation och signeringsalgoritm bestämmer skadeområdet för varje token-läcka.

Aktivera Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Varje refresh utfärdar en ny refresh-token och invaliderar den gamla. Kombinerat med absolut förfall begränsar detta token-stöld.
Sätt Refresh Token Reuse Interval till 0 (eller så lågt som din replay-tolerans tillåter). Reuse-intervallet låter en token användas två gånger i samma fönster — stäng av det om du inte har ett specifikt skäl att behålla det.
Sätt Absolute Refresh Token Expiry till 14–30 dagar, inte oändlighet. Application → Refresh Token Expiration → Absolute Expiration. Auth0 defaultar till endast-Inactivity, vilket betyder att en idle-session kan persistera i åratal.
Sätt JWT Signature Algorithm till RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 använder asymmetrisk signering så klienten inte kan förfalska tokens. Använd aldrig HS256 för klientvända applikationer.
Verifiera aud- och iss-claims på varje JWT ditt API tar emot. Använd den officiella Auth0-SDK:n på serversidan — den verifierar dessa automatiskt. Hand-rullad JWT-parsning hoppar oftast över audience-validering, vilket är ett auth-kringgående.

Actions och egen kod

Auth0 Actions (och legacy Rules) körs serverside vid inloggning och andra livscykelhändelser. De har åtkomst till hela request-kontexten. Osäker kod här är en tenant-omfattande sårbarhet.

Logga aldrig event.user eller event.transaction som ett helt objekt. Dessa innehåller e-postadresser, IP-adresser och annan PII. Använd fältnivå-loggning endast, och logga bara det du behöver.
Använd secrets-lagret för varje API-nyckel eller webhook-URL. Actions → Edit → Secrets. Inlina aldrig en API-nyckel som en strängliteral i action-kod — koden är synlig för alla med Action-editor-åtkomst på tenanten.
Validera input innan du persisterar dem som user_metadata eller app_metadata. En self-service-action som skriver event.body.name till user.user_metadata.display_name är en stored-XSS-vektor om din frontend renderar det fältet utan escaping.

RBAC och resource servers

Om du använder Auth0 RBAC är roll-till-behörighet-mappningen ditt auktoriseringslager. Få det fel och vilken autentiserad användare som helst kan träffa admin-endpoints.

Definiera Resource Servers (API:er) explicit i Auth0-dashboarden, inte på flygande fot. Varje API har en identifierare (audience), scopes och signeringsinställningar. Utan ett registrerat API utfärdas alla tokens för det implicita "Auth0 Management API" — fel audience.
Konfigurera Permissions per API och kräv dem i din kod med scope-claimen. Kontrollera inte rollmedlemskap i din applikationslogik; kontrollera scopes i access-tokenen. Scopes är den OAuth-naturliga auktoriseringsmekanismen.
Testa att en autentiserad användare utan den krävda rollen / scope:n inte kan träffa privilegierade endpoints. Logga in som vanlig användare, försök anropa POST /api/admin/users/delete. Svaret måste vara 403.

Anomaliedetektion och tenant-loggar

Auth0 skickar högsignal-händelser. Sätt upp dem så att de larmar ditt team, inte bara sitter i en loggbuffert.

Aktivera Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Var och en är avstängd som default på gratisnivåerna; slå på dem alla för produktion.
Streama tenant-loggar till ett SIEM eller dina applikationsloggar. Dashboard → Monitoring → Streams. Auth0 behåller loggar i 30 dagar på de flesta planer; långsiktig retention kräver en stream in i ditt eget system.
Larma vid spikar av fcoa (failed cross-origin auth) och fp (failed login). En skur av dessa under ett kort fönster är credential stuffing. Ruta till din on-call-kanal.

Nästa steg

Kör en FixVibe-scanning mot din produktions-URL — baas.clerk-auth0-checken flaggar Auth0 client secrets buntade i JavaScript och andra exponeringsklasser för identitetsleverantörer. För motsvarande för Clerk, se Clerk-säkerhetschecklista. För helhetsbilden över BaaS-leverantörer, läs BaaS-felkonfigurationsscanner.