Как современные фреймворки обрабатывают аутентификацию и авторизацию

Аутентификация vs Авторизация: что фреймворки обычно разделяют

Аутентификация отвечает на вопрос «кто вы?» Авторизация отвечает на вопрос «что вам разрешено делать?» Современные фреймворки рассматривают их как связанные, но отдельные проблемы — такое разделение помогает сохранять безопасность по мере роста приложения.

Аутентификация: установление личности

Аутентификация — это подтверждение, что пользователь (или сервис) — это то, за кого он себя выдаёт. Фреймворки обычно не жёстко привязывают вас к одному методу; вместо этого они дают точки расширения для распространённых вариантов: вход по паролю, социальный логин, SSO, API-ключи и учётные данные сервисов.

Результат аутентификации — это идентичность: ID пользователя, статус аккаунта и иногда базовые атрибуты (например, подтверждён ли email). Важно: аутентификация должна определить только, кто делает запрос, а не решать, разрешено ли действие.

Авторизация: принятие решения о доступе

Авторизация использует установленную идентичность плюс контекст запроса (маршрут, владелец ресурса, тенант, scope-ы, окружение и т.д.), чтобы решить, разрешено ли действие. Здесь живут роли, права, политики и правила, зависящие от ресурса.

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

• менять методы входа без переписывания правил доступа
• применять одинаковые проверки прав в веб-страницах, API и фоновых задачах
• держать логику «кто вы» отдельно от «что вы можете делать»

Точки применения: где фреймворк накладывает правила

Большинство фреймворков выполняют проверки через централизованные точки в жизненном цикле запроса:

• Middleware/фильтры/интерсепторы, которые запускаются до контроллеров/хендлеров
• Guards, блокирующие доступ к маршрутам или действиям
• Policy-проверки, вызываемые внутри бизнес-логики для решений, специфичных для ресурса

Общие строительные блоки (независимо от фреймворка)

Хотя названия различаются, строительные блоки знакомы: хранилище идентичностей (пользователи и учётные данные), сессия или токен, переносящий идентичность между запросами, и middleware/guards, которые обеспечивают аутентификацию и авторизацию последовательно.

Примеры в этой статье концептуальны, чтобы вы могли соотнести их с выбранным фреймворком.

Хранилища идентичности и модели пользователя

Прежде чем фреймворк сможет «войти» за кого-то, ему нужны две вещи: место для получения данных об идентичности (identity store) и единообразный способ представить эту идентичность в коде (user model). Многие «функции аутентификации» в современных фреймворках — это абстракции над этими двумя частями.

Типичные источники идентичности

Фреймворки обычно поддерживают несколько бэкендов, встроенно или через плагины:

• Пользователи в базе приложения: классическая таблица/коллекция users, управляемая приложением.
• Внешние провайдеры идентичности (IdP): Google, Microsoft, GitHub или специализированные провайдеры вроде Auth0/Okta, обычно через OAuth 2.0 / OpenID Connect.
• Корпоративные директории: LDAP/Active Directory, часто для внутренних инструментов и B2B-приложений.

Ключевое различие — кто источник правды. При хранении пользователей в базе ваше приложение владеет учётными данными и профилем. При использовании IdP или директории приложение часто хранит «локального shadow user», связанного с внешней идентичностью.

Основные поля модели пользователя

Хотя фреймворки могут генерировать модель пользователя по умолчанию, большинство команд стандартизируют несколько полей:

• id: неизменяемый первичный ключ (лучше не использовать email).
• email/username: идентификатор для входа; обычно уникальный и нормализованный.
• password_hash: только если приложение управляет паролями (никогда не храните сырой пароль).
• флаги статуса: например, is_verified, is_active, is_locked, deleted_at.

Эти флаги важны, потому что аутентификация — это не только «правильный пароль?», но и «может ли этот аккаунт входить прямо сейчас?».

Жизненный цикл аккаунта: больше, чем регистрация

Практичное хранилище идентичностей поддерживает события жизненного цикла: регистрация, подтверждение email/телефона, сброс пароля, отзыв сессий после чувствительных изменений и деактивация/soft-delete. Фреймворки часто дают примитивы (токены, временные метки, хуки), но вы определяете правила: сроки жизни, лимиты скорости и поведение существующих сессий при отключении аккаунта.

Где фреймворки «подключаются»

