jwt block lets you configure JSON Web Token access control for your gateway.
Like all access control types, the
jwt block is defined in
definitions Block and can be referenced in all configuration blocks by its
Since responses from endpoints protected by JWT access controls are not publicly cacheable, a
Cache-Control: private header field is added to the response, unless this feature is disabled with
disable_private_caching = true.
|Definitions Block||⚠ required|
References a backend in definitions for JWKS requests. Mutually exclusive with
If set to
Object with claims that must be given for a valid token (equals comparison with JWT payload). The claim values are evaluated per request.
Read token value from a cookie. Cannot be used together with
Log fields for custom logging. Inherited by nested blocks.
If set to
Read token value from the given request header field. Implies
Time period the cached JWK set stays valid after its TTL has passed.
Time period the JWK set stays valid and may be cached.
URI pointing to a set of JSON Web Keys (RFC 7517)
Public key (in PEM format) for
Reference to file containing verification key. Mutually exclusive with
Name of claim containing the granted permissions. The claim value must either be a string containing a space-separated list of permissions or a list of string permissions.
Mapping of granted permissions to additional granted permissions. Maps values from
Reference to JSON file containing permission mappings. Mutually exclusive with
List of claim names that must be given for a valid token.
Name of claim specifying the roles of the user represented by the token. The claim value must either be a string containing a space-separated list of role values or a list of string role values.
Mapping of roles to granted permissions. Non-mapped roles can be assigned with
Reference to JSON file containing role mappings. Mutually exclusive with
Private key (in PEM format) for
Reference to file containing signing key. Mutually exclusive with
The token's time-to-live (creates the
Expression to obtain the token. Cannot be used together with
token_value are mutually exclusive.
If all four attributes are missing,
bearer = true will be implied, i.e. the token will be read from the incoming
Authorization: Bearer ... header.
Deprecation Note: Configuring
header = "Authorization" to read from the incoming
Authorization: Bearer ... header is deprecated. Use
bearer = true instead.
If the key to verify the signatures of tokens does not change over time, it should be specified via either
key_file (together with
Otherwise, a JSON web key set should be referenced via
jwks_url; in this case, the tokens need a
A JWT access control configured by this block can extract permissions from
- the value of the claim specified by
- the result of mapping the value of the claim specified by
jwt block may also be referenced by the
jwt_sign() function, if it has a
signing_ttl defined. For
HS* algorithms the signing key is taken from
signing_key_file have to be specified.
signing_ttlcannot have the same label as a
timeout = "300s"
Configures a backend for JWKS requests (zero or one). Mutually exclusive with
Configures an error handler (zero or more).