// docs / baas security / auth0 hardening

Lista kontrolna bezpieczeństwa Auth0: 22 elementy

Auth0 to platforma tożsamości jako usługa z ogromną powierzchnią — aplikacje, API (serwery zasobów), najemcy, akcje, reguły (stare), połączenia i granty. Błędna konfiguracja któregokolwiek z nich to obejście uwierzytelniania. Ta lista kontrolna to 22-elementowy audyt obejmujący aplikacje, listy dozwolonych callbacków / wylogowania, tokeny i rotację odświeżania, niestandardowe akcje, RBAC, wykrywanie anomalii i bieżące monitorowanie. Każdy element jest weryfikowalny w panelu Auth0 w mniej niż 10 minut.

Dla równoważnej listy kontrolnej w Clerk zobacz Lista kontrolna bezpieczeństwa Clerk. Dla tła, dlaczego błędne konfiguracje warstwy tożsamości są ślepymi punktami narzędzi AI, zobacz Dlaczego narzędzia kodowania AI pozostawiają luki w bezpieczeństwie.

Typ aplikacji i typy grantów

Typ aplikacji i włączone typy grantów to ustawienia o największym wpływie w Auth0. Pomylenie ich otwiera klasy ataków, których żadna ilość kodu frontendowego nie zamknie.

Użyj Typu aplikacji = Single Page Application dla aplikacji tylko w przeglądarce i Regular Web Application dla aplikacji renderowanych po stronie serwera. Niewłaściwy typ pozwala na niewłaściwe typy grantów — np. Regular Web App z grantem SPA umożliwia przepływ Implicit bez PKCE, który wycieka tokeny przez fragmenty URL.
Wyłącz typ grantu Implicit w każdej aplikacji. Panel → Application → Advanced Settings → Grant Types → odznacz Implicit. Przepływ Implicit zwraca tokeny w fragmentach URL, gdzie są logowane w historii przeglądarki i analityce. Użyj Authorization Code z PKCE zamiast tego.
Wyłącz grant Password, chyba że masz udokumentowaną potrzebę. Grant Resource Owner Password Credentials (ROPC) wymaga, abyś sam obsługiwał hasła użytkowników — pokonując większość tego, dla czego kupiłeś Auth0. Wyłącz go, chyba że integrujesz starszy system.
Włącz Authorization Code z PKCE w każdym kliencie publicznym. Panel → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = włączone. PKCE jest wymagane dla aplikacji mobilnych i SPA, aby zapobiec przechwyceniu kodu.

Listy dozwolonych callbacków i URL wylogowania

Otwarte przekierowania na ścieżce callbacka OAuth to prymityw kradzieży tokenów. Lista dozwolonych Auth0 to Twoja jedyna obrona.

Ustaw Allowed Callback URLs na dokładną produkcyjną ścieżkę callbacka — bez wieloznaczników. https://yourapp.com/callback, a nie https://yourapp.com/*. Wieloznaczne callbacki pozwalają atakującym przekierowywać tokeny do dowolnych podścieżek w Twojej domenie.
Ustaw Allowed Logout URLs na skończoną listę. Ta sama reguła: tylko jawne URL. Otwarte przekierowanie wylogowania pozwala atakującym tworzyć strony phishingowe, które wyglądają jak Twój stan po wylogowaniu.
Ustaw Allowed Web Origins tylko na Twoje produkcyjne pochodzenie. Używane do cichej autoryzacji (odnowienie tokenu przez ukryty iframe). Wieloznaczne pochodzenie pozwala stronom atakującego wykonywać cichą autoryzację wobec Twojego najemcy.
Ustaw Allowed CORS origins dla punktów końcowych API, a nie aplikacji. Tenant Settings → Advanced → Allowed CORS origins. Domyślnie pusta (ograniczona); dodawaj tylko jawne pochodzenia, które kontrolujesz.

Tokeny i rotacja odświeżania

Czas życia tokenu, rotacja odświeżania i algorytm podpisywania decydują o promieniu wybuchu każdego wycieku tokenu.

