DOC: 'jwt_verify' converter now supports certificates

The 'jwt_verify' converter can now accept certificates as a second
parameter, which can be updated via the CLI.
This commit is contained in:
Remi Tricot-Le Breton 2025-06-30 16:56:31 +02:00 committed by William Lallemand
parent db5ca5a106
commit 94d750421c

View File

@ -20518,9 +20518,14 @@ jwt_payload_query([<json_path>[,<output_type>]])
jwt_verify(<alg>,<key>)
Performs a signature verification for the JSON Web Token (JWT) given in input
by using the <alg> algorithm and the <key> parameter, which should either
hold a secret or a path to a public key. The public key should either be in
the PKCS#1 format (for RSA keys, starting with BEGIN RSA PUBLIC KEY) or SPKI
format (Subject Public Key Info, starting with BEGIN PUBLIC KEY).
hold a secret, a path to a public key or a path to a public certificate. When
using a public key, it should either be in the PKCS#1 format (for RSA keys,
starting with BEGIN RSA PUBLIC KEY) or SPKI format (Subject Public Key Info,
starting with BEGIN PUBLIC KEY). Certificates should be a regular PEM
certificate (starting with BEGIN CERTIFICATE). If a full-on certificate is
used, it can either be used directly in the converter or passed via a
variable if it was already known by haproxy (previously loaded in a crt-store
for instance).
Returns 1 in case of verification success, 0 in case of verification failure
and a strictly negative value for any other error. Because of all those
non-null error return values, the result of this converter should never be
@ -20534,12 +20539,15 @@ jwt_verify(<alg>,<key>)
If the used algorithm is of the HMAC family, <key> should be the secret used
in the HMAC signature calculation. Otherwise, <key> should be the path to the
public key that can be used to validate the token's signature. All the public
keys that might be used to verify JWTs must be known during init in order to
be added into a dedicated cache so that no disk access is required during
runtime. For this reason, any used public key must be mentioned explicitly at
least once in a jwt_verify call. Passing an intermediate variable as second
parameter is then not advised.
public key or certificate that can be used to validate the token's signature.
All the public keys and certificates that might be used to verify JWTs must
be known during init in order to be added into a dedicated cache so that no
disk access is required during runtime. For this reason, any used public key
must be mentioned explicitly at least once in a jwt_verify call and every
certificate used must be loaded by haproxy (in a crt-store or mentioned
explicitly in a 'jwt_verify' call). Passing a variable as second parameter is
then not advised unless you only use certificates that fill one of those
prerequisites.
This converter only verifies the signature of the token and does not perform
a full JWT validation as specified in section 7.2 of RFC7519. We do not
@ -20559,6 +20567,7 @@ jwt_verify(<alg>,<key>)
| -3 | "Invalid token" |
| -4 | "Out of memory" |
| -5 | "Unknown certificate" |
| -6 | "Internal error" |
+----+----------------------------------------------------------------------+
Please note that this converter is only available when HAProxy has been
@ -20570,7 +20579,7 @@ jwt_verify(<alg>,<key>)
http-request set-var(txn.bearer) http_auth_bearer
http-request set-var(txn.jwt_alg) var(txn.bearer),jwt_header_query('$.alg')
http-request deny unless { var(txn.jwt_alg) -m str "RS256" }
http-request deny unless { var(txn.bearer),jwt_verify(txn.jwt_alg,"/path/to/pubkey.pem") 1 }
http-request deny unless { var(txn.bearer),jwt_verify(txn.jwt_alg,"/path/to/cert.pem") 1 }
language(<value>[,<default>])
Returns the value with the highest q-factor from a list as extracted from the