// docs / baas security / auth0 hardening

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

Auth0 — это платформа «идентификация как услуга» с огромной поверхностью — приложения, API (серверы ресурсов), арендаторы, действия, правила (устаревшие), соединения и гранты. Неправильная настройка любого из них — это обход аутентификации. Этот чек-лист — это аудит из 22 пунктов по приложениям, спискам разрешённых обратных вызовов / выходов, токенам и ротации обновления, пользовательским действиям, RBAC, обнаружению аномалий и текущему мониторингу. Каждый пункт можно проверить в Панели Auth0 менее чем за 10 минут.

Об эквивалентном чек-листе для Clerk см. Чек-лист безопасности Clerk. О том, почему неправильные настройки на уровне идентификации являются слепыми зонами ИИ-инструментов, см. Почему ИИ-инструменты кодирования оставляют пробелы в безопасности.

Тип приложения и типы грантов

Тип приложения и включённые типы грантов — это настройки с самым высоким уровнем влияния в Auth0. Неправильное их получение открывает классы атак, которые никакое количество фронтенд-кода не закроет.

Используйте Тип приложения = Single Page Application для приложений только для браузера и Regular Web Application для приложений с серверным рендерингом. Неправильный тип позволяет неправильные типы грантов — например, Regular Web App с грантом SPA включает Implicit-поток без PKCE, который утекает токены через URL-фрагменты.
Отключите тип гранта Implicit на каждом приложении. Панель → Application → Advanced Settings → Grant Types → снимите галочку с Implicit. Implicit-поток возвращает токены в URL-фрагментах, где они регистрируются в истории браузера и аналитике. Используйте Authorization Code с PKCE.
Отключите грант Password, если у вас нет задокументированной необходимости. Грант Resource Owner Password Credentials (ROPC) требует, чтобы вы сами обрабатывали пароли пользователей — побеждая большую часть того, для чего вы купили Auth0. Отключите его, если только не интегрируетесь с устаревшей системой.
Включите Authorization Code с PKCE на каждом публичном клиенте. Панель → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = включено. PKCE требуется для мобильных приложений и SPA, чтобы предотвратить перехват кода.

Списки разрешённых обратных вызовов и URL выхода

Открытые перенаправления на пути обратного вызова OAuth — это примитив кражи токенов. Список разрешённых Auth0 — это ваша единственная защита.

Установите Allowed Callback URLs на ваш точный производственный путь обратного вызова — без подстановочных знаков. https://yourapp.com/callback, а не https://yourapp.com/*. Подстановочные обратные вызовы позволяют злоумышленникам перенаправлять токены на произвольные подпути на вашем домене.
Установите Allowed Logout URLs на конечный список. Та же правило: только явные URL. Открытый перенаправление выхода позволяет злоумышленникам создавать фишинговые страницы, которые выглядят как ваше состояние после выхода.
Установите Allowed Web Origins только на ваше производственное происхождение. Используется для тихой аутентификации (обновление токена через скрытый iframe). Подстановочное происхождение позволяет страницам злоумышленника выполнять тихую аутентификацию против вашего арендатора.
Установите Allowed CORS origins для конечных точек API, а не приложения. Tenant Settings → Advanced → Allowed CORS origins. По умолчанию пусто (ограничено); добавляйте только явные источники, которые вы контролируете.

Токены и ротация обновления

Срок действия токена, ротация обновления и алгоритм подписи определяют радиус взрыва любой утечки токена.

Включите ротацию токена обновления. Application → Refresh Token Settings → Rotation. Каждое обновление выдаёт новый токен обновления и делает старый недействительным. В сочетании с абсолютным истечением это сдерживает кражу токенов.
Установите интервал повторного использования токена обновления равным 0 (или настолько низко, насколько позволяет ваша терпимость к повтору). Интервал повторного использования позволяет использовать токен дважды в одном окне — отключите его, если у вас нет конкретной причины держать его.
Установите абсолютный срок действия токена обновления на 14-30 дней, а не бесконечность. Application → Refresh Token Expiration → Absolute Expiration. По умолчанию Auth0 имеет только Inactivity, что означает, что незанятый сеанс может сохраняться годами.
Установите алгоритм подписи JWT на RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 использует асимметричную подпись, поэтому клиент не может подделать токены. Никогда не используйте HS256 для приложений, обращённых к клиенту.
Проверяйте утверждения aud и iss на каждом JWT, который получает ваш API. Используйте официальный Auth0 SDK на серверной стороне — он проверяет их автоматически. Самодельный разбор JWT обычно пропускает проверку аудитории, что является обходом аутентификации.

Действия и пользовательский код

Auth0 Actions (и устаревшие Rules) выполняются на серверной стороне при входе и других событиях жизненного цикла. У них есть доступ ко всему контексту запроса. Небезопасный код здесь — это уязвимость на уровне арендатора.

Никогда не регистрируйте event.user или event.transaction как целый объект. Они содержат адреса электронной почты, IP-адреса и другие PII. Используйте только логирование на уровне полей и регистрируйте только то, что вам нужно.
Используйте хранилище секретов для любого ключа API или URL webhook. Actions → Edit → Secrets. Никогда не встраивайте ключ API как строковый литерал в коде действия — код виден любому с доступом к редактору действий на арендаторе.
Проверяйте входные данные перед их сохранением как user_metadata или app_metadata. Самообслуживающее действие, которое записывает event.body.name в user.user_metadata.display_name, — это вектор хранимого XSS, если ваш фронтенд отображает это поле без экранирования.

RBAC и серверы ресурсов

Если вы используете Auth0 RBAC, отображение ролей на разрешения — это ваш слой авторизации. Сделайте это неправильно, и любой аутентифицированный пользователь может попасть на админские конечные точки.

Определяйте серверы ресурсов (API) явно в Панели Auth0, а не на лету. У каждого API есть идентификатор (audience), области и настройки подписи. Без зарегистрированного API все токены выдаются для неявного «Auth0 Management API» — неправильная аудитория.
Настройте разрешения на API и требуйте их в своём коде с утверждением scope. Не проверяйте членство в роли в логике приложения; проверяйте области в токене доступа. Области — это нативный механизм авторизации OAuth.
Протестируйте, что аутентифицированный пользователь без требуемой роли / области не может попасть на привилегированные конечные точки. Войдите как обычный пользователь, попытайтесь вызвать POST /api/admin/users/delete. Ответ должен быть 403.

Обнаружение аномалий и журналы арендатора

Auth0 испускает события с высоким сигналом. Настройте их, чтобы предупреждать вашу команду, а не просто сидеть в буфере журнала.

Включите защиту от атак: обнаружение ботов, грубая сила, регулирование подозрительных IP. Панель → Security → Attack Protection. Каждая по умолчанию отключена на бесплатных тарифах; включите их все для продакшена.
Поток журналов арендатора в SIEM или ваши журналы приложения. Панель → Monitoring → Streams. Auth0 сохраняет журналы 30 дней на большинстве планов; долгосрочное хранение требует потока в вашу собственную систему.
Предупреждайте о всплесках fcoa (неудачная кросс-источник аутентификация) и fp (неудачный вход). Всплеск этих в коротком окне — это подстановка учётных данных. Направляйте в ваш канал on-call.

Следующие шаги

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