Włącz rotację tokenu odświeżania. Application → Refresh Token Settings → Rotation. Każde odświeżenie wystawia nowy token odświeżania i unieważnia stary. W połączeniu z absolutnym wygaśnięciem to powstrzymuje kradzież tokenów.
Ustaw Refresh Token Reuse Interval na 0 (lub tak nisko, jak pozwala Twoja tolerancja powtórki). Interwał ponownego użycia pozwala na użycie tokenu dwukrotnie w tym samym oknie — wyłącz to, chyba że masz konkretny powód, aby go zachować.
Ustaw Absolute Refresh Token Expiry na 14-30 dni, a nie nieskończoność. Application → Refresh Token Expiration → Absolute Expiration. Auth0 domyślnie używa tylko Inactivity, co oznacza, że bezczynna sesja może trwać latami.
Ustaw JWT Signature Algorithm na RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 używa podpisywania asymetrycznego, więc klient nie może sfałszować tokenów. Nigdy nie używaj HS256 dla aplikacji skierowanych do klienta.
Weryfikuj roszczenia aud i iss na każdym JWT, który otrzymuje Twoje API. Użyj oficjalnego Auth0 SDK po stronie serwera — weryfikuje je automatycznie. Ręczne parsowanie JWT zwykle pomija walidację odbiorcy, co jest obejściem uwierzytelniania.

Akcje i niestandardowy kod

Auth0 Actions (i starsze Rules) działają po stronie serwera przy logowaniu i innych zdarzeniach cyklu życia. Mają dostęp do całego kontekstu żądania. Niezabezpieczony kod tutaj to luka obejmująca całego najemcę.

Nigdy nie loguj event.user ani event.transaction jako całego obiektu. Zawierają adresy e-mail, adresy IP i inne PII. Używaj tylko logowania na poziomie pól i loguj tylko to, czego potrzebujesz.
Użyj magazynu sekretów dla każdego klucza API lub URL webhooka. Actions → Edit → Secrets. Nigdy nie wstawiaj inline klucza API jako literału ciągu w kodzie akcji — kod jest widoczny dla każdego z dostępem do edytora akcji w najemcy.
Waliduj dane wejściowe przed utrwaleniem ich jako user_metadata lub app_metadata. Akcja samoobsługowa, która zapisuje event.body.name do user.user_metadata.display_name, jest wektorem stored-XSS, jeśli Twój frontend renderuje to pole bez ekranowania.

RBAC i serwery zasobów

Jeśli używasz Auth0 RBAC, mapowanie roli na uprawnienia to Twoja warstwa autoryzacji. Pomyl to, a każdy uwierzytelniony użytkownik może trafić na punkty końcowe administratora.

Definiuj serwery zasobów (API) jawnie w panelu Auth0, a nie w locie. Każde API ma identyfikator (audience), zakresy i ustawienia podpisywania. Bez zarejestrowanego API wszystkie tokeny są wystawiane dla domyślnego „Auth0 Management API" — niewłaściwa publiczność.
Skonfiguruj Uprawnienia na API i wymagaj ich w swoim kodzie z roszczeniem scope. Nie sprawdzaj członkostwa w roli w logice aplikacji; sprawdzaj zakresy w tokenie dostępu. Zakresy to natywny mechanizm autoryzacji OAuth.
Przetestuj, że uwierzytelniony użytkownik bez wymaganej roli / zakresu nie może trafić na uprzywilejowane punkty końcowe. Zaloguj się jako zwykły użytkownik, spróbuj wywołać POST /api/admin/users/delete. Odpowiedź musi być 403.

Wykrywanie anomalii i dzienniki najemcy

Auth0 emituje zdarzenia o wysokim sygnale. Ustaw je, aby alarmowały Twój zespół, a nie tylko siedziały w buforze dziennika.

Włącz Ochronę przed atakami: Bot Detection, Brute Force, Suspicious IP Throttling. Panel → Security → Attack Protection. Każda jest domyślnie wyłączona na bezpłatnych poziomach; włącz je wszystkie dla produkcji.
Streamuj dzienniki najemcy do SIEM lub dzienników aplikacji. Panel → Monitoring → Streams. Auth0 zachowuje dzienniki przez 30 dni na większości planów; długoterminowe zachowanie wymaga strumienia do Twojego własnego systemu.
Alarmuj przy szczytach fcoa (nieudane uwierzytelnianie międzypochodzeniowe) i fp (nieudane logowanie). Wybuch tych w krótkim oknie to credential stuffing. Kieruj do swojego kanału on-call.

Następne kroki

Uruchom skanowanie FixVibe wobec swojego produkcyjnego URL — kontrola baas.clerk-auth0 flaguje sekrety klienta Auth0 spakowane w JavaScript i inne klasy ujawniania dostawcy tożsamości. Dla równoważnika w Clerk zobacz Lista kontrolna bezpieczeństwa Clerk. Dla widoku parasolowego obejmującego dostawców BaaS przeczytaj Skaner błędnych konfiguracji BaaS.