JWT, OAuth 2.0 и API Keys часто звучат рядом, поэтому новички быстро начинают путать их между собой. Это плохая привычка, потому что это не три варианта одного и того же, а три разных механизма с разным назначением.
- →JWT - это формат токена
- →OAuth 2.0 - это framework делегированного доступа
- →API Key - это способ идентифицировать клиента или интеграцию
Для QA это важно не как "теория для архитектора", а как базовая навигация по access-механизмам. Если ты не различаешь эти вещи, тебе трудно понять, где реально ошибка: в токене, в правах, в flow получения доступа или в том, что команда вообще выбрала неподходящий механизм защиты.
JWT
JWT, или JSON Web Token, - это компактный формат токена, в котором обычно лежат claims, то есть утверждения о пользователе, клиенте или сессии. Чаще всего он используется как bearer token: клиент получает токен и потом прикладывает его к запросам.
Важно понимать: JWT - это не "авторизация" и не "OAuth". Это именно формат представления данных в токене.
- →sub - кто субъект
- →iss - кто выдал токен
- →aud - для кого он предназначен
- →exp - когда истекает
- →iat - когда выдан
- →роли, scope или другие custom claims
Сам по себе JWT удобен тем, что он компактный и хорошо подходит для stateless-сценариев. Но отсюда же растёт и риск неправильного обращения с ним. Очень частая ошибка в командах - относиться к JWT как к "доверенному JSON", который можно просто декодировать и считать истиной. Для QA это значит, что нужно смотреть не только на payload, но и на то, как система валидирует токен: срок жизни, issuer, audience, подпись, отозван ли токен, не используется ли он вне своего контекста.
Ещё важный момент: JWT не обязан быть зашифрован. Очень часто он просто подписан. Это значит, что payload может быть читаемым. Поэтому в JWT не стоит ожидать безопасного хранения чувствительных данных только потому, что строка выглядит "сложно".
OAuth 2.0
OAuth 2.0 - это framework, который позволяет одной системе получить ограниченный доступ к ресурсу от имени пользователя или клиента без передачи логина и пароля напрямую. Это очень важная идея: OAuth решает задачу делегирования доступа, а не просто "входа в систему".
Например, когда приложение просит доступ к твоему Google Drive или календарю, оно часто использует именно OAuth 2.0. Пользователь аутентифицируется у провайдера, подтверждает разрешения, а приложение получает ограниченный токен доступа.
Для QA здесь важно не заучивать все grant types как справочник, а понимать логику:
- →кто выдаёт токен
- →кто его запрашивает
- →к какому ресурсу он даёт доступ
- →какие scope у этого токена
- →каков срок жизни
- →можно ли его обновить
- →как выглядит revoke или отзыв доступа
Очень частая путаница у новичков: считать, что OAuth 2.0 сам по себе отвечает за аутентификацию пользователя. На практике для identity-сценариев обычно добавляется OpenID Connect. Поэтому если команда говорит "у нас OAuth-логин", QA полезно уточнить, где именно там identity layer и что именно система считает доказательством личности пользователя.
API Keys
API Key - это более простой механизм. Обычно это уникальный ключ, по которому система понимает, кто к ней обращается: приложение, клиент, партнёрская интеграция, внутренний сервис или скрипт.
- →server-to-server интеграции
- →ограничение доступа к API
- →учёт потребления
- →rate limiting
- →разделение клиентов и тарифов
Но здесь важно не переоценивать API Keys. Они хорошо подходят для идентификации клиента, но обычно недостаточны сами по себе для защиты чувствительных пользовательских операций. API Key не равен полноценной модели user authorization.
Для QA это значит простую вещь: если система защищает высокорисковые действия только API key без дополнительных ограничений, это повод внимательно смотреть на архитектурное решение. Особенно если ключ можно легко утянуть из клиента, логов, примеров кода или CI-конфигов.
Чем они отличаются по смыслу
- →JWT отвечает на вопрос "в каком виде передаётся токен"
- →OAuth 2.0 отвечает на вопрос "как этот доступ был получен и на каких условиях"
- →API Key отвечает на вопрос "какой клиент или интеграция к нам пришли"
В реальной системе они могут использоваться вместе.
- →access token может быть JWT
- →OAuth flow может закончиться выдачей JWT access token
- →отдельный внутренний сервис может использовать API key, а не OAuth
- →публичное API может требовать API key для тарифа и ещё bearer token для доступа к пользовательским данным
То есть это не взаимоисключающие сущности. Это разные слои модели доступа.
Что важно QA
При проверке JWT полезно смотреть на:
- →срок жизни токена
- →поведение после exp
- →корректность aud и iss
- →состав claims
- →реакцию системы на повреждённый, подменённый или просроченный токен
- →logout, revoke и обновление токенов
При проверке OAuth 2.0 важно смотреть на:
- →правильность выбранного flow
- →scope и их ограничения
- →refresh flow
- →revoke access
- →redirect URI safety
- →поведение при отказе пользователя
- →что происходит, если токен получен, но прав недостаточно
При проверке API keys полезно смотреть на:
- →где и как ключ передаётся
- →можно ли использовать отозванный ключ
- →есть ли rotate и revoke
- →есть ли rate limiting
- →не даёт ли ключ слишком широкий доступ
- →не утёк ли он в клиентский код, логи или документацию
Практический пример
Представь сервис, который подключается к календарю пользователя.
Если пользователь даёт приложению доступ к своему календарю через Google или Microsoft, здесь логично ожидать OAuth 2.0 flow. После согласия приложение получает access token. Этот токен может быть JWT, а может и не быть - это уже зависит от реализации.
Что здесь важно QA:
- →приложение запрашивает только нужные scope
- →пользователь может отказать в доступе и система корректно это обрабатывает
- →access token истекает так, как ожидается
- →refresh работает корректно
- →после revoke приложение действительно теряет доступ
- →нельзя использовать токен для другого ресурса или другого пользователя
Если бы такая интеграция строилась только на одном API key, это уже был бы совсем другой и, скорее всего, неверный security-подход.
Что должен вынести QA из этой темы
- →JWT, OAuth 2.0 и API Keys - это не одно и то же.
- →JWT - формат токена, а не полноценная access-модель.
- →OAuth 2.0 - framework делегированного доступа, а не просто "логин".
- →API Key чаще идентифицирует клиента, а не конечного пользователя.
- →Один из главных навыков QA здесь - понимать, какой механизм решает какую задачу и где его границы.
Что ещё почитать
- →Внутри базы: Аутентификация и авторизация
- →Внутри базы: HTTP и HTTPS
- →Внешний материал: OAuth 2.0 Simplified