Identity, authentication и authorization слишком часто сливаются в одну тему, хотя архитектурно это три разных слоя доверия.
Глава раскладывает их на последовательность решений о личности пользователя, федерации, сессиях, токенах и политике доступа, а OAuth 2.0/OIDC, SAML, WebAuthn и mTLS встают на свои места в этой схеме.
На интервью и в архитектурных разборах она помогает четко отделять login flow от access policy, объяснять trust assumptions и не путать user auth с service-to-service trust.
Практическая польза главы
Практика проектирования
Используйте материал по идентификации, аутентификации и авторизации в modern identity stack, чтобы формировать архитектурные security-требования до этапа реализации.
Качество решений
Проверяйте решения через модель угроз, security invariants и управляемость контролей в production, а не только через чеклист соответствия.
Interview articulation
Стройте ответ в формате threat -> control -> residual risk, показывая связь между бизнес-сценарием и техническими мерами защиты.
Trade-off framing
Явно описывайте компромиссы по идентификации, аутентификации и авторизации в modern identity stack: UX friction, latency overhead, стоимость сопровождения и требования compliance.
Spec
OpenID Connect Core
Базовая спецификация OIDC для user authentication поверх OAuth 2.0.
В продакшене чаще всего ломаются не криптографические алгоритмы, а границы ответственности: где заканчивается идентификация, где начинается аутентификация, и в каком месте принимать решение авторизации. Эта глава фиксирует практическую модель Identification Authentication Authorizationи показывает, какие протоколы сегодня обычно используют для user и service сценариев.
Трио: Identification - AuthN - AuthZ
Identification
Кем ты представился
- Субъект сообщает идентификатор: email, phone, employee ID, service account name.
- Идентификатор не доказывает личность сам по себе.
- Должен быть уникальным в своем домене (tenant/org/system).
Authentication (AuthN)
Ты действительно тот, за кого себя выдаешь
- Проверка факторов: пароль, OTP, passkey (WebAuthn), клиентский сертификат.
- Результат AuthN: подтвержденная identity + метод и уровень уверенности.
- Текущий стандарт для пользователей: MFA и отказ от password-only сценариев.
Authorization (AuthZ)
Что тебе разрешено делать
- Проверка прав на действие над ресурсом в конкретном контексте.
- RBAC, ABAC, ReBAC или policy-as-code (OPA/Cedar).
- Решение AuthZ всегда зависит от subject + action + resource + context.
BCP
OAuth 2.0 Security BCP
Рекомендации IETF по безопасной реализации OAuth 2.0.
Как это обычно реализуют сейчас
User -> App/API
- IdP (OIDC) проводит аутентификацию пользователя.
- Приложение получает session или токены и обновляет их по безопасной политике.
- API проверяет access token (issuer, audience, expiry, signature).
- AuthZ выполняется на API или в выделенном policy engine.
Service -> Service
- mTLS для подтверждения service identity на сетевом уровне.
- Короткоживущие credentials/tokens вместо long-lived secrets.
- Fine-grained AuthZ по policy-as-code для внутренних API.
- Полный audit trail: кто, куда, зачем и с каким решением policy.
Control Plane
- Централизованный IdP + каталог identities.
- Отдельный policy store и policy decision point.
- JIT access, least privilege, periodic access review.
- Автоматический revoke и deprovision при изменении роли/статуса.
Основные протоколы и стандарты
OAuth 2.0 + PKCE
For: Delegated access to APIs
Where: Web/mobile/public clients
Note: Используйте Authorization Code Flow + PKCE; implicit flow не использовать.
OpenID Connect (OIDC)
For: Authentication layer on top of OAuth 2.0
Where: SSO, user login, identity claims
Note: ID Token про identity, Access Token про доступ к API.
SAML 2.0
For: Enterprise SSO
Where: Legacy enterprise integrations
Note: Часто встречается в корпоративных IdP/SSO-порталах.
WebAuthn / FIDO2
For: Passwordless and phishing-resistant auth
Where: End-user authentication
Note: Passkeys как modern baseline для user auth в клиентских приложениях.
mTLS + workload identity
For: Service-to-service authentication
Where: Microservices and zero-trust networks
Note: Комбинируйте с SPIFFE/SPIRE или аналогичной системой доверия.
SCIM
For: Identity provisioning lifecycle
Where: B2B/B2E user lifecycle
Note: Не AuthN/AuthZ протокол, а стандарт provisioning/deprovisioning.
Важно: JWT — это формат токена, а не протокол аутентификации/авторизации. Без валидных правил проверки и управления ключами JWT сам по себе не решает задачу безопасности.
Частые ошибки в продакшене
- Путать AuthN и AuthZ: успешный login не означает право на любое действие.
- Хранить access tokens слишком долго или без строгой ротации ключей.
- Использовать одну роль 'admin' без детализации прав по операциям и ресурсам.
- Проверять подпись JWT, но не проверять issuer/audience/expiry/nbf.
- Оставлять 'вечные' сервисные ключи вместо короткоживущих identity-based credential.
- Не вести единый audit лог решений авторизации и событий доступа.
Дополнительные материалы
Связанные главы
- Подходы к управлению правами: ACL, RBAC, ABAC, ReBAC - Расширяет AuthZ-часть через выбор модели политик и объясняет trade-offs между ACL/RBAC/ABAC/ReBAC.
- Zero Trust: современный подход к безопасности архитектуры - Показывает, как identity становится основой непрерывной проверки и policy enforcement на каждом запросе.
- API Security Patterns - Применяет AuthN/AuthZ в API-контуре: token validation, object-level authorization и deny-by-default.
- Шифрование, ключи и TLS: как это работает на практике - Связывает identity с криптографической базой: сертификаты, PKI, mTLS и доверенные каналы для сервисов.
- Secrets Management Patterns - Дополняет тему жизненным циклом секретов и ключей, без которого безопасный AuthN в продакшене нестабилен.