// docs / baas security / auth0 hardening
Kontrolný zoznam zabezpečenia Auth0: 22 položiek
Auth0 je identity-as-a-service platforma s obrovským povrchom — aplikácie, API (resource servery), tenanti, akcie, pravidlá (legacy), spojenia a granty. Chybná konfigurácia ktoréhokoľvek z nich je obídenie autentizácie. Tento kontrolný zoznam je 22-položkový audit naprieč aplikáciami, zoznamami povolených callback / logout, tokenmi a rotáciou refresh, vlastnými akciami, RBAC, detekciou anomálií a priebežným monitorovaním. Každú položku možno overiť v Auth0 Dashboarde za menej než 10 minút.
Pre ekvivalentný kontrolný zoznam na Clerk si pozrite Kontrolný zoznam zabezpečenia Clerk. Pre kontext, prečo sú chybné konfigurácie vrstvy identity slepými miestami AI nástrojov, si pozrite Prečo nástroje na kódovanie s AI zanechávajú bezpečnostné medzery.
Typ aplikácie a typy grantov
Typ aplikácie a zapnuté typy grantov sú nastavenia s najvyšším dopadom v Auth0. Ich zlé nastavenie otvára triedy útokov, ktoré žiadne množstvo frontend kódu neuzavrie.
- Použite Application Type = Single Page Application pre aplikácie iba v prehliadači a Regular Web Application pre aplikácie vykresľované na strane servera. Zlý typ povoľuje zlé typy grantov — napr. Regular Web App s SPA grantom umožňuje Implicit flow bez PKCE, ktorý nechá uniknúť tokeny cez URL fragmenty.
- Vypnite typ grantu Implicit na každej aplikácii. Dashboard → Application → Advanced Settings → Grant Types → odškrtnite Implicit. Implicit flow vracia tokeny v URL fragmentoch, kde sú logované v histórii prehliadača a analytike. Použite Authorization Code s PKCE namiesto toho.
- Vypnite Password grant, pokiaľ nemáte zdokumentovanú potrebu. Resource Owner Password Credentials (ROPC) grant vyžaduje, aby ste sami spravovali heslá používateľov — porážka väčšiny toho, prečo ste si kúpili Auth0. Vypnite ho, pokiaľ neintegrujete legacy systém.
- Zapnite Authorization Code s PKCE na každom verejnom klientovi. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = zapnuté. PKCE je vyžadované pre mobilné aplikácie a SPA na zabránenie zachyteniu kódu.
Zoznamy povolených callback a logout URL
Otvorené presmerovania na OAuth callback ceste sú primitívom krádeže tokenov. Auth0 zoznam povolených je vaša jediná obrana.
- Nastavte Allowed Callback URLs na presnú produkčnú callback cestu — žiadne žolíky.
https://yourapp.com/callback, niehttps://yourapp.com/*. Žolíkové callbacky umožňujú útočníkom presmerovať tokeny na ľubovoľné podcesty na vašej doméne. - Nastavte Allowed Logout URLs na konečný zoznam. Rovnaké pravidlo: iba explicitné URL. Otvorené logout presmerovanie umožňuje útočníkom vytvárať phishing stránky, ktoré vyzerajú ako váš stav po odhlásení.
- Nastavte Allowed Web Origins iba na vašu produkčnú origin. Používa sa pre tichú autentizáciu (obnovenie tokenu cez skrytý iframe). Žolíková origin umožňuje útočníckym stránkam vykonávať tichú autentizáciu proti vášmu tenantovi.
- Nastavte Allowed CORS origins pre API koncové body, nie pre aplikáciu. Tenant Settings → Advanced → Allowed CORS origins. Predvolené je prázdne (obmedzené); pridajte iba explicitné originy, ktoré ovládate.
Tokeny a rotácia refresh
Doba života tokenu, rotácia refresh a podpisový algoritmus rozhodujú o radiu výbuchu akéhokoľvek úniku tokenu.
- Zapnite Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Každé obnovenie vydáva nový refresh token a zneplatňuje starý. V kombinácii s absolútnym vypršaním to obmedzuje krádež tokenov.
- Nastavte Refresh Token Reuse Interval na 0 (alebo tak nízko, ako vám vaša tolerancia replay umožňuje). Reuse interval umožňuje použiť token dvakrát v rovnakom okne — vypnite ho, pokiaľ nemáte konkrétny dôvod ho ponechať.
- Nastavte Absolute Refresh Token Expiry na 14-30 dní, nie nekonečno. Application → Refresh Token Expiration → Absolute Expiration. Auth0 predvolene používa iba Inactivity, čo znamená, že nečinná relácia môže pretrvávať roky.
- Nastavte JWT Signature Algorithm na RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 používa asymetrický podpis, takže klient nemôže podvrhnúť tokeny. Nikdy nepoužívajte HS256 pre aplikácie zamerané na klienta.
- Overujte nároky
audaissna každom JWT, ktoré vaše API prijme. Použite oficiálne Auth0 SDK na strane servera — overuje ich automaticky. Ručne písané parsovanie JWT zvyčajne preskakuje validáciu audience, čo je obídenie autentizácie.
Akcie a vlastný kód
Auth0 Actions (a legacy Rules) bežia na strane servera pri prihlasovaní a iných udalostiach životného cyklu. Majú prístup k celému kontextu požiadavky. Nezabezpečený kód tu je tenant-široká zraniteľnosť.
- Nikdy nelogujte
event.useraleboevent.transactionako celý objekt. Tieto obsahujú emailové adresy, IP adresy a ďalšie PII. Používajte iba field-level logovanie a logujte iba to, čo potrebujete. - Použite secrets store pre akýkoľvek API kľúč alebo webhook URL. Actions → Edit → Secrets. Nikdy neinlineujte API kľúč ako string literal v kóde akcie — kód je viditeľný komukoľvek s prístupom k editoru akcií v tenantovi.
- Validujte vstupy pred ich uložením ako user_metadata alebo app_metadata. Akcia samoobsluhy, ktorá zapisuje
event.body.namedouser.user_metadata.display_name, je vektor stored-XSS, ak váš frontend vykresľuje toto pole bez escapovania.
RBAC a resource servery
Ak používate Auth0 RBAC, mapovanie rolí na oprávnenia je vaša autorizačná vrstva. Ak to nastavíte zle, akýkoľvek overený používateľ môže zasiahnuť administrátorské koncové body.
- Definujte Resource Servers (APIs) explicitne v Auth0 Dashboarde, nie za chodu. Každé API má identifikátor (
audience), scopes a nastavenia podpisovania. Bez registrovaného API sú všetky tokeny vydávané pre implicitné „Auth0 Management API" — nesprávny audience. - Nakonfigurujte Permissions na API a vyžadujte ich vo svojom kóde s nárokom
scope. Nekontrolujte členstvo v role v logike vašej aplikácie; kontrolujte scopes v access tokene. Scopes sú OAuth-natívny autorizačný mechanizmus. - Otestujte, že overený používateľ bez požadovanej role / scope nemôže zasiahnuť privilegované koncové body. Prihláste sa ako bežný používateľ, skúste zavolať
POST /api/admin/users/delete. Odpoveď musí byť403.
Detekcia anomálií a tenant logy
Auth0 emituje udalosti s vysokým signálom. Nastavte ich tak, aby upozorňovali váš tím, nielen sedeli v logovacom buffri.
- Zapnite Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Každé je predvolene vypnuté na bezplatných tarifoch; zapnite ich všetky pre produkciu.
- Streamujte tenant logy do SIEM alebo do logov vašej aplikácie. Dashboard → Monitoring → Streams. Auth0 uchováva logy 30 dní vo väčšine plánov; dlhodobé uchovávanie vyžaduje stream do vášho vlastného systému.
- Upozorňujte na skoky
fcoa(failed cross-origin auth) afp(failed login). Návalek týchto v krátkom okne je credential stuffing. Smerujte to do vášho on-call kanála.
Ďalšie kroky
Spustite sken FixVibe proti vašej produkčnej URL — kontrola baas.clerk-auth0 označuje Auth0 client secrets zbalené v JavaScripte a ďalšie triedy odhalenia poskytovateľa identity. Pre ekvivalent na Clerk si pozrite Kontrolný zoznam zabezpečenia Clerk. Pre zastrešujúci pohľad naprieč BaaS poskytovateľmi si prečítajte Skener chybnej konfigurácie BaaS.