Authenticator supporting RFC 9421 (HTTP Message Signatures)

[dadrus]

Preflight checklist

• [x] I agree to follow this project's Code of Conduct.
• [x] I have read and am following this repository's Contribution Guidelines."
• [ ] I have discussed this feature request with the community.

Describe the background of your feature request

HTTP Message Signatures (RFC 9421) defines a standardized mechanism for applying digital signatures to HTTP request and response messages. This approach is particularly interesting for request authentication, as it allows clients to prove authenticity not just by presenting a token, but by cryptographically binding aspects of the HTTP message itself (such as headers or body content) to their identity.

This provides a number of advantages:

• Client binding – Unlike bearer tokens, which can be replayed if stolen, message signatures can tie the request to a particular client and message content (this is also known as Proof-of-Posession).
• Payload integrity – By including request body or specific header fields in the signature, the server can verify that they have not been tampered with in transit.
• Replay protection – When combined with elements like timestamps or nonces, message signatures can prevent attackers from reusing intercepted requests.
• Complementary to existing auth – Works alongside OAuth 2.0 or API keys, strengthening scenarios where stronger request-level assurances are required.
• Standardization – Provides an interoperable alternative to ad-hoc signing mechanisms already seen in various APIs (e.g., AWS SigV4, HTTP MAC drafts).

Describe your idea

For heimdall, supporting HTTP Message Signatures would open the door for use cases that require verifiable message-level security in addition to traditional token-based authentication.

Therefore, add a new authenticator, named http_message_signatures, that verifies HTTP Message Signatures on inbound requests. Verification is performed against the request’s Signature-Input and Signature fields, including the covered components and parameters such as created, expires, or nonce, using the configured key store and lookup. This enables lightweight, token-free client authentication and request-level binding (e.g., @method, @authority, @path, and optionally the body via content-digest) — pushing authentication closer to the request itself while remaining complementary to TLS and OAuth/OIDC.

High-level behavior

• Parse and select a signature label, or optionally verify all signatures present.
• Verify the signature over the components declared in the Signature-Input header (e.g., @method, @authority, @path, content-digest).
• Ensure the declared components cover the components required by the authenticator’s configuration.
• Enforce time windows with configurable leeway for clock skew, while respecting constraints such as max-age.
• Provide replay protection via nonce tracking (cache-backed).
• Resolve keys via keyid lookup against a configured key store.
• On success, create a Subject with an ID derived from the verified key (e.g., key id, certificate fingerprint, or SAN) and attach useful attributes such as algorithm, label, tag, covered components, and key id.

Are there any workarounds or alternatives?

Nothing, which would allow the same feature set

Version

0.17.0

Additional Context

No response