// docs / baas security / auth0 hardening

Auth0 turvalisuse kontrollnimekiri: 22 punkti

Auth0 on identity-as-a-service platvorm tohutu pinnaga — rakendused, API-d (ressursiserverid), rentnikud, toimingud, reeglid (vana), ühendused ja grant'id. Ühegi neist väärseadistus on auth-möödaminek. See kontrollnimekiri on 22-punktiline audit rakenduste, callback / logout allowlistide, tokenite ja refresh-pööramise, kohandatud toimingute, RBAC-i, anomaalia tuvastamise ja pideva jälgimise kohta. Iga punkt on kontrollitav Auth0 Dashboardis vähem kui 10 minutiga.

Clerki paralleelse kontrollnimekirja jaoks vaata Clerki turvalisuse kontrollnimekiri. Tausta saamiseks selle kohta, miks identiteedi-kihi väärseadistused on AI-tööriistade pimedad nurgad, vaata Miks AI-koodimistööriistad jätavad turvaaugud.

Rakenduse tüüp ja grant-tüübid

Rakenduse tüüp ja lubatud grant-tüübid on Auth0 kõige mõjusamad seaded. Need valesti seades avab klassi rünnakuid, mida ükski hulk esirakenduse koodi ei sulge.

Kasuta Application Type = Single Page Application ainult-brauseri rakendustele ja Regular Web Application server-renderdatud rakendustele. Vale tüüp lubab valed grant-tüübid — nt Regular Web App, kus SPA grant on lubatud, võimaldab PKCE-vaba Implicit voogu, mis lekib tokeneid URL-i fragmentide kaudu.
Keela Implicit grant-tüüp igal rakendusel. Dashboard → Application → Advanced Settings → Grant Types → eemalda märk Implicit-il. Implicit voog tagastab tokenid URL-i fragmentides, kus neid logitakse brauseri ajalukku ja analüütikasse. Kasuta selle asemel Authorization Code with PKCE.
Keela Password grant, kui sul pole dokumenteeritud vajadust. Resource Owner Password Credentials (ROPC) grant nõuab, et sa käsitleksid kasutaja paroole ise — võites enamiku sellest, milleks Auth0 ostsid. Keela see, kui sa ei integreeri vana süsteemi.
Luba Authorization Code with PKCE igal avalikul kliendil. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = lubatud. PKCE on mobiilirakendustele ja SPA-dele nõutav, et vältida koodi pealtkuulamist.

Callback ja logout URL-i allowlistid

Avatud ümbersuunamised OAuth callback-raja peal on tokenivarguse primitiiv. Auth0 allowlist on sinu ainus kaitse.