Большинство современных фреймворков предлагают точки расширения вроде user providers, adapters или repositories. Эти компоненты переводят «по идентификатору для входа получить пользователя» и «по user ID загрузить текущего пользователя» в операции для выбранного хранилища — SQL-запрос, вызов IdP или lookup в корпоративной директории.

Аутентификация на основе сессий (cookies и серверные сессии)

Сессионная аутентификация — «классический» подход, который многие веб-фреймворки по умолчанию используют для серверно-рендерных приложений. Идея проста: сервер помнит, кто вы, а браузер держит небольшой указатель на эту память.

Как это работает

После успешного входа фреймворк создаёт серверную запись сессии (обычно случайный session ID, связанный с пользователем). Браузер получает cookie с этим session ID. При каждом запросе браузер автоматически отправляет cookie, и сервер по нему находит вошедшего пользователя.

Поскольку cookie лишь идентификатор (а не сами данные пользователя), чувствительная информация остаётся на сервере.

Флаги cookie, которые обычно устанавливают фреймворки

Современные фреймворки стремятся затруднить кражу или неправильное использование session cookie, устанавливая безопасные значения по умолчанию:

• HttpOnly: блокирует доступ JavaScript к cookie (уменьшает вред от XSS).
• Secure: отправляет cookie только по HTTPS.
• SameSite (Lax/Strict/None): контролирует кросс-сайтовую отправку cookie (важно для защиты от CSRF и сторонних auth-флоу).

Эти параметры часто настраиваются в разделе «session cookie settings» или «security headers».

Где хранятся сессии

Фреймворки обычно позволяют выбрать хранилище сессий:

• In-memory: быстро и просто, но сессии пропадают при перезапуске и не масштабируются по нескольким серверам.
• Database-backed: надёжно и с возможностью аудита, но добавляет нагрузку на БД.
• Cache/Redis-подобное хранилище: быстро и разделяемо между серверами; подходит для масштабирования, но добавляет зависимость от ещё одного сервиса.

В общем, компромисс — скорость vs надёжность vs операционная сложность.

Выход из системы и инвалидизация

Logout может означать разные вещи:

• Выход на одном устройстве: удалить текущую сессию и очистить cookie.
• Выход везде: инвалидировать все сессии пользователя (например, после смены пароля).

Фреймворки часто реализуют «выход везде» через версию сессии пользователя, хранение множества session ID и их отзыв. Если вам нужен немедленный отзыв, сессионная модель обычно проще, чем токены, потому что сервер может просто забыть сессию.

Токен-бейзед аутентификация (JWT и непрозрачные токены)

Токен-бейзед аутентификация заменяет серверные lookup'и строкой, которую клиент подаёт при каждом запросе. Фреймворки обычно рекомендуют токены для API (много клиентов), мобильных приложений, SPA с отдельным бэкендом или когда сервисы вызывают друг друга без браузерных сессий.

Что значит «токен» в практике

Токен — это учётная запись доступа, выданная после входа (или завершения OAuth flow). Клиент отправляет его в последующих запросах, сервер аутентифицирует вызывающего и затем проводит авторизацию. Большинство фреймворков рассматривают это как первоклассный паттерн: endpoint для выдачи токена, middleware для валидации и guards/policies для проверок после установления идентичности.

Непрозрачные токены vs JWT

Непрозрачные (opaque) токены — случайные строки без смысла для клиента (например, tX9...). Сервер валидирует их через lookup в базе или кэше. Это упрощает отзыв и сохраняет содержимое приватным.

JWT (JSON Web Token) структурированы и подписаны. Обычно содержат claims: идентификатор пользователя (sub), издателя (iss), аудиторию (aud), времена выпуска/истечения (iat, exp) и иногда роли/скоупы. Важно: JWT кодированы, но по умолчанию не зашифрованы — любой, у кого токен, может прочитать его claims, даже если не может подделать подпись.

Хранение: заголовок Authorization vs cookies

Руководства фреймворков сходятся на двух безопасных вариантах:

• Отправлять access-токен в Authorization: Bearer <token> для API. Это снижает риск CSRF (cookie отправляются автоматически), но повышает требования к защите от XSS, потому что JavaScript имеет доступ к токену.
• Использовать cookie только если можно сделать их HttpOnly, Secure и SameSite, и если вы готовы корректно обрабатывать CSRF (часто в паре с отдельными CSRF-токенами).

