Token validation (JWT)
Token validation: verify the JWT in a request on the node with your identity provider keys, then allow or block by the claims in the token.
What it does
The node verifies the JWT carried by a request with the public keys you registered: signature, expiry, issuer and audience, then allows or blocks by the claims in the token (for example a role). Verification happens at the edge, so requests need not go back to your auth service.
When to use it
- An API or admin area accepts only requests with a valid login token.
- Only tokens whose
roleisadminmay reach admin paths. - You use an identity provider such as Keycloak, Auth0 or Azure AD and its public JWKS URL.
Where to configure it
Two steps:
- Console menu "Token validation": add a "key set" with the public keys and validation requirements.
- In a WAF rule of a security policy, choose the condition field "JWT token" (valid, or invalid/missing) and "JWT claim", select that key set, and set the action to block or allow as needed.
Settings
Key set
| Setting | Default | Description |
|---|---|---|
| Name, description | None | The name is unique within the account |
| Key source | None | "Fetch JWKS from a URL" or "Paste JWKS"; cannot be changed after creation |
| JWKS URL | None | For the URL source; public https addresses only, fetched by the control plane |
| Refresh interval | 1 hour | 5 minutes, 15 minutes, 1 hour, 6 hours, 1 day |
| JWKS content | None | For the paste source; public keys only |
| Allowed algorithms | None | RS256, ES256, EdDSA |
| Token locations | None | Up to 4, the first one found is used: Authorization: Bearer, header, cookie, query parameter |
| Issuer iss | Empty | Not checked when empty |
| Audience aud | Empty | Several allowed; not checked when empty |
| Require expiry | On | A token without exp is invalid |
| Clock skew | 60 seconds | Allowed offset when checking expiry and start time |
| Response on failure | 403 | The 403 block page, or 401 with WWW-Authenticate: Bearer |
Each account can hold 50 key sets. A remote source is fetched once on creation and then at the refresh interval; if a fetch fails the previous keys stay in use and repeated failures send a notification. "Refresh now" is allowed once per minute.
Rule conditions
| Field | Operators | Description |
|---|---|---|
| JWT token | valid, invalid or missing | The value is a key set |
| JWT claim | equals, in, contains, exists, number at least, number at most | The claim path is dot-separated, such as roles or user.level |
A rule can have 1 JWT token condition and up to 4 claim conditions; claim conditions require a "JWT token valid" condition in the same rule.
FAQ
How do I check the setup
Click "Try it" in the key set list and paste a token. The page shows whether it is valid, the failure reason, the token header and the claims. The token is parsed within that request only and is neither stored nor logged.
What are the failure reasons
No token, malformed, algorithm not allowed, key not found (kid), bad signature, expired, missing exp, not yet valid, issuer mismatch, audience mismatch.
A key set shows a fetch failure
The list states the reason, for example DNS failure, an address pointing to a private network, a TLS certificate failure, or a response that is not a valid JWK Set. For an identity provider on a private network use "Paste JWKS".
Can I use HS256
Symmetric algorithms are not supported.
Platform administrator accounts do not see Token validation
The menu is for tenant accounts.