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