DPoP (доказательство владения)

Welcome! Today we'll explore DPoP, which stands for Demonstrating Proof-of-Possession. It's a crucial security enhancement for OAuth2 and OpenID Connect.

DPoP helps prevent a major security risk: stolen access tokens. It ensures that only the legitimate client (the app) can use an access token.

Imagine an attacker steals an access token. Without DPoP, they could use this token to access your protected resources, impersonating the legitimate client.

This 'token exfiltration' is a significant vulnerability. Standard bearer tokens don't inherently prevent this because anyone who 'bears' (possesses) the token can use it.

DPoP cryptographically binds an access token to a specific client's private key. Think of it like a digital signature that only the rightful client can produce.

Here's the core idea:

• The client generates a unique key pair.
• The public key is linked to the access token.
• The client 'proves possession' of the private key with every request.

The process starts with the client application generating an asymmetric cryptographic key pair. This means it creates both a private key and a public key.

• The private key is kept secret by the client.
• The public key can be shared without compromising security.

This key pair is unique to the client session or instance.

When the client requests an access token from the Authorization Server, it includes a special header called DPoP in the request.

This DPoP header contains a JSON Web Token (JWT) signed by the client's private key. This JWT includes a hash of the client's public key.

The JWT in the DPoP header is the 'proof of possession'. It contains several claims:

• jkt: The JSON Web Key Thumbprint of the client's public key.
• htm: The HTTP method of the request (e.g., GET, POST).
• htu: The HTTP URL of the request.
• iat: Issued At time, preventing replay.

The Authorization Server validates this JWT and binds the jkt to the issued access token.

Once the client receives a DPoP-bound access token, it uses it to access protected resources on the Resource Server.

With every request to the Resource Server, the client must again send a new DPoP header containing a fresh JWT, signed by its private key, matching the current request's htm and htu.

The Resource Server performs critical checks:

1. It verifies the signature of the DPoP JWT using the public key derived from its jkt claim.
2. It ensures the jkt in the DPoP JWT matches the jkt stored within the access token itself.
3. It checks that the htm and htu claims in the DPoP JWT match the actual HTTP request.

If any check fails, access is denied. This ensures only the client possessing the private key can use the token.

You might wonder about Mutual TLS (mTLS). Both DPoP and mTLS bind tokens to a client, but they operate at different layers:

• mTLS: Binds at the TLS (transport) layer using client certificates.
• DPoP: Binds at the application layer using cryptographic proofs in HTTP headers.

DPoP is often more flexible and easier to implement for a wider range of client types (especially public clients like mobile apps) compared to mTLS.

Congratulations! You've learned about DPoP, a powerful security mechanism.

DPoP enhances OAuth2 and OIDC by cryptographically binding access tokens to the client's private key, effectively preventing token exfiltration and making stolen tokens unusable by attackers.

This 'proof of possession' significantly strengthens the security posture of your applications by ensuring only the legitimate client can use its access tokens.