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
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
| -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
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