JWT Validator rule
- Checks if the JWT token is valid.
- If valid, processes the request.
- If invalid or expired, returns HTTP 401 Unauthorized.
Policy execution order
This JWT Validator rule authenticates the request and provides the security context that downstream policies (such as Authorize by Role) require. If another authentication policy has already set the security context, this rule skips itself.
Supported algorithms
- Elliptic Curve Digital Signature Algorithm (ECDSA): ES256, ES384, ES512
- Rivest–Shamir–Adleman (RSA): RS256, RS384, RS512
- Hash-Based Message Authentication Code using SHA (HSA): HS256, HS384, HS512
| Field Name | Description |
| When this rule should be applied | An expression that defines one or more conditions that must be
true for the rule to execute.
Example: The expression |
| Key Input Format | Select one of the following two options:
Note: The option you select determines the subsequent fields. Default value: RAW_TEXT |
Raw text format properties
With the RAW_TEXT format selected, the following fields display.
| Field Name | Description |
|---|---|
| Key |
Paste the contents of the public key, which can be a PEM Encoded key, a JSON Web Key (JWK), or a Client Secret. Default value: N/A Example:
|
| Extract into $token | Required. Use one or more of the following properties to specify where to find the token in the request. The rule checks locations in this order and uses the first match: Custom Header Keys, Custom Query String Parameter Keys, Authorization Header, Custom Cookie Key. If the token isn't found in any location, this rule passes the request to the next rule. |
| Custom Header Keys | The name of one or more header keys to check for the token. Click + to add more. Default value: N/A Example: x-jwt-key |
| Custom Query String Parameter Keys | The names of one or more query parameter keys to check for the token. Click + to add
more. Default value: N/A Example:
|
| Custom Cookie Key | The names of one or more cookie keys to check for the token. Click + to add more custom
cookies. Tip: In the request, the cookie value should contain the
JWT. Default value: N/A Example: |
| Authorization Header Type | If the key is in the Authorization header, this value is used as the “type” to check.
Bearer is the correct type for JWTs. Default value:
|
| Extract User Info | Required. Expressions that extract the user identity and role from the JWT claims. Both fields use JSONPath syntax where $ represents the root of the claims document. |
| User ID Expression | Required.Where to find the user ID in the token claim. Default value: N/A Example:
|
| Roles Expression | Required. Where to find the user role in the token claim. Default value: N/A Example: |
| Headers to add | Optional. Name-value pairs to pass information from the token in
the request header to pipeline parameters. For example, you might pass the user ID from the
token claim so that the underlying pipeline can retrieve it in a parameter. Example: To pass the role and token in the header:
To retrieve the token in pipeline parameters, add a Mapper Snap and map the
header values:
|
| Description | The purpose of the rule. |
URL format properties
With the URL format selected, the following properties are available.
| Field Name | Description |
|---|---|
| URL |
Enter the URL endpoint or click = to enter an expression to obtain the key. Default value: N/A Example: https://login.microsoftonline.com/%3Ctenant%3E/discovery/v2.0/keys |
| Extract Keys from URL | A JSONPath expression that extracts the key material from the URL response. The default $ uses the entire response body as the key set.Note: This rule supports
a list of JWK keys or a single JWK key and verifies against the kid field in the
JWT header. If you pass in a list of keys, only the key whose
kid matches the JWT header’s kid is used
for verification.Default value:
Example: |
| Extract into $token | Required. Use one or more of the following properties to specify where to find the token in the request. The rule checks locations in this order and uses the first match: Custom Header Keys, Custom Query String Parameter Keys, Authorization Header, Custom Cookie Key. If the token isn't found in any location, this rule passes the request to the next rule. |
| Custom Header Keys | The name of one or more header keys to check for the token. Click + to add more. Default value: N/A Example: x-jwt-key |
| Custom Query String Parameter Keys | The names of one or more query parameter keys to check for the token. Click + to add
more. Default value: N/A Example:
|
| Custom Cookie Key | The names of one or more cookie keys to check for the token. Click + to add more custom
cookies. Tip: In the request, the cookie value should contain the
JWT. Default value: N/A Example: |
| Authorization Header Type | If the key is in the Authorization header, this value is used as the “type” to check.
Bearer is the correct type for JWTs. Default value:
|
| Extract User Info | Required. Expressions that extract the user identity and role from the JWT claims. Both fields use JSONPath syntax where $ represents the root of the claims document. |
| User ID Expression | Required.Where to find the user ID in the token claim. Default value: N/A Example:
|
| Roles Expression | Required. Where to find the user role in the token claim. Default value: N/A Example: |
| Headers to add | Optional. Name-value pairs to pass information from the token in
the request header to pipeline parameters. For example, you might pass the user ID from the
token claim so that the underlying pipeline can retrieve it in a parameter. Example: To pass the role and token in the header:
To retrieve the token in pipeline parameters, add a Mapper Snap and map the
header values:
|
| Description | The purpose of the rule. |