// docs / baas security / auth0 hardening

Auth0-tietoturvatarkistuslista: 22 kohtaa

Auth0 on identity-as-a-service-alusta, jolla on valtava pinta — sovellukset, API:t (resurssipalvelimet), tenantit, actionit, säännöt (vanhat), yhteydet ja grantit. Minkä tahansa virhekonfigurointi on auth-ohitus. Tämä tarkistuslista on 22-kohdan tarkastus sovellusten, callback-/uloskirjautumis-allowlistien, tokenien ja refresh-rotaation, mukautettujen actioneiden, RBAC:n, anomaliahavaitsemisen ja jatkuvan valvonnan yli. Jokainen kohta on verifioitavissa Auth0-dashboardissa alle 10 minuutissa.

Vastaavaan tarkistuslistaan Clerkille katso Clerk-tietoturvatarkistuslista. Taustaksi siitä, miksi identiteettikerroksen virhekonfiguraatiot ovat AI-työkalujen sokeita pisteitä, katso Miksi AI-koodaustyökalut jättävät tietoturva-aukkoja.

Sovellustyyppi ja grant-tyypit

Sovellustyyppi ja käytössä olevat grant-tyypit ovat Auth0:n korkeimman vaikutuksen asetuksia. Niiden virheellinen valinta avaa hyökkäysluokkia, joita mikään määrä frontend-koodia ei sulje.

Käytä Application Type = Single Page Application vain selaimessa toimiville sovelluksille ja Regular Web Application palvelinpuolella renderöityville sovelluksille. Väärä tyyppi sallii väärät grant-tyypit — esim. Regular Web App SPA-grantilla mahdollistaa PKCE-tukemattoman Implicit flow:n, joka vuotaa tokeneja URL-fragmenttien kautta.
Poista Implicit grant -tyyppi käytöstä jokaisessa sovelluksessa. Dashboard → Application → Advanced Settings → Grant Types → poista Implicit-merkintä. Implicit flow palauttaa tokenit URL-fragmenteissa, joissa ne lokitetaan selainhistoriaan ja analytiikkaan. Käytä Authorization Code with PKCE -toimintoa sen sijaan.
Poista Password grant käytöstä, ellei sinulla ole dokumentoitua tarvetta. Resource Owner Password Credentials (ROPC) -grant vaatii sinua käsittelemään käyttäjäsalasanoja itse — kumoten suurimman osan siitä, mitä ostit Auth0:lta. Poista se käytöstä, ellet integroi vanhaa järjestelmää.
Ota Authorization Code with PKCE käyttöön jokaisessa julkisessa klientissä. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = käytössä. PKCE vaaditaan mobiilisovelluksille ja SPA:ille koodin sieppausen estämiseksi.

Callback- ja uloskirjautumis-URL-allowlistit

Avoimet uudelleenohjaukset OAuth-callback-polulla ovat tokenin-varastamis-primitiivi. Auth0:n allowlist on ainoa puolustuksesi.

Aseta Allowed Callback URLs tarkkaan tuotantokuvauspolkuusi — ei wildcardeja. https://yourapp.com/callback, ei https://yourapp.com/*. Wildcard-callbackit antavat hyökkääjien uudelleenohjata tokeneita mielivaltaisiin alipolkuihin domainissasi.
Aseta Allowed Logout URLs rajalliseen listaan. Sama sääntö: vain eksplisiittiset URL:t. Avoin uloskirjautumisuudelleenohjaus antaa hyökkääjien laatia tietojenkalastelusivuja, jotka näyttävät uloskirjautumisen jälkeiseltä tilaltasi.
Aseta Allowed Web Origins vain tuotanto-originiisi. Käytetään hiljaiseen autentikointiin (tokenin uusiminen piilotetun iframen kautta). Wildcard-origin antaa hyökkääjäsivujen suorittaa hiljaista autentikointia tenanttiasi vastaan.
Aseta Allowed CORS origins API-päätepisteille, ei sovellukselle. Tenant Settings → Advanced → Allowed CORS origins. Oletus on tyhjä (rajoitettu); lisää vain eksplisiittiset originit, joita hallitset.

Tokenit ja refresh-rotaatio

Tokenin elinaika, refresh-rotaatio ja allekirjoitusalgoritmi päättävät minkä tahansa token-vuodon räjähdyssäteen.