Sea Allowed Callback URLs oma täpsele tootmise callback-rajale — ilma metasümboliteta. https://yourapp.com/callback, mitte https://yourapp.com/*. Metasümboli callback'id lubavad ründajatel suunata tokeneid sinu domeenil suvalistele alaradadele.
Sea Allowed Logout URLs piiratud nimekirjale. Sama reegel: ainult selgesõnalised URL-id. Avatud logout-ümbersuunamine lubab ründajatel meisterdada phishing-lehti, mis näevad välja nagu sinu post-logout-olek.
Sea Allowed Web Origins ainult oma tootmise originale. Kasutatakse silent-autentimiseks (tokeni uuendamine peidetud iframe'i kaudu). Metasümboli origin lubab ründaja lehtedel teha vaikne autentimine sinu rentniku vastu.
Sea Allowed CORS origins API otspunktide jaoks, mitte rakenduse jaoks. Tenant Settings → Advanced → Allowed CORS origins. Vaikeväärtus on tühi (piiratud); lisa ainult selgesõnalised originid, mida kontrollid.

Tokenid ja refresh-pööramine

Tokeni eluiga, refresh-pööramine ja allkirjastamise algoritm otsustavad mis tahes tokeni lekke plahvatusraadiuse.

Luba Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Iga refresh väljastab uue refresh-tokeni ja muudab vana kehtetuks. Koos absoluutse aegumisega see ohjeldab tokenivargust.
Sea Refresh Token Reuse Interval = 0 (või nii madalaks, kui sinu kordumistolerants lubab). Taaskasutuse intervall lubab tokenit kasutada samas aknas kaks korda — keela see välja, kui sul pole konkreetset põhjust seda hoida.
Sea Absolute Refresh Token Expiry 14–30 päevaks, mitte lõpmatuseks. Application → Refresh Token Expiration → Absolute Expiration. Auth0 vaikeväärtus on ainult Inactivity, mis tähendab, et jõudeolev seanss võib aastaid püsida.
Sea JWT Signature Algorithm = RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 kasutab asümmeetrilist allkirjastamist, nii et klient ei saa tokeneid võltsida. Ära kunagi kasuta klient-suunatud rakenduste jaoks HS256.
Kontrolli aud- ja iss-väiteid igal JWT-l, mille sinu API saab. Kasuta serveripoolel ametlikku Auth0 SDK-d — see kontrollib need automaatselt. Käsitsi tehtud JWT-parser jätab tavaliselt audiens'i valideerimise vahele, mis on auth-möödaminek.

Toimingud ja kohandatud kood

Auth0 Actions (ja vana Rules) jooksevad serveripoolel sisselogimisel ja teistel elutsükli sündmustel. Neil on juurdepääs kogu päringu kontekstile. Ebaturvaline kood siin on rentniku-ülene haavatavus.

Ära kunagi logi event.user või event.transaction tervet objekti. Need sisaldavad e-posti aadresse, IP-aadresse ja muud PII-d. Kasuta ainult välja-tasandi logimist ja logi ainult seda, mida vajad.
Kasuta saladuste salve iga API-võtme või webhooki-URL-i jaoks. Actions → Edit → Secrets. Ära kunagi pane API-võtit stringi literaalina toimingu koodi sisse — kood on nähtav kõigile, kellel on rentnikul Action editor'i juurdepääs.
Valideeri sisendid enne nende salvestamist user_metadata või app_metadata-na. Iseteeninduse toiming, mis kirjutab event.body.name väärtuse user.user_metadata.display_name-isse, on salvestatud-XSS-vektor, kui sinu esirakendus seda välja ilma põgenemata renderdab.

RBAC ja ressursiserverid

Kui kasutad Auth0 RBAC-i, on rolli-õiguste vastendus sinu volituste-kiht. Selle vale seadmise korral saab iga autenditud kasutaja administraatori otspunktidesse.

Määratle ressursiserverid (API-d) Auth0 Dashboardis selgesõnaliselt, mitte käigult. Igal API-l on identifikaator (audience), skoobid ja allkirjastamise seaded. Ilma registreeritud API-ta väljastatakse kõik tokenid kaudse "Auth0 Management API" jaoks — vale audiens.
Seadista õigused API kohta ja nõua neid oma koodis scope-väitega. Ära kontrolli rolli kuuluvust rakenduse loogikas; kontrolli juurdepääsutokeni skoope. Skoobid on OAuthi-loomulik volitusmehhanism.
Testi, et autenditud kasutaja ilma nõutava rolli / skoobita ei jõua privilegeeritud otspunktidesse. Logi sisse tavakasutajana, proovi kutsuda POST /api/admin/users/delete. Vastus peab olema 403.

Anomaalia tuvastamine ja rentniku logid

Auth0 väljastab kõrge-signaali sündmusi. Seadista nad sinu meeskonda hoiatama, mitte ainult logipuhvris istuma.

Luba Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Igaüks on tasuta tasemetel vaikimisi väljas; lülita tootmises kõik sisse.
Stream'i rentniku logid SIEM-i või oma rakenduse logidesse. Dashboard → Monitoring → Streams. Auth0 säilitab logid 30 päeva enamikul plaanidel; pikaajaline säilitamine nõuab stream'i sinu enda süsteemi.
Saada hoiatusi fcoa (ebaõnnestunud risti-origin'i auth) ja fp (ebaõnnestunud sisselogimine) hüpete kohta. Lühikese aknaga selliste sündmuste plahvatus on credential-stuffing. Suuna oma valveskanalisse.

Järgmised sammud

Käivita FixVibe-skannimine oma tootmise URL-i vastu — kontroll baas.clerk-auth0 märgib paki sisse jätkatud Auth0 kliendi-saladusi ja muid identiteedi-pakkuja paljastuse klasse. Clerki paralleeli jaoks vaata Clerki turvalisuse kontrollnimekiri. Üldpildi saamiseks BaaS-pakkujate üle, loe BaaS väärseadistuse skanner.