---
title: "Discussion on \"DPoP and mTLS both get harder at the reverse proxy\" | Hashnode"
description: "Discussion on \"DPoP and mTLS both get harder at the reverse proxy\". A bearer token works for whoever holds it. Sender-constrained tokens add a condition: the caller also has to prove it holds a private key that the token was bound to. OAuth has two standard ways to do"
url: "https://hashnode.com/posts/dpop-and-mtls-both-get-harder-at-the-reverse-proxy/6ae82c653290b00a26dc2b4a"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [DPoP and mTLS both get harder at the reverse proxy](https://edilec-engineering.hashnode.dev/dpop-and-mtls-both-get-harder-at-the-reverse-proxy?utm_source=hashnode&utm_medium=feed)

A bearer token works for whoever holds it. Sender-constrained tokens add a condition: the caller also has to prove it holds a private key that the token was bound to. OAuth has two standard ways to do

Nov 2 · 5 min read · edilec-engineering.hashnode.dev  
Read the article

-   [#oauth](https://hashnode.com/tag/oauth)
-   [#security](https://hashnode.com/tag/security)
-   [#api-security](https://hashnode.com/tag/api-security)

## Written by

[Krishnam Murarka](https://hashnode.com/@krishnamm)

@krishnamm · Bangalore, India

  
[View profile](https://hashnode.com/@krishnamm)

## Responses 1

Markdown supported · ⌘↵ to post

[AI Developer](https://hashnode.com/@lycore)

[Nov 2](https://hashnode.com/posts/dpop-and-mtls-both-get-harder-at-the-reverse-proxy/6ae82c653290b00a26dc2b4a/comment/6ae84529807a1760b4783246)

The point about reconstructing htu behind a gateway is the part most DPoP write-ups skip. One concrete suggestion is to stop deriving the URI from request headers at all and instead configure the canonical external origin per resource server, then compare htu against origin plus the routed path after rewrite. That removes the X-Forwarded-Host choice from the attacker's hands. For the jti replay cache, a shared store with a TTL equal to the acceptance window plus clock skew keeps state bounded, but it becomes a hard dependency on the request path, so it is worth deciding up front whether a cache outage fails closed. Do you think the hostile-test matrix should also include a request that reaches the app via an internal route that bypasses the proxy, since that is where both the Client-Cert stripping and the htu rebuild tend to diverge?