Ota Refresh Token Rotation käyttöön. Application → Refresh Token Settings → Rotation. Jokainen refresh myöntää uuden refresh-tokenin ja mitätöi vanhan. Yhdistettynä absoluuttisen vanhentumisajan kanssa tämä rajoittaa tokenien varastamista.
Aseta Refresh Token Reuse Interval arvoon 0 (tai niin alas kuin toistosietokykysi sallii). Uudelleenkäyttö-intervalli sallii tokenin käyttämisen kahdesti samassa ikkunassa — kytke se pois päältä, ellei sinulla ole erityistä syytä pitää sitä.
Aseta Absolute Refresh Token Expiry 14–30 päivään, ei äärettömään. Application → Refresh Token Expiration → Absolute Expiration. Auth0:n oletus on vain Inactivity, mikä tarkoittaa, että jouten oleva sessio voi säilyä vuosia.
Aseta JWT Signature Algorithm RS256:ksi. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 käyttää epäsymmetristä allekirjoitusta, joten klientti ei voi väärentää tokeneja. Älä koskaan käytä HS256:ta klientille suunnatuissa sovelluksissa.
Verifioi aud- ja iss-claimit jokaisesta API:si vastaanottamasta JWT:stä. Käytä virallista Auth0-SDK:ta palvelinpuolella — se verifioi nämä automaattisesti. Käsin tehty JWT-jäsennys jättää yleensä yleisön validoinnin pois, mikä on auth-ohitus.

Actionit ja mukautettu koodi

Auth0 Actions (ja vanhat Säännöt) ajetaan palvelinpuolella sisäänkirjautumisessa ja muissa elinkaaritapahtumissa. Niillä on pääsy koko pyyntökontekstiin. Turvaton koodi tässä on tenant-laajuinen haavoittuvuus.

Älä koskaan lokita event.user:ia tai event.transaction:ia kokonaisena objektina. Nämä sisältävät sähköpostiosoitteita, IP-osoitteita ja muuta PII:tä. Käytä vain kenttätason lokitusta ja lokita vain se, mitä tarvitset.
Käytä secrets-varastoa minkä tahansa API-avaimen tai webhook-URL:n osalta. Actions → Edit → Secrets. Älä koskaan inlinaa API-avainta merkkijonokirjaimena action-koodissa — koodi on näkyvissä kenelle tahansa, jolla on Action-editor-pääsy tenanttiin.
Validoi syötteet ennen niiden tallentamista user_metadata:na tai app_metadata:na. Itsepalvelu-action, joka kirjoittaa event.body.name:n kohtaan user.user_metadata.display_name, on tallennetun-XSS-vektori, jos frontendisi renderöi tuon kentän ilman escapettämistä.

RBAC ja resurssipalvelimet

Jos käytät Auth0 RBAC:ia, rooli-oikeus-kuvaus on autorisaatiokerroksesi. Tee se väärin, ja kuka tahansa autentikoitu käyttäjä voi osua hallintapäätepisteisiin.

Määritä Resource Servers (API:t) eksplisiittisesti Auth0-dashboardissa, ei lennossa. Jokaisella API:lla on tunniste (audience), scope-arvot ja allekirjoitusasetukset. Ilman rekisteröityä API:a kaikki tokenit myönnetään implisiittiselle "Auth0 Management API":lle — väärä yleisö.
Konfiguroi Permissions API:ta kohti ja vaadi niitä koodissasi scope-claimilla. Älä tarkista roolijäsenyyttä sovelluslogiikassasi; tarkista scope-arvot access-tokenissa. Scope-arvot ovat OAuth-natiivi autorisaatiomekanismi.
Testaa, että autentikoitu käyttäjä ilman vaadittua roolia/scope-arvoa ei voi osua etuoikeutettuihin päätepisteisiin. Kirjaudu sisään tavallisena käyttäjänä, yritä kutsua POST /api/admin/users/delete. Vastauksen täytyy olla 403.

Anomaliahavaitseminen ja tenant-lokit

Auth0 lähettää korkean signaalin tapahtumia. Aseta ne hälyttämään tiimisi, älä vain istumaan lokipuskurissa.

Ota Attack Protection käyttöön: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Jokainen on oletuksena pois päältä ilmaistasoilla; ota ne kaikki käyttöön tuotantoa varten.
Suoratoista tenant-lokit SIEMiin tai sovelluslokeihisi. Dashboard → Monitoring → Streams. Auth0 säilyttää lokit useimmissa suunnitelmissa 30 päivää; pitkäaikainen säilytys vaatii streamin omaan järjestelmääsi.
Hälytä fcoa:n (epäonnistunut cross-origin-auth) ja fp:n (epäonnistunut sisäänkirjautuminen) piikeistä. Näiden purkaus lyhyessä ikkunassa on credential stuffing. Reititä päivystyskanavallesi.

Seuraavat askeleet

Aja FixVibe-skannaus tuotanto-URL:ääsi vastaan — baas.clerk-auth0-tarkistus lippuu JavaScriptiin paketoidut Auth0-klientti-secretit ja muut identiteetin tarjoajan paljastusluokat. Vastaavaan Clerkille katso Clerk-tietoturvatarkistuslista. Kokonaisnäkymää varten BaaS-tarjoajien yli lue BaaS-virhekonfiguraatioskanneri.