▫️ Аутентификация (Authentication) — подтверждение, что это действительно тот клиент / пользователь, за кого он себя выдаёт.
Проверяется при входе в систему, когда пользователь предоставляет ключи доступа:
+ логин+пароль
+ токен
Если аутентификация не пройдена, то API должен вернуть ошибку HTTP-401.
▫️ Авторизация (Authorization) — проверка прав аутентифицированного клиента: что ему можно, а что нет.
При выполнении очередного действия в системе, например - удаление мероприятия в календаре, надо проверить, что у него есть права на это (он его создал, оно в его календаре).
Если нет прав, то API должен вернуть ошибку HTTP-403.
▫️ Основные схемы аутентификации
🔑 API-ключи
• Простая пара «ключ=значение» в заголовке X-API-Key.
• Быстро настраивается, но статичен и часто уязвим (нет ротации, нет TTL).
Пример Header:
X-API-Key: 123e4567-e89b-12d3-a456-426614174000
🔒 HTTP Basic Auth
• Передаёт логин/пароль закодированным в Base64 в заголовке Authorization: Basic <credentials>.
• Использовать только по HTTPS.
Пример Header:
Authorization: Basic bXlVc2VyOm15UGFzc3dvcmQ=
🚀 JWT (JSON Web Token)
• Короткоживущий токен с подписанным payload’ом (claims).
• Передача в заголовке Authorization: Bearer <token>.
• Удобен для распределённых систем: нет обращений к БД при каждом запросе.
🌐 OAuth 2.0
• Полноценный фреймворк (стандарт) для выдачи и обновления токенов: Access + Refresh Token.
• Подходит для публичных API и сторонних интеграций.
• Поддерживает разные гранты (Client Credentials, Authorization Code и другие).
▫️ В описании API-метода обязательно указать:
+ какую схему аутентификации поддерживаем
+ формат токена (JWT, UUID и т.д.)
+ куда передавать (заголовок, query-параметр, cookie)
+ список возможных ошибок и их тело (JSON-ответ)
Нужно глубже погрузиться в тему аутентификации
и авторизации в API?
🎧 Подкаст и статья тут 🙂
#RestApiGA