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 лог решений авторизации и событий доступа.
Связанные материалы
Для high-risk систем обязательно добавляйте threat modeling и security testing в CI/CD, а не только "правильный" выбор протокола.