Access-токен.

Access-токен выражает авторизацию, которую владелец ресурса предоставил клиенту, ограниченную конкретными правами и audience. В OAuth 2.0 (RFC 6749) и OpenID Connect access-токены могут быть непрозрачными — валидируемыми через вызов эндпоинта интроспекции сервера авторизации (RFC 7662) — или самодостаточными JWT, проверяемыми локально по подписи. Обычно они отправляются в заголовке Authorization: Bearer согласно RFC 6750 и должны передаваться по TLS.

Ключевая слабость обычного bearer-токена в том, что владение равно полномочиям: токен, украденный из хранилища браузера, лога или прокси, может быть воспроизведён кем угодно. Это привело к появлению sender-constrained токенов. RFC 8705 привязывает токен к TLS-сертификату клиента (записывая его хеш в claim cnf.x5t#S256), а RFC 9449 (DPoP) привязывает токен к ключевой паре, хранимой клиентом, требуя на каждый запрос свежее подписанное доказательство в виде JWT, так что воспроизведённый токен бесполезен без приватного ключа. Атаки кражи токенов — включая воспроизведение сессий/токенов, наблюдавшееся в Lapsus$ и различных облачных вторжениях типа «pass-the-token», — это именно то, что побеждают эти механизмы.

Лучшие практики: короткое время жизни (минуты), узкие scope, строгая проверка audience и issuer, отклонение трюка с JWT alg: none, связка с refresh-токенами для обновления и хранение токенов вне доступного для JavaScript хранилища. Для критичных API предпочтительны токены, привязанные через DPoP или mTLS, а не обычные bearer-токены.

flowchart LR
  RO[Владелец ресурса] -->|даёт согласие| AS[Сервер авторизации]
  C[Клиент] -->|запрос токена + ключ DPoP/mTLS| AS
  AS -->|короткоживущий access-токен<br/>scope + aud + claim cnf| C
  C -->|Bearer-токен + доказательство владения| RS[Сервер ресурсов / API]
  RS -->|проверка подписи/интроспекция<br/>проверка aud, exp, привязки ключа| RS
  RS -->|разрешить или отклонить| C