Map of JWT provider name to Provider. If specified, multiple providers will be OR-ed together and will allow validation to any of the providers.
allowMissingOrFailedJwt
bool
Allow pass through of JWT requests for this virtual host, even if JWT token is missing or JWT auth failed. If this is false (default false), requests that fail JWT authentication will fail authorization immediately. For example, if a request requires either JWT auth OR another auth method, this can be enabled to allow a failed JWT auth request to pass through to the other auth method. Deprecated: use validation_policy instead.
Optional: Configure how JWT validation works, with the flexibility to handle requests with missing or invalid JWTs. By default, after applying JWT policy to a route, only requests that authenticate with a valid JWT succeed.
ValidationPolicy
Name
Description
REQUIRE_VALID
Default value. Allow only requests that authenticate with a valid JWT to succeed. Note that the allowMissingOrFailed=true setting takes precedence. In such a case, even if you explicitly set validationPolicy=REQUIRE_VALID, this field is ignored.
ALLOW_MISSING
Allow requests to succeed even if JWT authentication is missing, but fail when an invalid JWT token is presented. You might use this setting when later steps depend on input from the JWT. For example, you might add claims from the JWT to request headers with the claimsToHeaders field. As such, you may want to make sure that any provided JWT is valid. If not, the request fails, which informs the requester that their JWT is not valid. Requests without a JWT, however, still succeed and skip JWT validation.
ALLOW_MISSING_OR_FAILED
Allow requests to succeed even when a JWT is missing or JWT verification fails. For example, you might apply multiple policies to your routes so that requests can authenticate with either a JWT or another method such as external auth. Use this value to allow a failed JWT auth request to pass through to the other authentication method.
Fetch Jwks asynchronously in the main thread before the listener is activated. Fetched Jwks can be used by all worker threads. If this feature is not enabled: * The Jwks is fetched on-demand when the requests come. During the fetching, first few requests are paused until the Jwks is fetched. * Each worker thread fetches its own Jwks since Jwks cache is per worker thread. If this feature is enabled: * Fetched Jwks is done in the main thread before the listener is activated. Its fetched Jwks can be used by all worker threads. Each worker thread doesn’t need to fetch its own. * Jwks is ready when the requests come, not need to wait for the Jwks fetching.
LocalJwks
"key": string
Field
Type
Description
key
string
Inline key. this can be json web key, key-set or PEM format.
