Аутентификация и авторизация в API
аутентификация проверяет, кто делает запрос; авторизация — имеет ли он право на действие.
Почему это важно: Небезопасная аутентификация — одна из топ-10 уязвимостей по OWASP. Понимание разных подходов необходимо для выбора правильного механизма под конкретную задачу.
Главная идея
API-ключи подходят для server-to-server; JWT — для stateless-аутентификации; OAuth 2.0 — для делегированного доступа от имени пользователя.
Как это выглядит на практике
- Клиент отправляет POST /sessions с credentials и получает JWT-токен.
- Все последующие запросы включают заголовок Authorization: Bearer .
- Сервер верифицирует токен и извлекает из него идентификатор пользователя.
- Авторизация проверяет права пользователя на конкретный ресурс.
Что происходит под капотом
- JWT (JSON Web Token) состоит из трёх частей: header.payload.signature — подписывается секретом или RSA-ключом.
- JWT stateless: сервер не хранит сессию; информация о пользователе внутри токена.
- Проблема JWT: отозвать конкретный токен до истечения срока сложно — нужен blacklist или короткий TTL.
- OAuth 2.0 — протокол делегированного доступа: пользователь разрешает приложению действовать от его имени без передачи пароля.
Типичные ошибки и заблуждения
- Ошибка: JWT безопасен по умолчанию. Алгоритм 'none' в старых библиотеках позволял обойти подпись.
- Ошибка: аутентификация и авторизация — одно и то же. Аутентификация — 'кто ты', авторизация — 'что тебе разрешено'.
- Ошибка: API-ключи достаточно передавать в URL. URL логируются; ключи должны передаваться в заголовках.
- Ошибка: OAuth = авторизация. OAuth — протокол делегирования доступа, а не только авторизации.
Ключевые выводы
- Аутентификация ≠ авторизация: разные концепции с разной реализацией.
- Токены передаются через заголовок Authorization, а не через URL.
- JWT stateless; для отзыва нужен blacklist или короткий срок жизни.
- HTTPS обязателен при любой схеме аутентификации.
Термины урока
Связь с работой backend-разработчика
Для внутренних API и server-to-server используйте API-ключи или service tokens. Для пользовательских приложений — JWT с коротким TTL и refresh tokens. Для 'войти через Google/GitHub' — OAuth 2.0.
Мини-разбор реальной ситуации
API возвращает токен с expiry через 24 часа. Сотрудник увольняется. Его токен остаётся валидным ещё 24 часа. Решение: short-lived access token (15 мин) + refresh token с возможностью отзыва.
Что запомнить
- Аутентификация говорит 'кто ты', авторизация — 'что тебе можно'.
- HTTPS обязателен — без него любой механизм аутентификации бесполезен.
- Короткий срок жизни токена + возможность отзыва — основа безопасной аутентификации.
Итог
Безопасная аутентификация API — это не сложно, если понимать разницу между подходами и выбирать правильный инструмент под задачу.