From: Remi Tricot-Le Breton Date: Mon, 30 Jun 2025 14:56:31 +0000 (+0200) Subject: DOC: 'jwt_verify' converter now supports certificates X-Git-Tag: v3.3-dev3~59 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=94d750421c3c158f0f16f9034f13adcc2daa493f;p=thirdparty%2Fhaproxy.git 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. --- diff --git a/doc/configuration.txt b/doc/configuration.txt index 895dab118..d98584d46 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -20518,9 +20518,14 @@ jwt_payload_query([[,]]) jwt_verify(,) Performs a signature verification for the JSON Web Token (JWT) given in input by using the algorithm and the 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(,) If the used algorithm is of the HMAC family, should be the secret used in the HMAC signature calculation. Otherwise, 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(,) | -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(,) 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([,]) Returns the value with the highest q-factor from a list as extracted from the