Refresh-токены, ротация и эндпойнты

Access-токены делают короткоживущими. Чтобы не требовать частых повторных входов, многие фреймворки поддерживают refresh-токены: долгоживущий учётный элемент, используемый только для выдачи новых access-токенов.

Типичная структура:

• POST /auth/login → возвращает access token (и refresh token)
• POST /auth/refresh → вращает refresh token и возвращает новый access token
• POST /auth/logout → инвалидирует refresh-токены на сервере

Ротация (выдача нового refresh-токена при каждом использовании) ограничивает ущерб при компрометации. Многие фреймворки предоставляют хуки для хранения идентификаторов токенов, обнаружения повторного использования и быстрой отзыва сессий.

OAuth 2.0 и OpenID Connect в экосистемах фреймворков

OAuth 2.0 и OpenID Connect (OIDC) часто упоминаются вместе, но фреймворки трактуют их по-разному, потому что они решают разные задачи.

OAuth 2.0 vs OIDC: что вам действительно нужно

Используйте OAuth 2.0, когда нужно делегированное право доступа: ваше приложение получает разрешение вызывать API от имени пользователя (читать календарь, постить в репозиторий) без обработки пароля пользователя.

Используйте OpenID Connect, когда вам нужен логин/идентичность: ваше приложение хочет узнать, кто пользователь, и получить ID-токен с claims. На практике «Войти через X» обычно — это OIDC поверх OAuth 2.0.

Основные потоки, которые поддерживают фреймворки

Большинство современных фреймворков и библиотек аутентификации фокусируются на двух потоках:

• Authorization Code flow + PKCE: дефолт для браузерных приложений и мобильных клиентов. PKCE предотвращает перехват кода и ожидается большинством провайдеров.
• Client Credentials flow: для вызовов сервис‑к‑сервису, где нет конечного пользователя (джобы, бэк‑энд воркеры, внутренние микросервисы).

Обработка callback: где важны детали безопасности

Интеграции фреймворков обычно дают callback-маршрут и вспомогательное middleware, но вам всё равно нужно настроить основные элементы:

• Валидировать redirect URI точно (схема/хост/путь). Избегайте wildcard-redirect URI.
• Использовать и проверять параметр state для защиты от CSRF-подобных атак при входе.
• Для OIDC генерировать и проверять nonce, чтобы уменьшить риск повторного воспроизведения токенов.
• Хранить временные значения (state/nonce/verifier) в безопасной сессии или зашифрованном cookie, а не в localStorage.

Scopes, claims и маппинг на локальных пользователей

Фреймворки обычно нормализуют данные провайдера в локальную модель пользователя. Ключевое решение — что именно будет двигателем авторизации:

• Scopes — это права OAuth для API (что может делать access token).
• Claims — атрибуты идентичности в ID-токене OIDC (кто пользователь).

Типичный паттерн: сопоставлять стабильные идентификаторы (например, sub) с локальным пользователем, затем переводить провайдерские роли/группы/claims в локальные роли или политики, которыми управляет ваше приложение.

Пароли, хеширование, МФА и восстановление аккаунта

Пароли всё ещё распространены, поэтому фреймворки обычно поставляются с безопасными паттернами хранения и общими защитами. Главное правило не меняется: никогда не храните пароль в открытом виде (и не храните простую хеш‑строку без соли и работы).

Дефолты хеширования паролей (и почему простое хеширование небезопасно)

Современные фреймворки и их библиотеки обычно используют специализированные хешеры паролей: bcrypt, Argon2 или scrypt. Эти алгоритмы намеренно медленные и включают salt, что затрудняет атаки с предвычисленными таблицами и делает масштабное взламывание дорогим.

Обычный быстрый хеш (например, SHA-256) небезопасен для паролей, потому что он слишком быстрый — при утечке БД атакующий сможет перебрать миллиарды вариантов. Хешеры паролей добавляют параметр сложности (cost), который можно увеличивать по мере улучшения железа.

Политики паролей, которые вы обычно увидите

Фреймворки обычно дают хуки (или плагины) для навешивания правил без хардкода:

• Политики на основе длины (длинные passphrase эффективнее сложных, но коротких правил).
• Проверки по утечкам против баз скомпрометированных паролей (не позволять пароли из известных сливов).
• Ограничение частоты попыток и опциональная временная блокировка после повторных неудач, чтобы замедлить перебор.

