// docs / baas security / auth0 hardening

Kontrolní seznam zabezpečení Auth0: 22 položek

Auth0 je identity-as-a-service platforma s obrovským povrchem — aplikace, API (resource servery), tenanti, akce, pravidla (legacy), spojení a granty. Chybná konfigurace kteréhokoliv z nich je obejití autentizace. Tento kontrolní seznam je 22bodový audit napříč aplikacemi, callback / logout allowlisty, tokeny a refresh rotací, vlastními akcemi, RBAC, detekcí anomálií a průběžným monitoringem. Každá položka je ověřitelná v Auth0 Dashboardu za méně než 10 minut.

Pro ekvivalentní kontrolní seznam na Clerk viz Kontrolní seznam zabezpečení Clerk. Pro pozadí toho, proč jsou chybné konfigurace vrstvy identity slepými místy AI nástrojů, viz Proč nástroje pro kódování s AI nechávají bezpečnostní mezery.

Typ aplikace a typy grantů

Typ aplikace a povolené typy grantů jsou nejvýznamnější nastavení v Auth0. Chybné nastavení otevírá třídy útoků, které žádné množství frontendového kódu neuzavře.

U aplikací pouze pro prohlížeč použijte Application Type = Single Page Application a u serverově renderovaných Regular Web Application. Špatný typ povoluje špatné typy grantů — např. Regular Web App s grantem SPA povoluje Implicit flow bez PKCE, který uniká tokeny přes URL fragmenty.
Na každé aplikaci vypněte typ grantu Implicit. Dashboard → Application → Advanced Settings → Grant Types → odškrtněte Implicit. Implicit flow vrací tokeny v URL fragmentech, kde jsou logovány v historii prohlížeče a analytics. Místo toho použijte Authorization Code s PKCE.
Vypněte grant Password, pokud nemáte zdokumentovanou potřebu. Grant Resource Owner Password Credentials (ROPC) vyžaduje, abyste sami zpracovávali hesla uživatelů — což negativně ovlivňuje většinu toho, kvůli čemu jste si Auth0 koupili. Vypněte ho, pokud neintegrujete starší systém.
Povolte Authorization Code s PKCE na každém veřejném klientu. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = zapnuto. PKCE je vyžadováno pro mobilní aplikace a SPA, aby se zabránilo zachycení kódu.

Allowlisty callback a logout URL

Otevřené přesměrování na OAuth callback cestě je primitivem pro krádež tokenu. Allowlist Auth0 je vaší jedinou obranou.

Nastavte Allowed Callback URLs na přesnou produkční callback cestu — bez wildcardů. https://yourapp.com/callback, ne https://yourapp.com/*. Wildcard callbacky umožňují útočníkům přesměrovat tokeny na libovolné podcesty na vaší doméně.
Nastavte Allowed Logout URLs na konečný seznam. Stejné pravidlo: pouze explicitní URL. Otevřené logout přesměrování umožňuje útočníkům vytvořit phishingové stránky, které vypadají jako váš stav po odhlášení.
Nastavte Allowed Web Origins pouze na vaši produkční origin. Používá se pro tichou autentizaci (obnovení tokenu přes skrytý iframe). Wildcard origin umožňuje stránkám útočníka provést tichou autentizaci proti vašemu tenantu.
Nastavte Allowed CORS origins pro API koncové body, nikoliv pro aplikaci. Tenant Settings → Advanced → Allowed CORS origins. Výchozí stav je prázdný (omezený); přidávejte pouze explicitní origins, které vlastníte.

Tokeny a rotace refresh

Životnost tokenu, rotace refresh a podpisový algoritmus rozhodují o rozsahu škody jakéhokoliv úniku tokenu.

