Идентификацию, аутентификацию и авторизацию часто смешивают в одну тему, хотя архитектурно это три разных слоя доверия.
Глава раскладывает их на решения о субъекте, федерации, сессиях, токенах, сервисной идентичности и политике доступа, чтобы OAuth 2.0/OIDC, SAML, WebAuthn, SCIM и mTLS заняли понятные места.
На интервью и в архитектурных разборах она помогает отделять сценарий входа от политики доступа, объяснять допущения доверия и не путать аутентификацию пользователя с доверием между сервисами.
Практическая польза главы
Практика проектирования
Разделяйте идентификацию, аутентификацию и авторизацию в архитектуре: кто субъект, как он доказал подлинность и какое действие ему разрешено.
Качество решений
Проверяйте жизненный цикл токенов, сервисную идентичность, точки применения политики и журнал аудита, а не только форму входа.
Аргументация на интервью
Стройте ответ как поток: идентификатор, проверка подлинности, сессия или токен, решение доступа.
Формулировка компромиссов
Явно обсуждайте цену многофакторной аутентификации, короткоживущих токенов, централизованных политик и отзыва доступа.
Spec
OpenID Connect Core
Базовая спецификация OIDC для аутентификации пользователя поверх OAuth 2.0.
В промышленной эксплуатации чаще всего ломаются не криптографические алгоритмы, а границы ответственности: где заканчивается , где начинается и где принимается решение .
Эта глава фиксирует практическую модель для пользователей и сервисов: , , токены, OIDC/OAuth, SAML, WebAuthn, mTLS, SCIM и политику доступа.
Архитектурные схемы идентичности
Три режима показывают разные архитектурные вопросы: кто субъект, как он доказал подлинность и кто принимает решение о доступе.
Субъект сообщает идентификатор
Идентификатор помогает найти запись о субъекте, но сам по себе ещё не доказывает, что запрос делает именно этот субъект.
1. Кто представился
Субъект
Пользователь, сервис или устройство сообщает логин, адрес почты, номер сотрудника или имя учётной записи.
2. Поиск и нормализация
Каталог / провайдер
Каталог сопоставляет идентификатор с записью, тенантом, статусом и источником правды.
3. Результат
Запись идентичности
Система получает нормализованную запись и утверждения об идентичности, но проверка подлинности ещё впереди.
Что важно помнить
- Идентификатор не равен доказанной личности.
- Запись должна быть уникальной в своём домене.
- Жизненный цикл записи важен не меньше входа в систему.
Трио: идентификация, аутентификация и авторизация
Идентификация
Кем субъект представился
- Субъект сообщает идентификатор: адрес почты, телефон, табельный номер или имя учётной записи сервиса.
- Идентификатор помогает найти запись, но не доказывает подлинность субъекта сам по себе.
- Запись должна быть уникальной в своём домене: тенанте, организации или системе.
Аутентификация
Доказательство подлинности
- Проверяются факторы: пароль, одноразовый код, , клиентский сертификат или ключ рабочей нагрузки.
- Результат аутентификации: подтверждённый субъект, метод проверки и .
- Для пользователей базой становятся и сценарии без единственного пароля.
Авторизация
Решение о доступе
- Проверяется право выполнить действие над ресурсом в конкретном контексте запроса.
- Используются , , или на базе OPA/Cedar.
- Решение зависит от субъекта, действия, ресурса, тенанта, времени, устройства и других признаков контекста.
BCP
OAuth 2.0 Security BCP
Рекомендации IETF по безопасной реализации OAuth 2.0.
Как это обычно реализуют сейчас
Пользователь → приложение/API
- проводит вход пользователя через OIDC или SAML.
- Приложение получает сессию, , и при необходимости .
- API выполняет : подпись, , , срок действия и время начала действия.
- выполняется в API или через отдельный механизм политики доступа.
Сервис → сервис
- подтверждает на уровне защищённого канала.
- безопаснее долгоживущих секретов.
- Для внутренних API применяйте детальную .
- должен отвечать, кто сделал запрос, куда, зачем и с каким решением политики.
Контур управления
- Единый провайдер идентичности и каталог связывают пользователей, группы, сервисы, статусы и источники истины.
- Выделяйте и для оценки правил вне кода приложения.
- , и снижают накопление лишних прав.
- и отключение учётной записи должны срабатывать при смене роли или статуса.
Основные протоколы и стандарты
OAuth 2.0 + PKCE
Зачем: Делегированный доступ к API от имени пользователя или приложения.
Где: Веб-приложения, мобильные клиенты и публичные клиенты без безопасного хранения секрета.
Важно: Используйте с ; лучше не применять в новых системах.
OpenID Connect (OIDC)
Зачем: Слой поверх OAuth 2.0.
Где: Единый вход, пользовательский вход и федерация с внешним провайдером идентичности.
Важно: описывает вход пользователя, а даёт ограниченное право вызвать API.
SAML 2.0
Зачем: Корпоративный .
Где: Интеграции с корпоративными порталами, старыми провайдерами идентичности и B2B/B2E-сценариями.
Важно: часто остаётся обязательным стандартом в крупных организациях.
WebAuthn / FIDO2
Зачем: Вход без пароля и устойчивость к фишингу.
Где: Клиентские приложения, админские панели и чувствительные операции.
Важно: , и ключи доступа помогают снизить риск кражи пароля.
mTLS + SPIFFE/SPIRE
Зачем: сервисов и рабочих нагрузок.
Где: Микросервисы, сервисная сетка и zero-trust-сети.
Важно: Комбинируйте с и короткоживущими сертификатами.
SCIM
Зачем: : создание, изменение и отключение учётных записей.
Где: B2B/B2E, синхронизация пользователей и групп между каталогом и приложениями.
Важно: SCIM не заменяет AuthN/AuthZ: он автоматизирует и .
Важно: — это формат токена, а не протокол аутентификации или авторизации. Без правил проверки, ротации ключей и отзыва доступа он сам по себе не решает задачу безопасности.
Частые ошибки в промышленной эксплуатации
- Путать и : успешный вход не означает право на любое действие.
- Хранить слишком долго или без строгой ротации ключей.
- Использовать одну роль администратора без детализации прав по операциям, ресурсам и тенантам.
- Проверять подпись , но игнорировать издателя, аудиторию, срок действия и время начала действия.
- Оставлять вечные сервисные ключи вместо .
- Не вести единый решений авторизации и событий доступа.
Дополнительные материалы
Связанные главы
- Подходы к управлению правами: ACL, RBAC, ABAC, ReBAC - Расширяет часть про через выбор модели политик и компромиссы ACL/RBAC/ABAC/ReBAC.
- Zero Trust: современный подход к безопасности архитектуры - Показывает, как и непрерывная проверка становятся базой доверия на каждом запросе.
- API Security Patterns - Применяет AuthN/AuthZ в API-контуре: , объектная авторизация и .
- Шифрование, ключи и TLS: как это работает на практике - Связывает идентичность с криптографической базой: сертификатами, PKI, и доверенными каналами.
- Secrets Management Patterns - Дополняет тему жизненным циклом секретов и ключей, без которого безопасная в промышленной эксплуатации нестабильна.