Варианты МФА и компромиссы

Экосистемы обычно поддерживают добавление МФА как второго шага после проверки пароля:

• TOTP (приложения-аутентификаторы): широко поддерживается и работает офлайн; всё ещё фишится, если пользователь вводит код по запросу злоумышленника.
• WebAuthn / passkeys: сильная защита против фишинга и воспроизведения; часто наилучший UX после первоначальной настройки.
• SMS-коды: легко развернуть, но слабее из‑за SIM-swap и перехвата — лучше, чем ничего, но не идеально для рисковых аккаунтов.

Безопасное восстановление доступа к аккаунту

Сброс пароля — частый вектор атак, поэтому фреймворки поощряют такие шаблоны:

• Ссылки для сброса на основе одноразовых токенов, хранимых на сервере (часто хэшированных как пароли).
• Короткие сроки жизни (минуты‑часы) и одноразовость.
• Инвалидизация сессий или вращение токенов после успешного сброса, чтобы скомпрометированные сессии не оставались активными.

Хорошее правило: сделать восстановление простым для легитимного пользователя и дорогостоящим для автоматических атак.

Middleware, Guards и жизненный цикл запроса

Большинство современных фреймворков рассматривают безопасность как часть пайплайна запроса: ряд шагов, выполняемых до (и иногда после) контроллера/хендлера. Названия варьируются — middleware, filters, guards, interceptors — но идея постоянна: каждый шаг может читать запрос, добавлять контекст или прервать обработку.

Практичная модель пайплайна

Обычный поток выглядит так:

1. Routing выбирает endpoint (например, /account/settings).
2. Препроцессинг запускается (middleware/filters/interceptors).
3. Аутентификация пытается установить вызывающего.
4. Авторизация решает, может ли идентифицированный пользователь получить доступ.
5. Handler/controller выполняет бизнес-логику.
6. Постобработка может трансформировать ответ или логировать детали.

Фреймворки рекомендуют держать проверки безопасности вне бизнес-логики, чтобы контроллеры фокусировались на «что делать», а не «кто может это сделать».

Где происходит аутентификация (identity first)

Аутентификация — шаг, где фреймворк устанавливает контекст пользователя из cookie, session ID, API-ключей или bearer-токенов. При успехе он создаёт объект идентичности в контексте запроса — часто user, principal или context.auth.

Это важно, потому что последующие шаги и код приложения не должны заново парсить заголовки или повторно валидировать токены. Они читают уже заполненный объект пользователя, который обычно содержит:

• стабильный user ID
• роли/claims (иногда)
• метаданные вроде метода аутентификации или возраста сессии

Где происходит авторизация (проверки прав)

Авторизация обычно реализуется как:

• Guard на уровне маршрута (например, «требуется вход»)
• Policy-проверки (например, «может ли редактировать этот документ»), выполняемые после загрузки ресурса

Второй тип часто располагается ближе к контроллерам и сервисам, потому что ему нужны параметры маршрута или объекты из БД для корректного решения.

401 vs 403: корректная обработка ошибок

Фреймворки различают два режима отказа:

• 401 Unauthorized (неаутентифицирован): идентичность не установлена. Для браузерных приложений обычно перенаправление на страницу входа; для API — JSON-ошибка.
• 403 Forbidden (неавторизован): идентичность известна, но ей не хватает прав.

Хорошие системы не выдают подробностей в 403-ответах; они отказывают без объяснения, какое правило не прошло.

Модели авторизации: роли, права и политики

Авторизация отвечает на более узкий вопрос, чем логин: «Разрешено ли этому вошедшему пользователю сделать это прямо сейчас?» Современные фреймворки обычно поддерживают несколько моделей, и команды часто комбинируют их.

Ролевая модель (RBAC)

RBAC присваивает пользователям роли (например, admin, support, member) и ограничивает функции на основе ролей.

Её просто понять и быстро внедрить — часто фреймворк даёт хелперы вроде requireRole('admin'). Иерархии ролей (admin → manager → member) уменьшают дублирование, но могут скрывать привилегии: небольшое изменение в родительской роли может незаметно дать доступ по всему приложению.

RBAC хорошо подходит для широких, стабильных разграничений.

Права (permissions) для тонкой настройки

Проверка прав сопоставляет действие и ресурс, обычно как:

