Bearer Token

Bearer Token — это криптографический токен доступа, используемый в протоколах аутентификации и авторизации, в частности в рамках спецификации OAuth 2.0. Основной принцип работы Bearer Token заключается в том, что предъявитель (bearer) этого токена получает доступ к защищённым ресурсам без необходимости предоставления дополнительных доказательств своей личности (например, пароля или ключа). Токен представляет собой строку символов, которая передаётся в HTTP-заголовке Authorization при запросе к серверу.

История и стандартизация

Концепция Bearer Token была формализована в рамках развития протокола OAuth 2.0, который был опубликован в виде спецификации RFC 6749 в октябре 2012 года. До этого использовались различные механизмы аутентификации, такие как Basic Auth (передача логина и пароля в заголовке) и Digest Auth (хеширование). Bearer Token стал ответом на потребность в более гибком и безопасном способе делегирования доступа, особенно в контексте веб-приложений и API.

Сам термин «bearer» (предъявитель) заимствован из финансовой сферы, где bearer bonds (облигации на предъявителя) дают право владельцу на получение дохода без регистрации. В информационной безопасности это означает, что любой, кто владеет токеном, может использовать его для доступа к ресурсу. Спецификация использования Bearer Token в OAuth 2.0 описана в RFC 6750 (2012 год), где определены способы передачи токена в HTTP-запросах.

Устройство и формат

Bearer Token не имеет строго определённого внутреннего формата — это может быть произвольная строка, генерируемая сервером авторизации. Однако на практике чаще всего используются два подхода:

1. Обычный (opaque) токен

Это случайная последовательность символов, которая не содержит никакой информации о пользователе или правах доступа. Сервер хранит связь между токеном и данными сессии в своей базе данных (например, в реляционной БД или Redis). При получении запроса сервер проверяет токен по базе и извлекает соответствующие права.

2. JWT (JSON Web Token)

JWT — это самодостаточный токен, который содержит в себе полезную нагрузку (payload) в формате JSON, закодированную в Base64url. Структура JWT включает три части, разделённые точками:

• Header — метаданные о типе токена и алгоритме подписи (например, {"alg": "HS256", "typ": "JWT"}).
• Payload — утверждения (claims), такие как идентификатор пользователя (sub), время выпуска (iat), время истечения (exp), область доступа (scope) и другие.
• Signature — цифровая подпись, созданная с использованием секретного ключа (симметричное шифрование) или приватного ключа (асимметричное шифрование, например, RS256).

JWT позволяет серверу проверять токен без обращения к базе данных, что ускоряет обработку запросов. Однако он не может быть отозван до истечения срока действия, если не реализован механизм чёрных списков.

Передача в HTTP-запросах

Согласно RFC 6750, Bearer Token передаётся в HTTP-заголовке Authorization с типом Bearer. Пример:

`` GET /api/resource HTTP/1.1 Host: example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... ``

Альтернативные способы передачи (менее предпочтительные из-за безопасности):

• В теле POST-запроса с параметром access_token.
• В URL-параметре запроса (?access_token=...), что не рекомендуется из-за риска утечки через логи сервера или реферер.

Применение

Bearer Token широко используется в современных веб-приложениях и API для реализации следующих сценариев:

Аутентификация и авторизация в REST API

Большинство публичных и внутренних API (например, от Google, GitHub, VK) используют Bearer Token для доступа. Пользователь получает токен после успешной аутентификации (например, через OAuth 2.0 flow) и затем передаёт его в каждом запросе.

Single Page Applications (SPA)

В SPA (React, Vue, Angular) токен хранится в памяти браузера или в localStorage/sessionStorage и отправляется с каждым запросом к серверу. Это позволяет избежать хранения паролей на стороне клиента.

Микросервисная архитектура

Внутри микросервисов Bearer Token (часто в формате JWT) используется для передачи контекста аутентификации между сервисами. Сервис, получивший токен, может проверить его подпись и извлечь данные о пользователе без обращения к центральному серверу аутентификации.

Мобильные приложения

Мобильные приложения получают токен при входе пользователя и используют его для доступа к серверным ресурсам. Токен обычно хранится в защищённом хранилище устройства (например, Keychain на iOS или EncryptedSharedPreferences на Android).

Безопасность

Bearer Token имеет ряд уязвимостей, которые требуют тщательной реализации:

Утечка токена

Поскольку токен даёт доступ к ресурсу любому, кто им владеет, его перехват (например, через MITM-атаку, XSS или логирование) равносилен компрометации учётной записи. Для защиты необходимо:

• Использовать HTTPS для шифрования трафика.
• Не передавать токен в URL.
• Ограничивать время жизни токена (обычно от 15 минут до нескольких часов).
• Использовать refresh token для получения нового access token без повторного ввода пароля.

Отзыв токена

Opaque токены можно отозвать, удалив их из базы данных. JWT-токены, напротив, не могут быть отозваны до истечения срока действия, если не реализован механизм чёрных списков (например, Redis с TTL). Это делает JWT менее подходящим для сценариев, где требуется немедленный отзыв доступа (например, при увольнении сотрудника).

CSRF-атаки

Если токен хранится в cookie, он может быть украден через CSRF. Для защиты рекомендуется хранить токен в заголовке Authorization, а не в cookie, или использовать SameSite-атрибуты.

Повторное использование

Bearer Token не имеет встроенной защиты от повторного использования (replay attack). Для снижения риска применяются короткие сроки жизни и привязка к IP-адресу или User-Agent (хотя это снижает мобильность).

Критика и ограничения

Основная критика Bearer Token связана с его фундаментальным свойством: любой владелец токена получает доступ. Это делает систему уязвимой к краже токена, особенно в средах с низким уровнем безопасности (например, в публичных Wi-Fi сетях без HTTPS). Альтернативные механизмы, такие как Proof of Possession (PoP) token или DPoP (Demonstration of Proof-of-Possession), требуют от клиента доказательства владения секретным ключом, что усложняет реализацию, но повышает безопасность.

Также отмечается, что JWT-токены, несмотря на популярность, могут привести к проблемам с производительностью при большом размере payload (например, если включены все права пользователя). Кроме того, неправильная реализация проверки подписи (например, использование алгоритма none или слабого ключа) может привести к полной компрометации системы.

Примеры использования

• GitHub API: для доступа к репозиториям требуется передача Personal Access Token в заголовке Authorization: Bearer <token>.
• Google Cloud API: сервисные аккаунты используют JWT-токены, подписанные приватным ключом, для аутентификации.
• VK API: после авторизации через OAuth 2.0 пользователь получает access token, который передаётся в параметрах запроса или заголовке.

Источники

• RFC 6749 — The OAuth 2.0 Authorization Framework (2012)
• RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage (2012)
• RFC 7519 — JSON Web Token (JWT) (2015)
• RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP) (2023)
• Книга: «OAuth 2.0: The Definitive Guide» (Charles Bihis, 2020)