Tabella dei contenuti
Focus on DPoP
Demonstrating Proof-of-Possession (DPoP) is the IETF standard (RFC 9449) that renders a voucher (JWT token) unusable if stolen, because it is bound to a public key owned by the caller.
It is the producer who requires the use of DPoP by including it within the information of their API interface file. DPoP is recommended for use cases where extra protection is desired against token theft and replay. If the use of DPoP is not explicitly required, traditional “Bearer” vouchers continue to be used.
Summary
The subscriber generates an asymmetric key pair dedicated to DPoP. The private key always remains on the subscriber’s server or device and is never shared.
This key must not be deposited on PDND nor coincide with any of those possibly registered for the client assertion: it is independent and managed by the subscriber.
DPoP encourages the use of ephemeral or at least separate keys: the same key may sign all requests in a “session,” but each API call includes a DPoP with unique jti and iat, thus creating a distinct cryptographic context that cannot be reused by third parties.
If necessary, the subscriber may keep the DPoP key for longer periods, as long as it remains different from the one used for the client assertion.
Why use DPoP?
| Vantaggio | Cosa significa in pratica |
|---|---|
| Token bound to the caller | The voucher contains the hash — the thumbprint — of the caller’s public key; without the corresponding private key it cannot be used. |
| Replay protected | Each request carries a small signed JWT (“DPoP”) with htm + htu + timestamp + jti; the same proof cannot be reused on another endpoint or after a few minutes. |
| Zero caller certificates | Achieves a result similar to mTLS, but with a simple key pair generated by the caller. |
| Cryptographic "red thread" | DPoP creates a unique link between the actors in the OAuth 2.0 flow through the sharing of unique information in the exclusive possession of the subscriber (private key). |
In essence, the end-to-end process requires seven steps:
- The subscriber generates the standard client assertion; signs it with the private key whose public key is deposited on their client on PDND.
- The subscriber builds the DPoP intended for PDND’s authorization server; signs it with a second private key whose public key will be placed in the DPoP header, in the jwk field.
- The subscriber requests the voucher from PDND’s authorization server, adding the DPoP header.
- PDND’s authorization server performs the necessary checks. If successful, it returns a DPoP-type voucher.
- The subscriber builds a second DPoP, this time intended for the resource server — the producer’s e-service API; signs it with the same private key as the DPoP in step 2, again including the corresponding public key in the DPoP header, in the jwk field.
- The subscriber makes a request to the producer’s e-service; includes both the voucher issued by PDND and the DPoP generated in the previous step in the DPoP header.
- The producer performs the necessary checks. If successful, it returns the data to the subscriber.
For details on how to implement it, see the dedicated tutorial.
Hai bisogno di aiuto?
Apri un ticket utilizzando l’apposita funzione all’interno della tua Area Riservata
