Открыть сервис
Главная → Блог → Маркеры доступа

Маркеры доступа

Маркеры доступа (англ. access tokens) — это криптографические или цифровые объекты, содержащие данные, необходимые для аутентификации и авторизации пользователя, приложения или устройства при обращении к защищённым ресурсам (веб-сервисам, API, базам данных). Маркеры доступа представляют собой строку символов (обычно в формате JSON Web Token, JWT, или случайную последовательность), которая выдаётся сервером аутентификации после успешной проверки учётных данных (логина, пароля, сертификата, биометрических данных). Основное назначение маркера — подтвердить право субъекта на выполнение определённых операций (чтение, запись, удаление) в рамках заданного контекста (времени, IP-адреса, области действия). В отличие от сессионных cookie, маркеры доступа часто не хранятся на сервере, а проверяются на основе подписи или шифрования, что позволяет реализовывать распределённые и децентрализованные системы аутентификации.

История

Концепция маркеров доступа возникла как развитие механизмов сессионных идентификаторов в ранних веб-протоколах. В 1990-х годах для аутентификации в HTTP-запросах использовались базовые заголовки (Basic Auth) и сессионные cookie, которые требовали постоянного хранения состояния на сервере. С ростом числа микросервисных архитектур и мобильных приложений в 2000-х годах возникла необходимость в лёгких, самодостаточных токенах, не требующих обращения к централизованной базе сессий.

В 2007 году был опубликован стандарт OAuth 1.0 (RFC 5849), который ввёл понятие токена доступа для делегирования прав сторонним приложениям. В 2010 году появился OAuth 2.0 (RFC 6749), ставший основой для большинства современных систем авторизации. В 2015 году был стандартизирован формат JSON Web Token (JWT, RFC 7519), который стал наиболее распространённым способом кодирования маркеров доступа. В 2018 году OAuth 2.0 был дополнен протоколом OpenID Connect, который добавил поддержку идентификационных токенов (ID Token) для аутентификации пользователей.

Классификация

Маркеры доступа делятся на несколько типов в зависимости от способа хранения, проверки и области применения.

По способу проверки

  • Bearer-токены (токены-носители) — наиболее распространённый тип. Предъявитель токена (bearer) автоматически считается владельцем прав, указанных в токене. Проверка осуществляется по подписи или хешу. Недостаток — утечка токена даёт злоумышленнику полный доступ до истечения срока действия.
  • Proof-of-Possession-токены (PoP) — требуют от клиента доказательства владения закрытым ключом или другим секретом, связанным с токеном. Даже при перехвате токена злоумышленник не сможет его использовать без соответствующего ключа. Используются в высокозащищённых системах, например, в банковских API.

По формату

  • JSON Web Token (JWT) — самодостаточный токен, содержащий заголовок (тип и алгоритм подписи), полезную нагрузку (claims — утверждения, например, идентификатор пользователя, роли, срок действия) и подпись. JWT может быть подписан (JWS) или зашифрован (JWE). Пример: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....
  • Opaque-токены (непрозрачные) — случайная строка символов (например, UUID), которая не содержит информации о правах. Для проверки сервер обязан обращаться к хранилищу (базе данных или кешу), где хранится соответствие токена и прав. Пример: dGhpcyBpcyBhIHRva2Vu.
  • SAML-токены (Security Assertion Markup Language) — XML-документы, содержащие утверждения об аутентификации и авторизации. Используются в корпоративных системах единого входа (SSO). Менее распространены в веб-API из-за громоздкости.

По сроку действия

  • Краткосрочные (access token) — живут от нескольких минут до нескольких часов. Используются для непосредственного доступа к ресурсу. После истечения клиент должен получить новый токен.
  • Долгосрочные (refresh token) — живут от нескольких дней до месяцев. Используются для получения нового access token без повторного ввода учётных данных. Refresh token хранится в защищённом хранилище (например, в системном Keychain на iOS) и передаётся только по защищённому каналу.

Устройство и характеристики

