Demonstration of Proof-of-Possession overview

Demonstration of Proof-of-Possession overview

architect

Demonstration of Proof-of-Possession

The Demonstration of Proof-of-Possession (DPoP) is a relatively simple mechanism for sender-constraining access tokens. It gives you a way to tie an access token to the client who gets it. This means that the access token is no longer a bearer token, the client must provide a proof of possession in order to use the token.

The DPoP mechanism is a proposed standard, though still in draft status and has been designed to be used in scenarios where stronger means of proof of possession cannot be used. For example, when the client is not able to utilise mutual TLS.

Overview

The DPoP relies on a simple principle: first the client presents their public key to the Authorization Server, which is then incorporated into the access token. Next the client sends the public key, encoded as a JWT, together with the access token to the Resource Server. Thanks to this the RS can verify that the client is in possession of the private key and that it is the same key pair that was used when issuing the access token.

DPoP proofs are JWTs that must be signed by the client using a private key. What is important, asymmetric signing must be used for DPoP, otherwise the mechanism would be insecure.

Tying an access token to a Proof of Possession

When sending a request to the /token endpoint, the client adds a DPoP header, which is a signed JWT containing the following information:

  • the public key that can be used to verify the signature
  • jti claim, which is a unique identifier of the JWT
  • htm and htu claims, which contain respectively the HTTP method and the URL to which the client sends the request
  • iat claim, which has the time when the token was issued (Authorization Servers should only accept fairly fresh DPoP tokens)

The DPoP token sent to a /token endpoint could, thus look something like this:

{
    "typ":"dpop+jwt",
    "alg":"ES256",
    "jwk": {
        "kty":"EC",
        "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
        "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
        "crv":"P-256"
    }
}
{
    "jti":"-BwC3ESc6acc2lTc",
    "htm":"POST",
    "htu":"https://myidsvr.com/token",
    "iat":1598524639
}

The Authorization Server should validate the JWT - the signature and claims contained in the token. If DPoP is deemed valid the AS adds a confirmation claim to the Access Token which is a Base64 urlencoding of the SHA-256 Thumbprint of the public key used to sign the DPoP token.

This claim can look something like this in the resulting access token JWT:

"cnf":{
    "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
}

jkt claim is used to indicate that the DPoP mechanism was used.

Proving possession in requests to a Resource Server

Once the client receives an access token with a confirmation claim it must provide a proof of possession whenever the token is used to access resources. The client must send a DPoP token for every request it makes to the RS. The token must be constructed in the same way as for the /token endpoint. In particular, the htm and htu claims must have the values conforming to each request being made.

The client sends the access token using the DpoP scheme and a DPoP header containing the DPoP token minted for the concrete request:

GET /resource HTTP/1.1
Host: api.example.com
Authorization: DPoP eyJhbGci...hF1MQ
DPoP: eyJ0eXAi...4UCbQ

The Resource Server, should verify a few things when receiving a DPoP token:

  • Verify the signature of the DPoP token with the public key contained in the header of that token.
  • Verify the claims of the DPoP token: whether the HTTP method and URL match the called endpoint, whether the token is not too old, etc.
  • Verify whether the public key used to signed the DPoP token matches the Thumbprint from the jkt claim of the access token.

The resource server rejects requests which fail the verification of the proof of possession.

DPoP in Curity

In Curity Identity Server, DPoP is required for clients which want to use the Hypermedia Authentication API. DPoP is required when using the API to further increase security of the communication between client and the authorization server.

Conclusion

The DPoP mechanism provides a new way for sender-constraining access tokens. It’s great for scenarios where clients are not able to use a different method for proving the possession of an access token.

Let’s Stay in Touch!

Get the latest on identity management, API Security and authentication straight to your inbox.

Keep up with our latest articles and how-tos using RSS feeds