DPoP (Demonstrating Proof of Possession)
Was ist 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.
● Beispiele
- 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.
● Häufige Fragen
Was ist 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. Es gehört zur Kategorie Identität und Zugriff der Cybersicherheit.
Was bedeutet 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.
Wie funktioniert 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.
Wie schützt man sich gegen DPoP (Demonstrating Proof of Possession)?
Schutzmaßnahmen gegen DPoP (Demonstrating Proof of Possession) kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für DPoP (Demonstrating Proof of Possession)?
Übliche alternative Bezeichnungen: RFC 9449, Demonstrating Proof of Possession.
● Verwandte Begriffe
- identity-access№ 839
OAuth 2.0
Offenes Autorisierungs-Framework, mit dem ein Ressourceninhaber einer Drittanwendung beschränkten, scoped Zugriff auf eine API gewähren kann, ohne Zugangsdaten preiszugeben.
- identity-access№ 642
JWT (JSON Web Token)
Kompaktes, URL-sicheres Token-Format (RFC 7519) mit signierten JSON-Claims; weit verbreitet als Access Token, ID Token und Sitzungscontainer.
- 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
Opake oder strukturierte Credential (RFC 6750), die allein durch Besitz Zugriff auf eine Ressource gewahrt - ohne Nachweis, dass der Trager der rechtmassige Inhaber ist.
- network-security№ 797
Mutual TLS (mTLS)
Eine TLS-Erweiterung, bei der sowohl Client als auch Server X.509-Zertifikate vorlegen, um sich kryptografisch gegenseitig zu authentifizieren.
- identity-access№ 852
OpenID Connect (OIDC)
Identitätsschicht auf Basis von OAuth 2.0, mit der Clients über signierte ID Tokens die Nutzeridentität verifizieren und Basisprofildaten abrufen können.