Preflight checklist
Describe the background of your feature request
OAuth 2.0’s bearer-token model has long been a source of security incidents because anyone who obtains a bearer token can use it. To address this limitation, DPoP (RFC 9449) defines a mechanism for sender-constraining access and refresh tokens so that resource servers can verify that the client presenting a token is the only legitimate sender, which is recommended by RFC 9700, and is also explicitly addressed by the upcoming OAuth 2.1 standard.
Additionally, DPoP is being discussed in the MCP (Model Context Protocol) community as a proof-of-possession mechanism for tokens issued to AI Agents, serving as an alternative to HTTP Message Signatures (see also #2677).
Describe your idea
Supporting DPoP in Heimdall would strengthen its security posture and align it more closely with the future direction of OAuth 2.1–based deployments.
To add DPoP support, the jwt and oauth2_introspection authenticators would need to be extended to process the DPoP proof and verify the binding between the presented token and that proof. This could be handled automatically whenever the DPoP header (as defined in RFC 9449) is present, or it could be enforced explicitly via a configuration property such as proof_of_possession_required. When enabled, this property would require a valid proof to always be present; otherwise, the authenticator would fail.
Because proof-of-possession can be expressed through different further mechanisms, such as HTTP Message Signatures (RFC 9421), mTLS-based token binding (MPoP, RFC 8705), or others, the configuration for proof_of_possession_required may need to be structured so that it can express which proof-of-possession method is expected and define any additional parameters as needed. For DPoP and MPoP, no additional parameters are currently anticipated, but if HTTP Message Signatures is added as a pop option in the future, further configuration fields will likely be required.
Are there any workarounds or alternatives?
No direct workaround exists, as Heimdall currently treats all access tokens as regular bearer tokens.
As mentioned above, there are alternative mechanisms for achieving sender-constrained tokens, such as HTTP Message Signatures or MPoP.
Ideally, Heimdall should support DPoP alongside these alternatives to cover a wider range of use cases and deployment scenarios.
Version
0.17.0
Additional Context
No response
Preflight checklist
Describe the background of your feature request
OAuth 2.0’s bearer-token model has long been a source of security incidents because anyone who obtains a bearer token can use it. To address this limitation, DPoP (RFC 9449) defines a mechanism for sender-constraining access and refresh tokens so that resource servers can verify that the client presenting a token is the only legitimate sender, which is recommended by RFC 9700, and is also explicitly addressed by the upcoming OAuth 2.1 standard.
Additionally, DPoP is being discussed in the MCP (Model Context Protocol) community as a proof-of-possession mechanism for tokens issued to AI Agents, serving as an alternative to HTTP Message Signatures (see also #2677).
Describe your idea
Supporting DPoP in Heimdall would strengthen its security posture and align it more closely with the future direction of OAuth 2.1–based deployments.
To add DPoP support, the
jwtandoauth2_introspectionauthenticators would need to be extended to process the DPoP proof and verify the binding between the presented token and that proof. This could be handled automatically whenever theDPoPheader (as defined in RFC 9449) is present, or it could be enforced explicitly via a configuration property such asproof_of_possession_required. When enabled, this property would require a valid proof to always be present; otherwise, the authenticator would fail.Because proof-of-possession can be expressed through different further mechanisms, such as HTTP Message Signatures (RFC 9421), mTLS-based token binding (MPoP, RFC 8705), or others, the configuration for
proof_of_possession_requiredmay need to be structured so that it can express which proof-of-possession method is expected and define any additional parameters as needed. For DPoP and MPoP, no additional parameters are currently anticipated, but if HTTP Message Signatures is added as a pop option in the future, further configuration fields will likely be required.Are there any workarounds or alternatives?
No direct workaround exists, as Heimdall currently treats all access tokens as regular bearer tokens.
As mentioned above, there are alternative mechanisms for achieving sender-constrained tokens, such as HTTP Message Signatures or MPoP.
Ideally, Heimdall should support DPoP alongside these alternatives to cover a wider range of use cases and deployment scenarios.
Version
0.17.0
Additional Context
No response