Маркер доступа, как правило, состоит из трёх частей: заголовка, полезной нагрузки и подписи (в случае JWT). Заголовок содержит метаданные: алгоритм подписи (например, HS256, RS256), тип токена. Полезная нагрузка включает набор утверждений (claims), которые делятся на стандартные (зарегистрированные в IANA) и пользовательские (определяемые разработчиком). Стандартные утверждения включают:

  • iss (issuer) — эмитент, выпустивший токен (например, https://auth.example.com`).
  • sub (subject) — субъект, которому выдан токен (идентификатор пользователя).
  • aud (audience) — получатель, для которого предназначен токен (например, https://api.example.com`).
  • exp (expiration time) — время истечения (Unix timestamp).
  • iat (issued at) — время выдачи.
  • nbf (not before) — время, до которого токен недействителен.

Подпись создаётся с помощью секретного ключа (симметричное шифрование) или пары открытый/закрытый ключ (асимметричное шифрование). При асимметричном шифровании сервер ресурсов может проверить подпись, используя открытый ключ эмитента, без необходимости обращаться к серверу аутентификации.

Применение

Маркеры доступа широко используются в современных веб- и мобильных приложениях, а также в системах Интернета вещей (IoT).

Веб-API и микросервисы

При обращении к REST API клиент передаёт маркер доступа в HTTP-заголовке Authorization: Bearer <token>. Сервер проверяет подпись, срок действия и область действия (scope). Например, в архитектуре на основе OAuth 2.0 клиент получает токен с областью read:orders, что позволяет только читать заказы, но не изменять их. В микросервисной архитектуре каждый сервис может проверять токен локально, без обращения к центральному серверу аутентификации, что снижает задержки.

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

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

Системы единого входа (SSO)

В корпоративных средах маркеры доступа (часто в формате SAML или JWT) используются для реализации SSO. Пользователь аутентифицируется один раз на сервере идентификации (IdP), после чего получает токен, который может быть использован для доступа к нескольким приложениям (service providers). Примеры: Active Directory Federation Services (ADFS), Keycloak, Okta.

Интернет вещей (IoT)

В IoT-устройствах маркеры доступа применяются для аутентификации устройств при подключении к облачным платформам (например, AWS IoT, Azure IoT Hub). Устройство получает токен, подписанный закрытым ключом, и использует его для публикации данных или получения команд. Это позволяет избежать хранения паролей на устройстве.

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

Маркеры доступа подвержены нескольким типам атак, поэтому требуют соблюдения мер безопасности.

  • Перехват токена — при передаче по незащищённому каналу (HTTP) злоумышленник может перехватить токен. Рекомендуется использовать только HTTPS (TLS).
  • Утечка токена — если токен хранится в незащищённом месте (например, в localStorage веб-приложения), он может быть украден через XSS-атаку. Рекомендуется хранить токены в HttpOnly cookie или в защищённом хранилище браузера (SessionStorage).
  • Подделка подписи — если секретный ключ скомпрометирован, злоумышленник может создать поддельный токен. Рекомендуется использовать асимметричное шифрование (RS256, ES256) и регулярно менять ключи.
  • Атаки повторного воспроизведения — перехваченный токен может быть использован повторно. Для защиты используются короткие сроки жизни токена (обычно 15-30 минут) и механизм jti (уникальный идентификатор токена), который проверяется на стороне сервера.
  • Отзыв токена — в случае компрометации токен должен быть отозван. Для этого используется чёрный список (blacklist) или короткий срок жизни с обязательным обновлением через refresh token.

Примеры реализации

  • OAuth 2.0 + JWT — популярная комбинация для веб-API. Сервер аутентификации (например, Auth0, Keycloak) выдаёт JWT-токен, который проверяется каждым микросервисом. Пример запроса на получение токена:

`` POST /oauth/token Content-Type: application/x-www-form-urlencoded grant_type=password&username=user&password=pass&client_id=app ` Ответ: `json { "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "dGhpcyBpcyBhIHJlZnJlc2ggdG9rZW4..." } ``

  • API-ключи — упрощённая форма маркера доступа, используемая для аутентификации приложений (например, Яндекс.Карты API, Google Maps API). Ключ передаётся в URL или заголовке. Недостаток — отсутствие механизма обновления и ограниченной области действия.

Критика

Основные претензии к маркерам доступа связаны с их безопасностью и сложностью реализации. Bearer-токены критикуются за уязвимость к перехвату: если токен украден, злоумышленник получает полный доступ до истечения срока. Кроме того, JWT-токены могут быть перегружены данными, что увеличивает размер запроса и замедляет передачу. Некоторые эксперты указывают, что использование JWT без механизма отзыва (например, без чёрного списка) создаёт риски при компрометации токена. В ответ на это были разработаны протоколы с доказательством владения (DPoP, RFC 9449), которые требуют от клиента подписывать каждый запрос дополнительным ключом.

Источники

  • RFC 6749 — The OAuth 2.0 Authorization Framework
  • RFC 7519 — JSON Web Token (JWT)
  • RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP)
  • RFC 5849 — The OAuth 1.0 Protocol
  • OpenID Connect Core 1.0 Specification
  • «OAuth 2.0 in Action» by Justin Richer and Antonio Sanso (Manning Publications, 2017)
  • «JWT Handbook» by Sebastian Peyrott (Auth0, 2016)

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы