Bearer-токен (от англ. "bearer" — предъявитель) — тип токена доступа, где любой, кто владеет строкой токена, получает права, закодированные в ней. Сервер не проверяет, кто именно предъявляет токен — только его подлинность и срок действия. Схема определена в OAuth 2.0 (RFC 6750, октябрь 2012).
Как работает Bearer-токен
Клиент включает токен в заголовок каждого HTTP-запроса:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQyIiwiZXhwIjoxNzE5Mzk4NDAwfQ.signatureСервер проверяет подпись токена и срок действия (exp-claim). Если токен валиден — возвращает ресурс. Если истёк — отвечает 401 Unauthorized с заголовком WWW-Authenticate: Bearer error="invalid_token". Если отсутствует — 401 с WWW-Authenticate: Bearer realm="API".
Чаще всего bearer-токены реализуются как JWT (JSON Web Token, RFC 7519). JWT состоит из трёх частей, закодированных в Base64url и разделённых точками: заголовок (алгоритм подписи), полезная нагрузка (claims: sub, exp, iat, roles) и подпись. Сервер проверяет подпись публичным ключом без обращения к базе данных.
Виды Bearer-токенов
- Opaque token — случайная строка (UUID или Base64-encoded bytes). Сервер проверяет через базу данных или endpoint интроспекции (
POST /oauth/introspect). Легко отозвать, но требует хранилища и дополнительного HTTP-запроса на каждую проверку. - JWT — самодостаточный токен с подписью. Сервер проверяет без обращения к базе. Отозвать сложнее — нужен token blocklist или уменьшение срока жизни.
- Access token + refresh token — access token живёт 15–60 минут (короткий срок снижает ущерб при краже), refresh token — дни или недели. При истечении access token клиент использует refresh token для получения нового без повторного логина.
Bearer-токены vs другие методы авторизации
| Метод | Передача | Безопасность | Применение |
|---|---|---|---|
| Basic Auth | login:password в каждом запросе | Низкая (пароль в каждом запросе) | Внутренние API, legacy |
| Bearer token (JWT) | Заголовок Authorization | Высокая при HTTPS + короткий exp | REST API, SPA, мобильные приложения |
| API Key | Заголовок или параметр URL | Средняя (не истекает) | Серверные интеграции |
| OAuth 2.0 + PKCE | Bearer token через code flow | Высокая | Авторизация сторонних приложений |
История
До OAuth 2.0 API-авторизация строилась на Basic Auth или OAuth 1.0a — сложной схеме с подписью каждого запроса через HMAC-SHA1. RFC 6749 и RFC 6750, опубликованные в октябре 2012 года, ввели упрощённую схему bearer-токенов. RFC 7519 (JWT, 2015) формализовал наиболее распространённый формат. OAuth 2.1 (2023) включил bearer-токены как обязательный элемент и запретил implicit flow.
Безопасность в хостинге
Bearer-токены передавать только по HTTPS — перехваченный токен даёт полный доступ без дополнительной аутентификации. Срок жизни access token — не более 1 часа. Хранить в памяти приложения (JS-переменная), не в localStorage (уязвим к XSS) и не в cookie без httpOnly и Secure флагов. Bearer-токены используются в REST API всех крупных хостинг-панелей: Hetzner Cloud API, DigitalOcean API, Plesk API, ISPmanager API. Для серверных скриптов Python-автоматизации токены хранить в переменных окружения, не в коде: TOKEN = os.environ["HETZNER_API_TOKEN"].
OAuth 2.0 flows и Bearer-токены
Bearer-токены получаются через разные OAuth 2.0 flows в зависимости от сценария:
- Authorization Code + PKCE — для веб-приложений и мобильных клиентов. Пользователь логинится через IdP (Google, Keycloak), получает code, обменивает на access + refresh token.
- Client Credentials — для серверных M2M-интеграций без пользователя. Сервер авторизуется своим client_id + client_secret и получает access token. Используется для автоматических API-запросов к хостинг-провайдерам.
- Device Code — для устройств без браузера (CLI, IoT). Пользователь авторизуется на другом устройстве.
Проверка JWT без обращения к серверу: jwt.decode(token, PUBLIC_KEY, algorithms=["RS256"]) — декодирование и проверка подписи занимает менее 1 мс на стороне сервиса.