Аутентификация устанавливает, кто обращается к API, авторизация — какие действия и объекты ему доступны. Для пользовательского входа подходит OIDC с Authorization Code и PKCE; для сервисов — подходящий механизм машинной идентификации, например OAuth client credentials или mTLS. JWT — формат токена, а не протокол аутентификации. Права проверяют на сервере для каждого действия и объекта. Дополняют защиту HTTPS, ограничениями запросов, валидацией и безопасным аудитом.
Что применить для безопасности API? Как авторизовать клиента и взаимодействие host-to-host?
Аутентификация пользователей и сервисов, серверная проверка прав, безопасное применение токенов и дополнительные меры защиты API.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Сначала определю, кто вызывает API: браузер, мобильное приложение, другой сервис или внешняя интеграция. Аутентификация подтверждает идентичность, а авторизация проверяет разрешённые действия. Валидный токен не означает право читать любой документ: сервер должен проверять доступ к каждому объекту и операции, включая принадлежность организации. OWASP: объектная авторизация.
Для пользовательского входа можно использовать OpenID Connect поверх OAuth 2.0. Для публичных клиентов, которые не могут надёжно хранить общий секрет, подходит Authorization Code с PKCE. ID token сообщает клиенту результат аутентификации; для обращения к API предназначен access token с нужной аудиторией и разрешениями. Это разные назначения, даже если оба токена представлены как JWT. OpenID Connect, OAuth Security BCP.
Для host-to-host выбирают механизм под инфраструктуру: например, OAuth client credentials для конфиденциального клиента или mTLS для идентификации по сертификату. Машинная учётная запись получает минимальные права; она не становится автоматически представителем пользователя. API key может подходить для ограниченной интеграции, но не заменяет полноценную модель прав. HMAC-подпись требует защиты от повторной отправки, а VPN и список разрешённых IP — лишь дополнительные барьеры. Client credentials, OAuth и mTLS.
JWT — формат, не готовая схема безопасности. Проверяют подпись доверенным алгоритмом, издателя, аудиторию и срок действия; заранее продумывают ротацию ключей и отзыв доступа. Независимо от токенов нужны HTTPS, проверка входных данных, лимиты размера и частоты запросов, безопасные ошибки и аудит без паролей и токенов. При cookie-аутентификации отдельно учитывают CSRF. Конкретный набор выбирают по модели угроз, а не собирают все механизмы одновременно. OWASP: безопасность REST API.