DPoP (Demonstrating Proof of Possession)
Qu'est-ce que 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.
● Exemples
- 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.
● Questions fréquentes
Qu'est-ce que 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. Cette notion relève de la catégorie Identité et accès en cybersécurité.
Que signifie 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.
Comment fonctionne 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.
Comment se défendre contre DPoP (Demonstrating Proof of Possession) ?
Les défenses contre DPoP (Demonstrating Proof of Possession) combinent habituellement des contrôles techniques et des pratiques opérationnelles, comme détaillé dans la définition ci-dessus.
Quels sont les autres noms de DPoP (Demonstrating Proof of Possession) ?
Noms alternatifs courants : RFC 9449, Demonstrating Proof of Possession.
● Termes liés
- identity-access№ 839
OAuth 2.0
Cadre ouvert d'autorisation permettant au propriétaire d'une ressource d'accorder à une application tierce un accès limité à une API sans partager d'identifiants.
- identity-access№ 642
JWT (JSON Web Token)
Format de token compact et URL-safe (RFC 7519) portant des claims JSON signees, tres utilise comme access token, ID token et conteneur de session.
- 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 Token (token au porteur)
Credential opaque ou structure (RFC 6750) qui accorde l'acces a une ressource par simple possession, sans preuve que le porteur en est le proprietaire legitime.
- network-security№ 797
TLS mutuel (mTLS)
Extension de TLS dans laquelle le client et le serveur présentent tous deux des certificats X.509 pour s'authentifier mutuellement de manière cryptographique.
- identity-access№ 852
OpenID Connect (OIDC)
Couche d'identité construite au-dessus d'OAuth 2.0, permettant aux clients de vérifier l'identité d'un utilisateur et d'obtenir un profil de base via un jeton ID signé.