DPoP (Demonstrating Proof of Possession)
Что такое DPoP (Demonstrating Proof of Possession)?
DPoP (Demonstrating Proof of Possession)An OAuth 2.0 extension (RFC 9449) that binds access tokens to a per-client key pair, so a stolen bearer token cannot be replayed by an attacker without also stealing the private signing key.
DPoP (Demonstrating Proof of Possession at the Application Layer), specified in RFC 9449, is an OAuth 2.0 mechanism that converts bearer tokens into sender-constrained tokens without requiring mutual TLS. The client generates an ephemeral asymmetric key pair, includes the public key's JWK thumbprint as `jkt` in the access token (issued by the IdP), and on every API call sends a short-lived JWT proof signed with its private key in the `DPoP` HTTP header. The proof commits to the HTTP method, the request URI, and a fresh nonce or jti, so an attacker who steals the access token but lacks the private key cannot forge a valid proof. Resource servers verify the proof matches both the token's bound key and the current request. DPoP is one of two practical answers to OAuth bearer-token theft (the other being mTLS-bound tokens) and is now widely supported by Okta, Auth0, Entra ID, Keycloak, and several open-source libraries. Combined with PKCE and short refresh-token lifetimes, DPoP dramatically reduces the value of a stolen token to an attacker.
● Примеры
- 01
A mobile banking app signs a DPoP proof JWT with its TEE-stored key on every API call; a stolen access token alone gets the attacker nothing.
- 02
An IdP issues access tokens with `cnf.jkt` bound to the client's DPoP key, and the resource server rejects any request whose proof JWT doesn't match the bound thumbprint.
● Частые вопросы
Что такое DPoP (Demonstrating Proof of Possession)?
An OAuth 2.0 extension (RFC 9449) that binds access tokens to a per-client key pair, so a stolen bearer token cannot be replayed by an attacker without also stealing the private signing key. Относится к категории Идентификация и доступ в кибербезопасности.
Что означает DPoP (Demonstrating Proof of Possession)?
An OAuth 2.0 extension (RFC 9449) that binds access tokens to a per-client key pair, so a stolen bearer token cannot be replayed by an attacker without also stealing the private signing key.
Как работает DPoP (Demonstrating Proof of Possession)?
DPoP (Demonstrating Proof of Possession at the Application Layer), specified in RFC 9449, is an OAuth 2.0 mechanism that converts bearer tokens into sender-constrained tokens without requiring mutual TLS. The client generates an ephemeral asymmetric key pair, includes the public key's JWK thumbprint as `jkt` in the access token (issued by the IdP), and on every API call sends a short-lived JWT proof signed with its private key in the `DPoP` HTTP header. The proof commits to the HTTP method, the request URI, and a fresh nonce or jti, so an attacker who steals the access token but lacks the private key cannot forge a valid proof. Resource servers verify the proof matches both the token's bound key and the current request. DPoP is one of two practical answers to OAuth bearer-token theft (the other being mTLS-bound tokens) and is now widely supported by Okta, Auth0, Entra ID, Keycloak, and several open-source libraries. Combined with PKCE and short refresh-token lifetimes, DPoP dramatically reduces the value of a stolen token to an attacker.
Как защититься от DPoP (Demonstrating Proof of Possession)?
Защита от DPoP (Demonstrating Proof of Possession) обычно сочетает технические меры и операционные практики, как описано в определении выше.
Какие есть другие названия DPoP (Demonstrating Proof of Possession)?
Распространённые альтернативные названия: RFC 9449, Demonstrating Proof of Possession.
● Связанные термины
- identity-access№ 839
OAuth 2.0
Открытый фреймворк авторизации, позволяющий владельцу ресурса предоставлять стороннему приложению ограниченный и регулируемый доступ к API без передачи учётных данных.
- identity-access№ 642
JWT (JSON Web Token)
Компактный URL-безопасный формат токена (RFC 7519) с подписанными JSON-утверждениями; используется как access token, ID token и контейнер сессии.
- identity-access№ 928
PKCE (Proof Key for Code Exchange)
An OAuth 2.0 extension (RFC 7636) that binds an authorization-code redemption to a one-time secret created by the client, neutralizing authorization-code interception attacks on public and confidential clients alike.
- identity-access№ 104
Bearer-токен
Непрозрачный или структурированный мандат (RFC 6750), дающий доступ к ресурсу самим фактом владения, без подтверждения, что обладатель — законный владелец.
- network-security№ 797
Взаимный TLS (mTLS)
Расширение TLS, при котором и клиент, и сервер предъявляют сертификаты X.509, что обеспечивает криптографическую взаимную аутентификацию сторон.
- identity-access№ 852
OpenID Connect (OIDC)
Слой идентификации поверх OAuth 2.0, позволяющий клиентам проверять подлинность пользователя и получать базовые сведения о профиле через подписанные ID-токены.