ci: build both JSON backends per distro; disable GnuTLS in compat matrix Expand the build-linux vendor-compat matrix to build each distro twice - once with jansson, once with json-c - so both JSON backends are exercised across their shipped versions (5 distros x 2 = 10 jobs). Turn GnuTLS OFF on every compat row. Enabling GnuTLS against the stacks these distros ship (Debian trixie 3.8.9, Ubuntu resolute 3.8.12) revealed that libjwt SEGFAULTS loading Ed448 keys (jwt_flipflop, jwt_jwks) and returns NULL for X25519/X448 ECDH-ES (jwe_ecdh, jwe_json); the NIST P-curves are fine. Only the from-source GnuTLS 3.8.13 stack in the build-linux-combos image is known-correct (those rows pass). GnuTLS NEWS for 3.8.10-3.8.13 lists no Ed448/X448 fix, so the differentiator (GnuTLS vs nettle version vs the --without-p11-kit build) is not yet pinned down. Native GnuTLS coverage stays in build-linux-combos; re-enable GnuTLS here per distro once a stack is verified working. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ben Collins <bcollins@libjwt.io>
| Standard | RFC | Description |
|---|---|---|
JWS | :page_facing_up: RFC-7515 | JSON Web Signature |
JWE | :page_facing_up: RFC-7516 | JSON Web Encryption |
JWK | :page_facing_up: RFC-7517 | JSON Web Keys and Sets |
JWA | :page_facing_up: RFC-7518 | JSON Web Algorithms |
JWT | :page_facing_up: RFC-7519 | JSON Web Token |
[!NOTE] Throughout this documentation you will see links such as the ones above to RFC documents. These are relevant to that particular part of the library and are helpful to understand some of the specific standards that shaped the development of LibJWT.
-DWITH_JSON_C=ON). The two are interchangeable.[!NOTE] At least one crypto backend is required, but any non-empty combination works. OpenSSL is enabled by default and can be disabled with
-DWITH_OPENSSL=OFF. Each backend parses and converts JWK(S) natively.
JWS Algorithm alg | OpenSSL | GnuTLS | MbedTLS |
|---|---|---|---|
HS256 HS384 HS512 | :white_check_mark: | :white_check_mark: | :white_check_mark: |
ES256 ES384 ES512 | :white_check_mark: | :white_check_mark: | :white_check_mark: |
RS256 RS384 RS512 | :white_check_mark: | :white_check_mark: | :white_check_mark: |
EdDSA using ED25519 | :white_check_mark: | :white_check_mark: | :x: |
EdDSA using ED448 | :white_check_mark: | :white_check_mark: | :x: |
PS256 PS384 PS512 | :white_check_mark: | :white_check_mark: | :white_check_mark: |
ES256K | :white_check_mark: | :x: | :white_check_mark: |
ML-DSA-44/65/87 [^mldsa] | :white_check_mark: | :white_check_mark: | :x: |
[^mldsa]: ML-DSA (FIPS 204, registered for JOSE by RFC 9964) is experimental and off by default. Build with -DWITH_ML_DSA=ON; it is only enabled when a backend with ML-DSA support is present: OpenSSL >= 3.5, or GnuTLS >= 3.8.10 built against a PQC provider (e.g. --with-leancrypto). When built in, the public header defines LIBJWT_HAVE_ML_DSA. ML-DSA keys use the "AKP" key type with a "pub" member and a "priv" member holding the 32-byte FIPS-204 seed. MbedTLS has no ML-DSA and rejects AKP keys.
LibJWT supports JWE (RFC 7516) in both the Compact Serialization and the JSON Serialization (the Flattened form and the General form with one or more recipients). A JWE uses two algorithms: a key management algorithm (alg) and a content encryption algorithm (enc).
| JWE serialization | Recipients | Supported |
|---|---|---|
| Compact (RFC 7516 §7.1) | one | :white_check_mark: |
| JSON Flattened (RFC 7516 §7.2.2) | one | :white_check_mark: |
| JSON General (RFC 7516 §7.2.1) | one or more | :white_check_mark: |
With the JSON serializations the plaintext is encrypted once with a single CEK; each recipient wraps that CEK independently, so any recipient's key can decrypt the token. They also carry an optional shared unprotected header, per-recipient headers, and an application AAD member.
Legend: :white_check_mark: native implementation · :x: not supported
JWE key management alg | OpenSSL | GnuTLS | MbedTLS |
|---|---|---|---|
dir (Direct Encryption) | :white_check_mark: | :white_check_mark: | :white_check_mark: |
A128KW A192KW A256KW | :white_check_mark: | :white_check_mark: | :white_check_mark: |
RSA-OAEP (SHA-1) | :white_check_mark: | :x: | :white_check_mark: |
RSA-OAEP-256 | :white_check_mark: | :white_check_mark: | :white_check_mark: |
ECDH-ES (+ +A128KW/+A192KW/+A256KW) | :white_check_mark: | :white_check_mark: | :white_check_mark: |
JWE content encryption enc | OpenSSL | GnuTLS | MbedTLS |
|---|---|---|---|
A128GCM A192GCM A256GCM | :white_check_mark: | :white_check_mark: | :white_check_mark: |
A128CBC-HS256 A192CBC-HS384 A256CBC-HS512 | :white_check_mark: | :white_check_mark: | :white_check_mark: |
[!NOTE]
ECDH-ESsupports both Direct Key Agreement and the+A*KWkey wrapping modes, on the EC curves P-256/384/521 and the OKP curves X25519/X448, with optionalapu/apvPartyInfo.RSA1_5andzip(compression) are intentionally not supported. Each backend implements JWE natively. GnuTLS/Nettle cannot perform RSA-OAEP with SHA-1, so the GnuTLS backend does not support plainRSA-OAEP(RSA-OAEP-256is native).
:link: Current Docs
:link: Legacy Docs v2.1.1
:link: GitHub Repo
LibJWT is available in most Linux distributions as well as through Homebrew for Linux, macOS, and Windows.
$ mkdir build $ cd build $ cmake .. $ make