Skip to main content

HTTP JWT Tokenizer

Tokens may need to be re-issued or re-signed, this tokenizer handles that for you.

This tokenizer re-signs JWT authorization tokens with updated expiration times. The existing JWT is decoded and used as a template. Once modifications are complete, the JWT is re-signed using the secret provided. By default, all new signed tokens are valid for 48 hours.

Example

{
"type": "http_auth",
"config": {
"claims": "{\"sub\":\"speedscaleServiceUser\"}",
"prefix": "Bearer ",
"secret": "/home/speedscale/jwt/jwt"
"requestHeader": "Authorization",
"responseHeader": ""
}
}

Configuration

KeyDescription
claimsA list of key/value pairs that will be placed into the claims section of the newly signed token
prefixA required prefix for the Authorization header value. For example, if prefix is "JWTBearer " then only HTTP rrpairs with header value Authorization "JWTBearer headers.claims.sig" will be modified
secretThe filename of the secret to be used for the JWT re-encoding (generator must have these files available)
requestHeaderDefaults to Authorization, but can be set to another HTTP header
responseHeaderDefaults to Authorization, but can be set to another HTTP header
headerFilterA key/value map in the same format as claims that filters any JWTs that do not have the necessary headers
claimsFilterA key/value map in the same format as claims that filters any JWTs that do not have the necessary claims

Notes

  • Many http_auth tokens with different prefixes can be present in the same tokenizer configuration. Only the rrpairs matching the specific tokenizer will be utilized. Tokenizers are executed in the order they are presented in the configuration file.
  • Most errors are caused by the generator not having the secrets available in the filename provided OR the key being in the wrong format. For example, if alg=RS512 then the secret file must contain a valid RSA private key.