Demonstration of Proof-of-Possession (DPoP)

Introduction

The Demonstration of Proof-of-Possession(DPoP) is a mechanism to tie an access_token to the client who gets it. The client will have to provide a proof of possession before the access_token can be used.

DPoP Mechanism

1. Client application generates an ephemeral (One time) keypair on each API request.

Please ensure a new ephemeral keypair is generated on each request to ensure DPoP Proof is always unique per transaction.

  • Ephemeral public key (JWK)

  • Ephemeral private key

With the following information:

  • alg: ES256

  • use: sig


2. Client application generates the DPoP Proof JWT(for /token API)

  • Embed the DPoP Proof JWTephemeral public key (JWK) into the header of the DPoP Proof JWT DPoP Proof JWT

  • Sign the DPoP Proof JWT using the DPoP Proof JWT ephemeral private key


3. Client application appends ephemeral public key (JWK) thumbprint into the payload of the client_assertion (cnf.jkt)

Refer to Generate Client Assertion

This step ensures that the identical client application generates the DPoP Proof (for Token API) and client_assertion.


4. Client application calls the /token API to request for an access_token with the following information:

  • DPoP Proof (for Token API)

  • client_assertion

  • authcode


5. AuthZ server validates and embeds the ephemeral public key (JWK) thumbprint of the DPoP Proof JWT (for /token API) into the access_token (cnf.jkt).

This step ensures that the access_token can only be used by the client application.


6. AuthZ server returns access_token to the client application with token_type as DPoP.


7. Client application generates another DPoP Proof JWT (for /person API):

This step ensures that the access_token can only be used by the client application.


8. Client application calls the /person API to request for the person data (Resource) with the following information:

  • DPoP Proof (for Person API)

  • access_token


9. Resource server validates the payload (ath) and ensures the ephemeral public key (JWK) thumbprint of the DPoP Proof JWT (for /person API) matches the access_token hash and cnf.jkt.

This step ensures that the access_token belongs to the client application that generates the DPoP Proof (Person API).


10. Resource server response with the person data.


Generate Ephemeral keys

Sample Code:


Generate DPoP Proof JWT

The claims (Refer to https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#name-dpop-proof-jwt-syntax) expected in the DPoP Proof JWT are:

PARAMETER
DESCRIPTION

typ

Type - Type (Header), value "dpop+jwt"

alg

Algorithm (Header) - digital signature algorithm identifier as per RFC7518 (Refer to https://datatracker.ietf.org/doc/html/rfc7518). MUST NOT be none or an identifier for a symmetric algorithm (MAC), value "ES256"

jwk

JSON Web Key (Header) - public key chosen by the client. MUST NOT contain the private key.

jti

JWT ID (Payload) - unique identifier

htu

HTTP URL (Payload) - HTTP URI used for the request, without query (?) and fragment parts (#)

htm

HTTP Method (Payload) - HTTP method for the request to which the JWT is attached

iat

Issued At (Payload) - current timestamp

exp

Expiry (Payload) - expiry timestamp

ath

Access token hash (Payload) - The base64url encoded SHA-256 hash of the ASCII encoding of the associated access token's value (Required only for /person call after DPoP-bound access token is issued)

DPoP Proof Sample

Token API

Person API

Sample Code:

Last updated

Was this helpful?