• Действие: read, create, update, delete, invite
• Ресурс: invoice, project, user, иногда с ID или проверкой владения

Эта модель точнее, чем RBAC. Например, «может обновлять проекты» отличается от «может обновлять только свои проекты», что требует проверки и прав, и условий по данным.

Фреймворки часто реализуют это через центральную функцию can? (или сервис), вызываемую из контроллеров, резолверов, воркеров или шаблонов.

Политики (policy-based authorization)

Политики упаковывают логику авторизации в переиспользуемые оценщики: «Пользователь может удалить комментарий, если он его автор или модератор». Политики принимают контекст (user, resource, request), поэтому они идеальны для:

• проверок владения
• правил, связанных с тарифом/подпиской
• ограничений по времени или организации

Когда фреймворки интегрируют политики в маршрутизацию и middleware, вы можете последовательно применять правила по всем конечным точкам.

Атрибуции/аннотации vs проверки в коде

Аннотации (например, @RequireRole('admin')) держат намерение рядом с хендлером, но могут фрагментировать логику при усложнении правил.

Проверки в коде (вызовы авторизатора) более многословны, но проще тестируются и рефакторятся. Частая компромиссия: аннотации для грубых ворот и политики для детальной логики.

Встроенные защиты: CSRF, CORS и security headers

Современные фреймворки помогают не только с логином — они предлагают защиты от распространённых атак, которые возникают вокруг аутентификации.

CSRF: защита cookie‑базированных браузерных приложений

Если приложение использует session cookies, браузер автоматически прикрепляет их к запросам — иногда даже когда запрос инициирован с другого сайта. Защита CSRF обычно добавляет per-session (или per-request) CSRF-токен, который должен идти вместе с изменяющими состояние запросами.

Распространённые паттерны:

• Synchronizer token: сервер рендерит токен в формы и проверяет его в POST/PUT/PATCH/DELETE.
• Double-submit cookie: CSRF-токен хранится в cookie и также отправляется в заголовке/теле; сервер проверяет совпадение.

Комбинируйте CSRF-токены с SameSite куки (часто Lax) и делайте session cookie HttpOnly и Secure, если уместно.

CORS: API требуют явных правил

CORS — это не механизм аутентификации; это браузерная политика. Фреймворки обычно дают middleware/конфигурацию для разрешения доверенных источников вызывать ваш API.

Ошибки настройки, которых нужно избегать:

• Access-Control-Allow-Origin: * вместе с Access-Control-Allow-Credentials: true (браузеры отвергнут это, а это признак неправильной конфигурации).
• Отражение любого Origin без строгого allowlist'а.
• Забвение нужных заголовков (например, Authorization) или методов, из‑за чего клиент «в curl работает, а в браузере нет».

Clickjacking и security headers

Большинство фреймворков могут установить безопасные дефолты или упростить добавление заголовков:

• X-Frame-Options или Content-Security-Policy: frame-ancestors для защиты от clickjacking.
• Content-Security-Policy для более широкого контроля скриптов/ресурсов.
• Referrer-Policy и X-Content-Type-Options: nosniff для безопасного поведения браузера.

Валидация ввода vs авторизация

Валидация гарантирует корректность данных; авторизация — что пользователь может выполнить действие. Корректный запрос всё ещё может быть запрещён — лучше валидировать входные данные и затем проверять права на конкретный ресурс.

Шаблоны по типам приложений: SSR, SPA, Mobile, Microservices

Правильный auth-паттерн сильно зависит от того, где выполняется код и как запросы доходят до бэкенда. Фреймворки могут поддерживать несколько опций, но дефолты, удобные для одного типа приложения, могут быть неудобны или рискованны для другого.

Серверно-рендерные приложения (SSR)

SSR обычно лучше сочетаются с куками и сессионными сессиями. Браузер отправляет cookie автоматически, сервер по ним восстанавливает сессию, и страницы рендерятся с контекстом пользователя без лишнего клиентского кода.

Практическое правило: держите session cookies HttpOnly, Secure и с осмысленным SameSite, и полагайтесь на серверные проверки авторизации для каждого запроса, который рендерит приватные данные.

Single-page apps (SPA)

SPA часто вызывают API из JavaScript, что делает видимым выбор токенов. Многие команды предпочитают OAuth/OIDC, выдающий короткоживущие access-токены.

