RFC 9421 · RFC 9530 · Five languages

httpsig

Cryptographic proof of who sent an HTTP message — per request, no bearer tokens.

httpsig is a multi-language library for HTTP Message Signatures (RFC 9421) and Content-Digest (RFC 9530). It signs the parts of a request or response that matter — method, path, headers, body digest — so a recipient can prove the message came from the holder of a specific key and was not altered in flight. The same core abstractions are implemented natively in Go, TypeScript, Java, Swift, and Kotlin, all passing the shared RFC 9421 test vectors.

Open the playground → Read the docs Interactive diagrams

Try it now: the playground signs and verifies real RFC 9421 messages entirely in your browser — generated keys never leave the page.

What it does

A bearer token grants access to whoever holds it — steal the token, impersonate the user. An HTTP message signature binds authority to a key and to this specific message: the signer covers a chosen set of components, hashes them into a canonical signature base, and signs it. Every request runs the same pipeline:

1 select components 2 build signature base 3 sign 4 attach Signature headers 5 send verify on receipt

How signing works

The signer lists the components it wants to cover (e.g. @method, @path, content-digest) plus metadata — key id, created/expires timestamps, an optional nonce. Those become the signature base: one canonical line per component, ending with the @signature-params line. The base is signed; the result travels in two headers — Signature-Input (what was covered) and Signature (the bytes). A verifier reconstructs the same base from the message it received and checks the signature against the signer's public key. Change a single covered byte and verification fails.

▶ Toggle the covered components and watch the exact signed bytes — the signature base — assemble:

What you get

Five native implementations

Go, TypeScript, Java, Swift, and Kotlin — each idiomatic to its ecosystem, not a transliteration, all validated against the same RFC 9421 vectors.

Getting started ↗

Every standard algorithm

ed25519, ecdsa-p256-sha256, rsa-pss-sha512, and hmac-sha256 — the RFC 9421 algorithm set, with raw r‖s ECDSA encoding done for you.

Algorithms ↗

Keys that can't be exfiltrated

Back keys with the Secure Enclave, Android Keystore, an HSM, a Cloud KMS, or a non-extractable Web Crypto key. The library only ever asks them to sign.

Key management ↗

Body integrity, built in

RFC 9530 Content-Digest hashes the body; cover that header in the signature and the body is protected too — without the signer reading the whole stream.

Content-Digest ↗

Response & proxy binding

Bind a response to the request that triggered it with ;req, and forward through proxies that add their own signature without breaking the client's.

Response binding ↗

Drop-in client integrations

Sign automatically through fetch, axios, undici, OkHttp, the JDK HttpClient, Spring WebClient, URLSession, Alamofire, and the Ktor client.

Integrations ↗

Find your way around