Povolte Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Každý refresh vydává nový refresh token a invaliduje starý. V kombinaci s absolutní expirací to omezuje krádeže tokenů.
Nastavte Refresh Token Reuse Interval na 0 (nebo na nejnižší hodnotu, kterou vaše tolerance přehrávání umožňuje). Interval znovupoužití umožňuje použít token dvakrát ve stejném okně — vypněte ho, pokud nemáte konkrétní důvod ho ponechat.
Nastavte Absolute Refresh Token Expiry na 14-30 dní, nikoliv na nekonečno. Application → Refresh Token Expiration → Absolute Expiration. Auth0 ve výchozím nastavení používá pouze Inactivity, což znamená, že nečinná relace může trvat roky.
Nastavte JWT Signature Algorithm na RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 používá asymetrické podepisování, takže klient nemůže padělat tokeny. Nikdy nepoužívejte HS256 pro aplikace orientované na klienta.
Na každém JWT, který vaše API přijímá, ověřte nároky aud a iss. Použijte oficiální Auth0 SDK na straně serveru — ověří je automaticky. Ručně psané JWT parsování obvykle přeskakuje validaci audience, což je obejití autentizace.

Akce a vlastní kód

Auth0 Actions (a starší Rules) běží na straně serveru při přihlášení a dalších životních událostech. Mají přístup k celému kontextu požadavku. Nezabezpečený kód zde je zranitelností pro celý tenant.

Nikdy nelogujte event.user nebo event.transaction jako celý objekt. Obsahují e-mailové adresy, IP adresy a další PII. Používejte pouze logování na úrovni polí a logujte pouze to, co potřebujete.
Pro jakýkoliv API klíč nebo webhook URL použijte úložiště tajemství. Actions → Edit → Secrets. Nikdy nevkládejte API klíč jako řetězec doslova do kódu akce — kód je viditelný komukoliv s přístupem k editoru Action na tenantu.
Validujte vstupy před jejich uložením jako user_metadata nebo app_metadata. Self-service akce, která zapisuje event.body.name do user.user_metadata.display_name, je vektorem uloženého XSS, pokud váš frontend toto pole renderuje bez escapování.

RBAC a resource servery

Pokud používáte Auth0 RBAC, mapování role-na-oprávnění je vaší autorizační vrstvou. Chybně to nastavte a jakýkoliv ověřený uživatel může zasáhnout admin koncové body.

Definujte Resource Servery (API) explicitně v Auth0 Dashboardu, ne na místě. Každé API má identifikátor (audience), scopes a nastavení podepisování. Bez registrovaného API jsou všechny tokeny vydávány pro implicitní "Auth0 Management API" — špatné publikum.
Nakonfigurujte oprávnění na API a vyžadujte je ve svém kódu pomocí nároku scope. Nekontrolujte členství v roli v logice aplikace; kontrolujte scopes v access tokenu. Scopes jsou OAuth-nativní autorizační mechanismus.
Otestujte, že ověřený uživatel bez požadované role / scope nemůže zasáhnout privilegované koncové body. Přihlaste se jako běžný uživatel, zkuste zavolat POST /api/admin/users/delete. Odpověď musí být 403.

Detekce anomálií a logy tenantu

Auth0 vysílá události s vysokým signálem. Nastavte je tak, aby alertovaly váš tým, ne aby jen ležely v log bufferu.

Povolte Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Každé je ve výchozím nastavení na bezplatných úrovních vypnuté; pro produkci je všechna zapněte.
Streamujte logy tenantu do SIEM nebo do logů vaší aplikace. Dashboard → Monitoring → Streams. Auth0 na většině tarifů uchovává logy po dobu 30 dnů; dlouhodobé uchovávání vyžaduje stream do vašeho vlastního systému.
Alertujte na špičky fcoa (neúspěšná cross-origin auth) a fp (neúspěšné přihlášení). Záplava těchto v krátkém okně je credential stuffing. Směrujte do svého on-call kanálu.

Další kroky

Spusťte FixVibe sken proti vaší produkční URL — kontrola baas.clerk-auth0 hlásí Auth0 client secrets v balíčku JavaScript a další třídy vystavení poskytovatele identity. Pro ekvivalent na Clerk viz Kontrolní seznam zabezpečení Clerk. Pro zastřešující pohled napříč poskytovateli BaaS si přečtěte Skener chybných konfigurací BaaS.