// docs / baas security / auth0 hardening

Чек-лист безпеки Auth0: 22 пункти

Auth0 — це платформа ідентичності як сервісу з величезною поверхнею — applications, APIs (resource servers), tenants, actions, rules (застарілі), connections та grants. Неправильне налаштування будь-якого з них — це обхід автентифікації. Цей чек-лист — це 22-пунктний аудит за applications, allowlist callback / logout, токенами та ротацією refresh, custom actions, RBAC, виявленням аномалій та поточним моніторингом. Кожен пункт можна перевірити на Панелі Auth0 менш ніж за 10 хвилин.

Для еквівалентного чек-листа щодо Clerk дивіться Чек-лист безпеки Clerk. Для розуміння, чому неправильні налаштування identity-шару є сліпою плямою ШІ-інструментів, дивіться Чому ШІ-інструменти кодування залишають прогалини в безпеці.

Тип застосунку та типи grants

Тип застосунку та увімкнені типи grants — це налаштування з найвищим впливом в Auth0. Неправильні значення відкривають класи атак, які жоден фронтенд-код не закриє.

Використовуйте Application Type = Single Page Application для застосунків лише в браузері та Regular Web Application для серверно-рендерених застосунків. Неправильний тип дозволяє неправильні типи grants — наприклад, Regular Web App з grant SPA вмикає Implicit flow без PKCE, що зливає токени через URL-фрагменти.
Вимкніть тип Implicit grant на кожному застосунку. Dashboard → Application → Advanced Settings → Grant Types → зніміть позначку Implicit. Implicit flow повертає токени в URL-фрагментах, де вони логуються в історії браузера та аналітиці. Використовуйте Authorization Code з PKCE натомість.
Вимкніть Password grant, якщо у вас немає задокументованої потреби. Grant Resource Owner Password Credentials (ROPC) вимагає, щоб ви самі обробляли паролі користувачів — нівелюючи більшість того, для чого ви купили Auth0. Вимкніть його, якщо не інтегруєте застарілу систему.
Увімкніть Authorization Code з PKCE на кожному публічному клієнті. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = enabled. PKCE необхідний для мобільних застосунків та SPA, щоб запобігти перехопленню коду.

Allowlist callback та logout URL

Відкриті редиректи на шляху callback OAuth — це примітив крадіжки токенів. Allowlist Auth0 — ваш єдиний захист.

Встановіть Allowed Callback URLs точно на ваш продакшен-шлях callback — без wildcards. https://yourapp.com/callback, а не https://yourapp.com/*. Wildcard-callbacks дозволяють зловмисникам перенаправляти токени на довільні підшляхи у вашому домені.
Встановіть Allowed Logout URLs у скінченний список. Те саме правило: лише явні URL. Відкритий редирект logout дозволяє зловмисникам створювати фішингові сторінки, які виглядають як ваш стан після logout.
Встановіть Allowed Web Origins лише на ваш продакшен-origin. Використовується для silent authentication (поновлення токенів через прихований iframe). Wildcard-origin дозволяє сторінкам зловмисника виконувати silent auth проти вашого tenant.
Встановіть Allowed CORS origins для API-кінцевих точок, а не для застосунку. Tenant Settings → Advanced → Allowed CORS origins. За замовчуванням — порожньо (обмежено); додавайте лише явні origin, які ви контролюєте.

Токени та ротація refresh

Термін дії токена, ротація refresh та алгоритм підпису вирішують радіус ураження будь-якого витоку токена.

Увімкніть Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Кожен refresh видає новий refresh-токен і знецінює старий. У поєднанні з абсолютним терміном дії це обмежує крадіжку токенів.
Встановіть Refresh Token Reuse Interval на 0 (або настільки низько, наскільки дозволяє ваша терпимість до повторів). Інтервал повторного використання дозволяє використати токен двічі в тому ж вікні — вимкніть його, якщо у вас немає конкретної причини залишати.
Встановіть 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. Використовуйте офіційний SDK Auth0 на стороні сервера — він перевіряє їх автоматично. Власноруч написаний парсинг JWT зазвичай пропускає валідацію audience, що є обходом автентифікації.

Actions та custom code

Auth0 Actions (та застарілі Rules) виконуються на стороні сервера під час входу та інших подій життєвого циклу. Вони мають доступ до всього контексту запиту. Небезпечний код тут — це tenant-широка вразливість.

Ніколи не логуйте event.user або event.transaction як цілий об'єкт. Вони містять електронні адреси, IP-адреси та інший PII. Використовуйте логування на рівні полів і логуйте лише те, що потрібно.
Використовуйте сховище секретів для будь-якого API-ключа або URL вебхука. Actions → Edit → Secrets. Ніколи не інлайніть API-ключ як рядковий літерал у коді action — код видимий будь-кому з доступом до редактора Actions на tenant.
Валідуйте вхідні дані перед збереженням їх як user_metadata або app_metadata. Self-service action, який пише event.body.name у user.user_metadata.display_name — це stored-XSS вектор, якщо ваш фронтенд рендерить це поле без екранування.

RBAC та resource servers

Якщо ви використовуєте Auth0 RBAC, відображення ролі-в-дозволи — це ваш шар авторизації. Зробіть це неправильно — і будь-який автентифікований користувач зможе вдарити по admin-ендпоінтах.

Визначайте Resource Servers (APIs) явно на Панелі Auth0, а не на льоту. Кожен API має ідентифікатор (audience), scopes та налаштування підпису. Без зареєстрованого API всі токени видаються для неявного "Auth0 Management API" — неправильна audience.
Налаштуйте Permissions для кожного API та вимагайте їх у вашому коді через claim scope. Не перевіряйте членство в ролях у логіці застосунку; перевіряйте scopes в access-токені. Scopes — це OAuth-нативний механізм авторизації.
Перевірте, що автентифікований користувач без необхідної ролі / scope не може вдарити по привілейованих ендпоінтах. Увійдіть як звичайний користувач, спробуйте викликати POST /api/admin/users/delete. Відповідь має бути 403.

Виявлення аномалій та tenant-логи

Auth0 видає події з високим сигналом. Налаштуйте їх для сповіщення вашої команди, а не просто щоб вони лежали в буфері логів.

Увімкніть Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Кожен вимкнено за замовчуванням на безкоштовних тарифах; увімкніть усі для продакшену.
Стрімте tenant-логи в SIEM або у ваші логи застосунку. Dashboard → Monitoring → Streams. Auth0 зберігає логи 30 днів на більшості тарифів; довгострокове зберігання потребує стріму у вашу власну систему.
Сповіщайте про сплески fcoa (failed cross-origin auth) та fp (failed login). Сплеск цих за короткий проміжок — це credential stuffing. Направляйте у ваш on-call канал.

Наступні кроки

Запустіть сканування FixVibe проти вашого продакшен-URL — перевірка baas.clerk-auth0 позначає клієнтські секрети Auth0 у JavaScript-бандлі та інші класи розкриття провайдера ідентичності. Для еквівалента щодо Clerk дивіться Чек-лист безпеки Clerk. Для оглядового погляду на постачальників BaaS читайте Сканер неправильних налаштувань BaaS.