// docs / baas security / auth0 hardening
Контролен списък за сигурност на Auth0: 22 точки
Auth0 е identity-as-a-service платформа с огромна повърхност — applications, APIs (resource servers), tenants, actions, rules (legacy), connections и grants. Неправилна конфигурация на който и да е от тях е заобикаляне на автентикацията. Този контролен списък е одит от 22 точки в приложения, callback / logout allowlists, токени и refresh ротация, custom actions, RBAC, откриване на аномалии и текущ мониторинг. Всяка точка е проверима в Auth0 Dashboard за по-малко от 10 минути.
За еквивалентния контролен списък на Clerk, вижте Контролен списък за сигурност на Clerk. За фон относно това защо неправилните конфигурации на identity слоя са слепи петна на AI инструменти, вижте Защо AI инструментите за кодиране оставят пропуски в сигурността.
Тип на приложение и типове grant
Типът на приложението и активираните типове grant са настройките с най-голямо въздействие в Auth0. Грешата им отваря класове атаки, които никаква frontend код не може да затвори.
- Използвайте Application Type = Single Page Application за приложения само за браузър и Regular Web Application за server-rendered приложения. Грешният тип позволява грешните типове grant — напр. Regular Web App с SPA grant активира PKCE-less Implicit flow, който изтича токени чрез URL фрагменти.
- Деактивирайте Implicit grant type на всяко приложение. Dashboard → Application → Advanced Settings → Grant Types → демаркирайте Implicit. Implicit flow връща токени в URL фрагменти, където се логват в историята на браузъра и анализите. Използвайте Authorization Code с PKCE вместо това.
- Деактивирайте Password grant, освен ако нямате документирана нужда. Resource Owner Password Credentials (ROPC) grant изисква вие сами да обработвате потребителските пароли — побеждава повечето от това, за което сте купили Auth0. Деактивирайте го, освен ако не интегрирате наследена система.
- Активирайте Authorization Code с PKCE на всеки публичен клиент. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = enabled. PKCE се изисква за мобилни приложения и SPAs, за да се предотврати code interception.
Callback и logout URL allowlists
Open redirects на OAuth callback пътя са примитив за кражба на токен. Allowlist на Auth0 е единствената ви защита.
- Задайте Allowed Callback URLs на вашия точен production callback път — без wildcards.
https://yourapp.com/callback, а неhttps://yourapp.com/*. Wildcard callbacks позволяват на нападателите да пренасочат токени към произволни subpaths на вашия домейн. - Задайте Allowed Logout URLs на краен списък. Същото правило: само явни URL. Open logout redirect позволява на нападателите да изработят phishing страници, които изглеждат като вашето post-logout състояние.
- Задайте Allowed Web Origins само на вашия production origin. Използва се за silent authentication (обновяване на токен чрез скрит iframe). Wildcard origin позволява на страниците на нападател да извършват silent auth срещу вашия tenant.
- Задайте Allowed CORS origins за API endpoints, не за приложението. Tenant Settings → Advanced → Allowed CORS origins. По подразбиране е празно (ограничено); добавяйте само явни origin-и, които контролирате.
Токени и refresh ротация
Времето на живот на токена, refresh ротация и алгоритъмът за подписване определят радиуса на взрив при всяко изтичане на токен.
- Активирайте Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Всеки refresh издава нов refresh token и анулира стария. Комбиниран с абсолютен срок, това ограничава кражбата на токени.
- Задайте Refresh Token Reuse Interval на 0 (или толкова ниско, колкото позволява вашата толерантност към replay). Reuse interval позволява токен да се използва два пъти в същия прозорец — изключете го, освен ако нямате конкретна причина да го запазите.
- Задайте Absolute Refresh Token Expiry на 14-30 дни, не безкрайност. Application → Refresh Token Expiration → Absolute Expiration. Auth0 по подразбиране е само на Inactivity, което означава, че неактивна сесия може да продължи години.
- Задайте JWT Signature Algorithm на RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 използва асиметрично подписване, така че клиентът не може да фалшифицира токени. Никога не използвайте HS256 за приложения, насочени към клиенти.
- Проверявайте claims
audиissна всеки JWT, който вашето API получава. Използвайте официалния Auth0 SDK на сървърната страна — той ги проверява автоматично. Hand-rolled JWT парсването обикновено пропуска валидиране на audience, което е заобикаляне на автентикацията.
Actions и custom code
Actions на Auth0 (и legacy Rules) се изпълняват на сървъра при влизане и други събития от жизнения цикъл. Те имат достъп до целия контекст на заявката. Несигурният код тук е tenant-wide уязвимост.
- Никога не логвайте
event.userилиevent.transactionкато цял обект. Те съдържат имейл адреси, IP адреси и друг PII. Използвайте само логване на ниво поле и логвайте само това, което ви трябва. - Използвайте secrets store за всеки API ключ или webhook URL. Actions → Edit → Secrets. Никога не inline-вайте API ключ като низов литерал в кода на action — кодът е видим за всеки с достъп до редактора на Actions в tenant.
- Валидирайте входовете, преди да ги запазвате като user_metadata или app_metadata. Self-service action, който записва
event.body.nameвuser.user_metadata.display_name, е stored-XSS вектор, ако вашият frontend рендира това поле без escaping.
RBAC и resource servers
Ако използвате Auth0 RBAC, mapping-ът роля-към-разрешение е вашият authorization слой. Грешка в него и всеки автентикиран потребител може да удари admin endpoints.
- Дефинирайте Resource Servers (APIs) явно в Auth0 Dashboard, а не в движение. Всеки API има идентификатор (
audience), scopes и настройки за подписване. Без регистриран API, всички токени се издават за имплицитния "Auth0 Management API" — грешен audience. - Конфигурирайте Permissions за API и ги изисквайте в кода си с
scopeclaim. Не проверявайте членство в роля в логиката на приложението ви; проверявайте scopes в access токена. Scopes са OAuth-нативният механизъм за оторизация. - Тествайте, че автентикиран потребител без необходимата роля / scope не може да удари привилегировани endpoints. Влезте като обикновен потребител, опитайте да извикате
POST /api/admin/users/delete. Отговорът трябва да бъде403.
Откриване на аномалии и tenant логове
Auth0 излъчва събития с висок сигнал. Настройте ги да алармират екипа ви, а не само да седят в буфер на логовете.
- Активирайте Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Всяко е изключено по подразбиране на безплатните планове; включете ги всички за продукция.
- Стриймвайте tenant логовете към SIEM или вашите application логове. Dashboard → Monitoring → Streams. Auth0 запазва логовете за 30 дни на повечето планове; дългосрочно задържане изисква поток в собствената ви система.
- Алармирайте при скокове на
fcoa(failed cross-origin auth) иfp(failed login). Изблик от тях в кратък прозорец е credential stuffing. Маршрутизирайте към канал за on-call.
Следващи стъпки
Изпълнете FixVibe сканиране срещу production URL — проверката baas.clerk-auth0 маркира Auth0 client secrets, bundled в JavaScript, и други класове излагане на доставчик на идентичност. За еквивалента на Clerk, вижте Контролен списък за сигурност на Clerk. За общ преглед на BaaS доставчиците, прочетете Скенер за неправилни конфигурации на BaaS.