Почему это важно
Одной копии токена недостаточно для повторного запроса без связанного ключа, хотя компрометация конечной точки или самого ключа всё равно опасна.
Что подтверждено
Актуальные рекомендации OAuth советуют привязывать токены доступа к отправителю через взаимную TLS-проверку или DPoP, чтобы снизить ценность украденного токена.
Граница применимости: Токены доступа OAuth, привязанные к отправителю.
Токен на предъявителя может использовать любой владелец строки, а токен с подтверждением владения требует связанное криптографическое доказательство для каждого принятого запроса.
Граница применимости: Токен на предъявителя и токен, привязанный к отправителю.
Что проверить
- Выберите способ привязки.
- Проверьте владение ключом.
- Отдельно защитите конечную точку и ключ.
Первоисточники
Best Current Practice for OAuth 2.0 Security
Internet Engineering Task Force · RFC 9700, January 2025
Актуализирует OAuth security: exact redirect matching, PKCE, sender-constrained tokens и безопасный refresh-token lifecycle.
Открыть первоисточникThe OAuth 2.0 Authorization Framework: Bearer Token Usage
Internet Engineering Task Force · RFC 6750, October 2012
Определяет bearer-token presentation, защиту от disclosure, Authorization header и ошибки invalid_token/insufficient_scope.
Открыть первоисточникOAuth 2.0 Demonstrating Proof of Possession
Internet Engineering Task Force · RFC 9449, September 2023
Определяет application-layer proof-of-possession и sender-constrained tokens с защитой от replay.
Открыть первоисточникResource Indicators for OAuth 2.0
Internet Engineering Task Force · RFC 8707, February 2020
Вводит resource parameter для target API и audience-restricted access tokens: scope отвечает что, resource — где.
Открыть первоисточник