Избегайте хранения долгоживущих токенов в localStorage, когда это возможно; это увеличивает blast radius от XSS. Альтернатива — паттерн backend-for-frontend (BFF): SPA общается с вашим сервером по сессионному cookie, а сервер хранит/обменивает токены для upstream API.

Мобильные клиенты

Мобильные приложения не могут опираться на браузерные cookie-правила так же, как веб. Они обычно используют OAuth/OIDC с PKCE и хранят refresh-токены в безопасном хранилище платформы (Keychain/Keystore).

Планируйте сценарии «потерянного устройства»: отзывайте refresh-токены, ротируйте учётные данные и делайте повторный вход максимально плавным, особенно при включённой МФА.

Микросервисы и API‑шлюзы

При большом количестве сервисов выбирают между централизованной идентичностью и применением политик на уровне сервиса:

• Gateway-centric: шлюз валидирует токены и форвардит контекст идентичности.
• Defense in depth: каждый сервис также валидирует токены и применяет авторизацию для своих ресурсов.

Для аутентификации сервисов часто применяют mTLS (сильная идентичность канала) или OAuth client credentials (service accounts). Важно не только аутентифицировать вызывающий сервис, но и авторизовать, что ему разрешено делать.

Имперсонация и доступ админа

Функции «войти как пользователь» мощные и опасные. Предпочитайте явные сессии имперсонации, требуйте повторной аутентификации/МФА для админов и всегда записывайте аудит (кто, кого, когда и какие действия выполнил).

Тестирование, наблюдаемость и распространённые ошибки

Механизмы безопасности помогают только если они продолжают работать при изменениях кода. Современные фреймворки упрощают тестирование auth-флоу, но вам всё равно нужны тесты, отражающие поведение реальных пользователей и атакующих.

Тестирование без хрупких настроек

Начните с разделения того, что вы тестируете:

• Unit-тесты для правил авторизации (политик, guards, permission checks). Они быстрые и покрывают крайние случаи: «пользователь владеет ресурсом» vs «admin имеет override».
• Интеграционные тесты для защищённых маршрутов (запросы, которые должны пройти или быть отклонены). Они ловят ошибки в middleware, отсутствующие декораторы и битые редиректы.

Большинство фреймворков содержит тест-хелперы, чтобы не писать вручную сессии или токены для каждого теста. Общие паттерны:

• Test client, сохраняющий куки между запросами (полезно для session-based auth).
• Хелперы для авторизации мок-пользователя (или подстановки JWT/opaque token) без прохождения UI.
• Fixtures/factories для пользователей, ролей и ресурсов, чтобы тесты были читабельными.

Практическое правило: для каждого «путь успешного выполнения» добавляйте тест «должен быть отказан», чтобы доказать, что проверка авторизации реально срабатывает.

Если вы быстро прототипируете, инструменты, поддерживающие откат изменений и снапшоты, помогают безопасно экспериментировать: например, генерировать фронтенд и бэкенд из чат‑спецификации и иметь лёгкие откаты при настройке middleware/guards.

Наблюдаемость: доказывайте, что произошло

Когда что‑то идёт не так, нужно быстро и надёжно получить ответы.

Логируйте/аудитируйте ключевые события:

• События аутентификации: вход/провал входа, MFA-челленджи, сбросы пароля, обновления токенов.
• Отказы авторизации: какое правило не сработало, над каким ресурсом, за какого пользователя (не логируйте секреты).
• Correlation IDs: request ID, прокинутый через логи и трассы, чтобы проследить попытку входа между сервисами.

Добавьте лёгкие метрики: частота 401/403, всплески неудачных входов и необычные паттерны обновления токенов.

Распространённые ошибки, от которых фреймворки не спасут полностью

• Доверие клиентским утверждениям: никогда не полагайтесь на флаги в UI или client-side roles. Всегда проверяйте на сервере.
• Пропущенные проверки во вторичных эндпоинтах: экспорт данных, фоновые задачи, админ‑инструменты и «внутренние» API всё ещё нуждаются в авторизации.
• Слишком широкие scopes/roles: «достаточно хорошо для сейчас» обычно становится постоянным и приводит к чрезмерным правам.
• Утечка токенов: хранение токенов в логах, URL или лёгкодоступных местах (localStorage) или передача третьим лицам.

Обращайтесь с багами в области авторизации как с тестируемым поведением: если это может регрессировать — это заслуживает теста.