Skip to content

Token (JWT) Auth

Auth using a Token (JWT)

This block allows you to check that an incoming request is from a logged in user.

You can use it with third party auth solutions such as Clerk, Auth0, Okta, Ory, etc.

If an invalid token is provided, it will return a 401 Unauthorized response.
If it is valid, you can then use the claims in the JWT to further authorize the request. The block provides several ways to validate claims:

  • Issuer (iss): Verify the token comes from a trusted source by checking if it matches your expected issuer (e.g., “https://auth.example.com”)
  • Subject (sub): Validate the token belongs to a specific user or entity (e.g., “user_123”, “service_account_456”)
  • Audience (aud): Ensure the token is intended for your application by matching your expected audience (e.g., “my-api-service”)
  • Authorized Party (azp): Verify which client application requested the token (e.g., “frontend-app”)
  • Custom Claims: Check any additional claims in the JWT using the Custom Claim Validation parameter. You can:
    • Match exact values (e.g., role: "admin")
    • Check against multiple allowed values using a JSON array (e.g., role: ["admin", "editor"] - You can also build an array directly on the tree if you expose the parameter as a Data Structure.)
    • Use JSON path notation to check nested claims

If any of these validation checks fail, the block will not authorize the trigger.


Parameters

ParameterParameterValid BlocksRequired
Manually Configure instead of using JWKS URL Manually configure instead of automatically using a JWKS URL. Boolean Block Group No
Auto Configure - Public key JWKS URL The JWKS URL used to auto configure the public key. Text Block Group No
PEM-encoded RSA Public Key The PEM-encoded RSA *Public* key for signature verification Text Block Group No
Allowed Signing Algorithm The allowed signing algorithm. This prevents algorithm substitution attacks by ensuring only specified algorithms are accepted (eg. "RS256"). Text Block Group No
Show Advanced Options If on, exposes advanced options. Boolean Block Group No
Token Location TokenLocation is where the JWT can be found in the request (ie. one of Header or Cookie) Text Block Group No
Auth Container Name AuthContainerName is the name of the header or cookie containing the JWT Text Block Group No
Expected Issuer (iss) The Expected Issuer (eg. "https://example.com"). This ensures the token was issued by a trusted entity. Text Block Group No
Expected Subject (sub) The Expected subject (eg. "user123", "admin123"). This can be used to ensure the token is for a specific user or entity. Text Block Group No
Expected Audience (aud) The Expected audience (eg. "my-backend-api"). Represents the intended recipient of the token, often the backend system or API that will validate and process the token. This ensures that the token is being sent to the correct server or service (Comnoco). Text Block Group No
Expected Authorized Party (azp) Expected authorized party (eg. "https://my-app.com"). Represents the client or frontend system that is authorized to use the token, often the application or service that initially requested the token from the authorization server. Text Block Group No
Custom Claim Validation A list of claims to validate on the JWT. If any of the claims are not present or do not match the expected value, the block will not authorise the trigger. Data Structure Block Group No