Auth0 scopes сами по себе не обеспечивают безопасность
Модель авторизации Auth0 работает только если команды понимают, откуда берутся разрешения, где они ограничены и какая настройка решает, что попадет в access token. Важно не то, использует ли приложение scopes, а то, соответствуют ли они правильной роли пользователя, границам приложения и доверенной модели.
Что изменилось#
Руководство Auth0 описывает взаимодействие четырех элементов авторизации, которые легко перепутать в продакшене: роли, разрешения, client grants и scopes.
Различие важно: аутентификация и авторизация решают разные задачи. Аутентификация отвечает кто пользователь, авторизация — что этот пользователь или приложение после входа может делать.
Именно на этом уровне обычно возникают ошибки контроля доступа. Корректный логин не гарантирует право читать заказ, изменять продукт, вызывать API или использовать admin-путь. Решение должно принимать политика.
Модель Auth0 начинается с permissions — гранулярных операций API, например чтение заказов или запись продуктов. Роль — это именованная группа разрешений, назначаемая пользователям. Это позволяет управлять набором возможностей без привязки каждой операции к каждому человеку.
Client grants задают политику для приложения. Они определяют, какие permissions приложение может запрашивать. Это критично для machine-to-machine доступа, но важно и для пользовательских приложений, так как приложение может стать «потолком» разрешений.
Scopes появляются в access token после того, как Auth0 оценит конфигурацию. Это не просто wishlist приложения, а результат политики.
Разница между запрошенным и выданным — практическая граница безопасности.
Зачем это важно#
Риск очевиден: команды смотрят на token, видят scopes и думают, что авторизация настроена. Нет. Token отражает только конфигурацию.
Auth0 выделяет две настройки, влияющие на то, какие permissions попадают в token.
Во-первых, RBAC должен быть включен, чтобы роли пользователей и их permissions учитывались в token. Если RBAC отключен, роли не влияют на token.
Во-вторых, политика доступа приложения определяет, доверяется ли приложению полностью, ограничено client grant или заблокировано от API permissions. Эта настройка резко меняет модель безопасности.
Для внутреннего админ-портала допустима модель, ориентированная на пользователя. Роль пользователя становится главным сигналом доверия. Для менеджера склада token может включать scopes, связанные с продуктами. Для агента поддержки — только scopes чтения заказов.
Для стороннего партнерского приложения такая модель слишком свободна. Приложение партнера не должно наследовать все разрешения мощного пользователя. Безопаснее применять модель, ориентированную на приложение: client grant задает жесткий потолок, и даже админ не может добавить лишние scopes.
Знание этих настроек важно для security operations, а не просто для разработчиков.
Что проверить#
Начните с API, а не UI. Перечислите permissions API, сравните с scopes, которые получают приложения.
Проверьте, включен ли RBAC для API. Если поток зависит от ролей, но RBAC выключен, роли могут выглядеть верно в dashboard, но token не будет ограничен.
Проверьте назначения ролей для пользователей с доступом. RBAC без роли дает отсутствие scopes, что безопаснее, чем implicit access, но может ломать рабочие процессы.
Проверьте client grants каждого приложения. Особенно важно для партнерских приложений, автоматизации, интеграций и любых приложений с меньшей силой, чем у пользователя.
Ответьте на четыре вопроса:
- Какие permissions есть в API?
- Какие роли их объединяют?
- Какие пользователи получают эти роли?
- Какие приложения могут запрашивать эти permissions?
Затем протестируйте реальные token. Декодируйте access token из репрезентативных потоков и сравните claims scopes с предполагаемой политикой. Dashboard не отражает реальность выданного token.
Для операционных деталей см. GigaTap: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational и https://gigatap.top/en/articles/open-source-security-needs-more-than-code
Чего не переоценивать#
Руководство Auth0 объясняет границы авторизации, но не гарантирует, что приложение корректно применяет все разрешения после выдачи token.
Token может содержать правильные scopes, но API все равно должен проверять их на нужных endpoints и объектах. Ошибки проверки на уровне объектов, отсутствие route guards и нестабильное backend enforcement все равно создают проблемы доступа.
Scopes не заменяют авторизацию на уровне данных. Широкий scope read access может требовать проверки арендатора, владельца, организации или ресурса. Материал поддерживает least privilege на уровне permissions и приложения, но не решает авторизацию сам по себе.
Правильная практика: Auth0 дает несколько слоев ограничения доступа, которые работают только при явной модели доверия.
Внутренние инструменты могут опираться на роли пользователей при доверенном приложении и управляемых пользователях. Потоки с третьими сторонами требуют жестких границ приложения. Machine-to-machine доступ требует прямого контроля над запросами client.
Проверка: определите, кто ограничивает token — пользователь, приложение или оба, и убедитесь, что выданные scopes соответствуют этой политике.