Авторизация и Аутентификация

Зачем это нужно

В любой информационной системе важно понимать, кто к ней обращается и что этому участнику позволено делать. Эти две задачи разделяются на процессы аутентификации (подтверждение личности) и авторизации (проверка прав доступа). Разделение обязанностей снижает риски, упрощает поддержку и повышение уровня безопасности.

Идентификация, аутентификация и авторизация — в чём различие

Идентификация — объявление своей личности: «Я — пользователь X».
Аутентификация — доказательство, что вы и есть X (пароль, одноразовый код, ключ и т.п.).
Авторизация — определение, какие действия вам разрешены (чтение, запись, администрирование и т.п.).

Факторы аутентификации

Надёжность подтверждения личности повышается комбинацией разных факторов:

Знание — то, что знает пользователь (пароль, PIN).
Обладание — то, что у пользователя есть (телефон, аппаратный токен).
Присущая характеристика — биометрия (отпечаток, лицо).
Контекст — место, время, устройство, поведенческие признаки.

Сеансы и токены доступа

После успешной аутентификации система должна «помнить» пользователя. Для этого используют сеанс (session) или токен доступа.

Сеансы чаще всего поддерживаются куками и хранят состояние на стороне сервера.
Токены обычно статeless: сервер проверяет их валидность без хранения состояния.

OAuth2: делегирование доступа

OAuth2 решает задачу безопасного делегирования доступа к ресурсам. Пользователь (Владелец ресурса) разрешает Приложению-клиенту выполнять ограничённые действия на Сервере ресурсов без передачи пароля. Разрешения выражаются через scopes (области доступа).

Авторизационный сервер выдаёт токены.
Сервер ресурсов защищает данные и проверяет токены.
Клиент запрашивает доступ к данным от имени пользователя.

OpenID Connect: слой идентичности поверх OAuth2

OIDC добавляет к OAuth2 идентификацию пользователя. Он вводит ID Token c набором claims (утверждений о пользователе: идентификатор, email, время выпуска и т.п.). Благодаря этому клиент может знать, кто вошёл, и привязать сеанс к конкретной личности.

JWT: формат компактных токенов

JSON Web Token — это компактный, URL-безопасный формат для переноса утверждений. Он обычно состоит из заголовка, полезной нагрузки (claims) и подписи или MAC. Проверив подпись и целостность, система принимает решение об авторизации.

Подпись: асимметричная (RS/EC) или симметричная (HMAC).
Стандартные claims: iss, sub, aud, exp, iat, nbf.
Пользовательские claims: роли, разрешения, контекстные сведения.

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

RBAC — доступ по ролям (роль агрегирует разрешения).
ABAC — доступ по атрибутам субъекта, объекта и контекста.
PBAC/Policy-based — доступ по политикам (правила, написанные на DSL/языке политик).

Жизненный цикл токенов: срок, обновление, отзыв

Безопасная работа с токенами требует управления жизненным циклом:

TTL — короткие сроки уменьшают окно атаки.
Refresh token — отдельный долгоживущий токен для обновления доступа.
Отзыв — механизмы немедленной блокировки (чёрные списки, ротация ключей, версии сессий).
Ротация ключей — периодическая смена криптоключей и публикация их через JWKS.

SSO и федерация

Единый вход позволяет пользователю аутентифицироваться один раз и получать доступ к нескольким приложениям. Федерация связывает доверенные домены: один выступает как поставщик идентичности, другие — как потребители.

Хранение и защита секретов

Если система управляет паролями или ключами, необходимо:

Хэшировать пароли адаптивными алгоритмами (Argon2, PBKDF2, bcrypt), использовать соль и перец (secret pepper).
Изолировать секреты в защищённом хранилище (менеджер секретов, HSM).
Обновлять криптополитику при изменениях угроз и стандартов.

Типичные угрозы и защиты

Фишинг — защищайтесь MFA, проверкой доменов, обучением пользователей.
Перехват токенов — используйте HTTPS, ограничивайте время жизни, привязывайте к аудитории/устройству, применяйте безопасные куки.
Реплей-атаки — nonce, одноразовые коды, короткий TTL.
Подбор паролей — замедляющие хэши, капчи, ограничение попыток, обнаружение аномалий.
Утечка ключей — ротация, сегрегация, мониторинг, отозвать токены, перевыпустить ключи.

Принципы проектирования политики доступа

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

Как соединяются понятия темы

На практике цепочка выглядит так: пользователь проходит аутентификацию у поставщика идентичности (часто через OIDC), получает ID Token и Access Token. Клиент предъявляет токен доступа серверу ресурсов. Сервер проверяет подпись, срок действия и область (scope) и принимает решение об авторизации согласно ролям, атрибутам и политикам.