Sender-constrained токены: DPoP и mTLS

Supply-chain атака инжектирует одну строчку JavaScript в твой SPA. Она читает access-токен из памяти и exfiltrate-ит его на сервер атакующего. Токен — bearer токен: кто держит, тот и использует. Атакующий теперь имеет минуты или часы для вызова твоего API как жертва. DPoP делает украденный токен бесполезным: без соответствующего приватного ключа, который никогда не покидал клиента, атакующий не может сгенерировать валидный proof.

Проблема bearer-токена

Bearer access-токен — это ровно то, что в названии: любой держатель может его использовать. Resource server не проверяет кто представляет токен — только что токен валиден. Это дизайн.

Следствие: кража = полная компрометация на оставшееся TTL токена. Короткие TTL (5–15 мин) ограничивают window, но не устраняют его. Для банкинга, healthcare и других high-value нагрузок “украденный токен работает 15 минут” — неприемлемый риск.

DPoP — Demonstrating Proof of Possession (RFC 9449)

DPoP привязывает access-токен к key pair под контролем клиента. Клиент генерирует non-extractable key pair (WebCrypto в браузерах, OS keychain в native apps). Access-токен несёт claim cnf (confirmation) с JWK thumbprint (jkt) публичного ключа.

На каждый API-вызов клиент вычисляет DPoP proof JWT в HTTP заголовке DPoP. Payload proof содержит:

• jti — unique ID (сервер кеширует для replay detection, типичное окно 5–10 мин)
• htm — HTTP method (например POST)
• htu — HTTP target URI (например https://api.bank.example/v1/transfer)
• iat — issued-at timestamp (сервер отклоняет если вне ~60с окна)
• ath — SHA-256 access-токена (привязывает этот proof к этому конкретному токену)

Header proof включает публичный ключ (jwk). Resource server валидирует:

1. Подпись валидна (используя embedded jwk)
2. ath = SHA-256 incoming bearer токена
3. htm и htu совпадают с реальным запросом
4. iat в допустимом окне
5. jti не виден недавно (anti-replay)
6. jwk хешируется в jkt в cnf claim токена

Украденный токен без приватного ключа не может пройти шаги 1 или 5. API-вызов отклонён.

mTLS-bound токены (RFC 8705)

mTLS (mutual TLS) привязывает access-токен к X.509 сертификату клиента. TLS handshake сам представляет сертификат; resource server верифицирует, что TLS-presented сертификат совпадает с cnf.x5t#S256 claim в токене.

DPoP vs mTLS — практическое отличие для браузерных SPA:

• Браузеры не раскрывают TLS client сертификаты JavaScript. mTLS требует выбора сертификата на уровне OS / браузера — непрактично для SPA, где ключ должен жить в JS.
• DPoP использует WebCrypto API для хранения non-extractable key pair в browser JS контексте. Это работает; ключ никогда не покидает браузер, но управляется SPA кодом.
• FAPI 2.0 (Open Banking профиль) требует sender-constrained токены через mTLS или DPoP. Для нового browser-based финтека в 2026 DPoP — дефолтный выбор. mTLS — выбор для backend service-to-service, где client сертификаты управляемы.

PAR и JAR: укрепление authorize-запроса

Pushed Authorization Requests (PAR, RFC 9126): Вместо того чтобы все параметры были в browser redirect URL, клиент POST-ит их на /par endpoint через TLS-authenticated back channel сначала. Сервер возвращает short-lived request_uri. Клиент редиректит браузер на /authorize?request_uri=... — никаких параметров в URL.

Преимущества: параметры не в browser history, referrer header или screenshots. Authorization server валидирует запрос до того, как браузер вовлечён.

JAR (JWT Authorization Requests, RFC 9101): Клиент упаковывает authorize параметры как signed JWT. Auth server валидирует подпись до обработки. В сочетании с PAR весь запрос off-URL и integrity-protected.

Оба PAR + JAR требуются FAPI 2.0. Consumer OAuth обычно скипает их; банкинг и healthcare требуют.