JWT против OAuth: основные различия, как они работают вместе и лучшие практики

Если ты только начинаешь разбираться в аутентификации и разрабатываешь приложение с логинами, платежами или пользовательскими данными, то наверняка сталкивался с терминами JWT и OAuth. Они могут показаться сложными и только «для бэкенда», но это темы не только для инженеров по безопасности.

В эпоху API, интеграций с третьими сторонами и новых технологий вроде ИИ, MCP и агентных систем эти две технологии напрямую влияют на удобство, безопасность и рост твоего продукта. Базовое понимание означает, что ты сможешь:

• Проектировать функции, которые изначально безопасны
• Эффективно общаться с инженерной командой
• Принимать более обоснованные продуктовые решения о механизмах аутентификации и пользовательских сценариях
• Избегать дорогостоящих ошибок в безопасности, которые разрушают доверие пользователей

Например, в последней спецификации MCP система авторизации строится на проверенных стандартах:

• OAuth 2.1 IETF Draft (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Authorization Server Metadata (RFC8414)
• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
• OAuth 2.0 Protected Resource Metadata (RFC9728)

Почему это важно#

Даже если ты никогда не пишешь бэкенд-код:

• Разработчики учатся защищать API, управлять сессиями и интегрироваться со сторонними сервисами.
• Продуктовые менеджеры получают терминологию для обсуждения логики логина, интеграций и соответствия стандартам с командами и партнерами.
• Основатели и небольшие команды избегают создания хрупких систем логина, которые ломаются при интеграциях или оставляют продукт уязвимым для атак.

JWT против OAuth: две ключевые концепции#

JWT (JSON Web Token) и OAuth (Open Authorization) часто используются вместе, но служат разным целям.

Представь себе так:

• OAuth — это способ выдать кому-то ключи, но только в те комнаты, куда у него есть доступ.
• JWT — это удостоверение личности, подтверждающее, кто это и что он может делать.

В следующем разделе мы рассмотрим их бок о бок, чтобы ты ясно увидел отличия и то, как они друг друга дополняют.

Что такое OAuth 2.0?#

OAuth 2.0 — это широко используемый фреймворк авторизации, который позволяет приложению (клиенту) получать доступ к ресурсам пользователя с ограниченными правами, не получая при этом его пароли или другие учетные данные.

Основные роли в OAuth#

• Клиент: Приложение, которое запрашивает доступ.
• Владелец ресурса: Обычно пользователь, дающий разрешение.
• Сервер авторизации: Выдает access токены после разрешения.
• Сервер ресурса: Хранит защищенные ресурсы и проверяет токены

Популярные типы грантов (потоков) OAuth#

• Authorization Code Grant: Самый безопасный и рекомендуемый, особенно с PKCE для браузеров, SPA и мобильных приложений.
• Implicit Grant: Сейчас не рекомендуется в OAuth 2.1 по причинам безопасности.
• Resource Owner Password Credentials (ROPC): Прямой обмен логином и паролем на токен; менее безопасно.
• Client Credentials Grant: Для сервер-сервер или machine-to-machine взаимодействия.
• Device Flow: Для устройств без клавиатуры (например, смарт-ТВ), когда пользователь авторизуется с другого устройства.

Что такое JWT (JSON Web Token)?#

JWT — это открытый стандарт (RFC 7519) для безопасной передачи утверждений (claims) между двумя сторонами в компактном, безопасном для URL виде.

Структура JWT#

JWT состоит из трех частей, закодированных в base64url и разделенных точками (.):

1. Header: Определяет алгоритм (например, HS256, RS256) и тип токена (JWT).
2. Payload: Содержит claims, например:
   • iss (issuer — издатель)
   • sub (subject, например, ID пользователя)
   • aud (audience — предназначение)
   • exp (expiration time — время истечения)
   • Пользовательские claims при необходимости
3. Signature – Гарантирует, что токен не был изменен.

Пример:

Пример JWT#

Вот пример типичного JWT в закодированном виде и как выглядит его структура при декодировании.

Закодированный JWT (Base64URL)

Он состоит из трех частей, разделённых точками: header.payload.signature

Структура при декодировании

• Header

• Payload

Payload содержит claims

• Signature

Signature гарантирует целостность токена.

Ключевые характеристики#

• Самодостаточность: Вся необходимая информация внутри токена.
• Без состояния: Нет необходимости хранить сессии на сервере.
• Подписан: (и при желании зашифрован) для проверки подлинности.

JWT против OAuth: основные отличия#

Кратко:

• JWT это контейнер: как паспорт с личной информацией.
• OAuth это система: как пограничный контроль, который решает, кому выдать паспорт и куда можно попасть.

Когда использовать только JWT#

Используй только JWT, если:

• Аутентификация внутри одной системы, когда твое приложение само выдает и проверяет токены, не обращаясь к внешнему провайдеру.
• Управление сессиями без состояния, чтобы проверять личность пользователя без хранения сессии на сервере.
• Простая аутентификация API для внутренних API, которым достаточно базовой проверки прав.
• Высокопроизводительная валидация, чтобы сервер ресурсов мог проверять токен локально, без обращения к серверу авторизации.

Пример:

SPA и backend API, которые ты полностью контролируешь. API выдает JWT с субъектом (ID пользователя), ролью и временем истечения (exp).

Когда использовать только OAuth#

Используй OAuth без JWT, если:

• Не нужны самодостаточные токены, а подойдут непрозрачные токены, которые требуют проверки на сервере.
• Нужно, чтобы сервер ресурсов всегда сверялся с сервером авторизации перед выдачей доступа.
• Работаешь с устаревшей или регулированной системой, где JWT не подходит.
• Цель — делегированная авторизация с безопасной выдачей ограниченного доступа сторонним приложениям.

Пример:

API выдает непрозрачные access токены и проверяет каждый запрос на стороне сервера авторизации.

Когда использовать JWT и OAuth вместе#

Используй оба, если:

• У тебя несколько сервисов или API и нужен OAuth для безопасного потока, а JWT для верифицируемых токенов между сервисами.
• Ты предоставляешь сторонний логин, например «Войти через Google», когда OAuth управляет согласием, а JWT содержит access или ID токен.
• Архитектура микросервисная, и каждый сервис проверяет JWT локально.
• Нужна масштабируемость благодаря модели делегирования OAuth и безсессионной верификации JWT.

Пример:

Твое приложение позволяет пользователям логиниться через Google. OAuth управляет процессом авторизации, Google выдает JWT (access token), и твои API проверяют его локально перед возвратом данных.

Как JWT и OAuth работают вместе#

В современных системах аутентификации/авторизации:

1. OAuth управляет процессом выдачи доступа.
2. Сервер авторизации выдает access token: часто это JWT.
3. JWT отправляется с API-запросами как доказательство личности и прав доступа.

Особые токены в OAuth#

• ID token: Используется в OpenID Connect для подтверждения личности пользователя; всегда JWT.
• Access token: Может быть JWT или непрозрачным токеном.

Лучшие практики работы с JWT и OAuth#

• Используй HTTPS для защиты токенов при передаче.
• Делай короткое время жизни JWT; для долгих сессий используй refresh токены.
  • https://auth.wiki/offline-access.
• Проверяй подпись перед доверием к claims.
• Проверь aud claim чтобы убедиться, что токен предназначен именно твоему приложению.
• Не храни токены в localStorage, если есть риск XSS; лучше используй безопасные cookies.

Итоги#

• OAuth 2.0 определяет как получать и использовать токены.
• JWT определяет как должен выглядеть токен и как он несет информацию.
• Они дополняют друг друга, а не взаимозаменяемы.

Большинство современных API используют OAuth для авторизационных потоков и JWT как формат токена. Понимание обоих поможет тебе проектировать безопасные и масштабируемые системы аутентификации.