Аутентификация и авторизация: различия
↑ 5.5 Аутентификация и доступ: Keycloak, SSO, ACL · → Следующая
Зачем это на собесе
Базовый вопрос безопасности; нужно чётко разделять «кто вы» и «что вам можно».
Объяснение
| Аутентификация (authN) | Авторизация (authZ) | |
|---|---|---|
| Вопрос | Кто вы? | Что вам разрешено? |
| Способы | пароль, MFA, SSO, biometrics, passkeys | роли, права, политики, владение ресурсом |
| Результат | идентичность (пользователь, claims) | решение allow/deny |
| Где проверяется | провайдер идентичности + сервер | сервер (обязательно), клиент — для UX |
Принципы безопасности:
- Клиент не является доверенной стороной. Скрытие кнопки — UX; реальная проверка на сервере для каждого запроса.
- Принцип наименьших привилегий, deny by default.
- Не изобретайте свою криптографию и схемы: используйте проверенные протоколы (OIDC) и провайдеров (Keycloak, Auth0, Entra ID).
- Многофакторная аутентификация и защита от перебора (rate limiting, lockout).
- Короткоживущие токены, отзыв, аудит.
Типовая схема SPA + API:
sequenceDiagram participant U as Пользователь participant SPA participant IdP as Keycloak (OIDC) participant API U->>SPA: открыть приложение SPA->>IdP: редирект на /authorize (PKCE) IdP->>U: форма входа / SSO IdP->>SPA: code SPA->>IdP: обмен code на токены SPA->>API: запрос с access token API->>API: проверка подписи/aud/scope/прав API-->>SPA: данные
Ответственность фронтенда: инициировать вход/выход, безопасно хранить/обновлять токены, добавлять их в запросы, обрабатывать 401/403, управлять UX по правам (маршруты, меню, кнопки).
Нюансы и подводные камни
- Проверка прав только на клиенте — уязвимость (запрос обходит UI).
- Путаница 401 и 403.
- «Роли» в JWT на клиенте можно прочитать, но нельзя доверять им для защиты.
- Хранение паролей и токенов «как получится».
Практика
- Нарисуйте схему входа вашего приложения и отметьте, где проверяются права.
- Проверьте, что API отклоняет запрос без токена и с чужими правами.
Вопросы с ответами
Разница аутентификации и авторизации?
Аутентификация устанавливает личность, авторизация решает, что этой личности разрешено.
Почему проверки на фронтенде недостаточны?
Клиентский код можно обойти; сервер обязан проверять права при каждом запросе.