Taxonomy of a Webtask Token

Webtask token is required to execute webtasks

For customized documentation and ready to run samples, please log in.

Webtask token

Auth0 webtask cluster endpoints require the caller to present a webtask token to authorize operations in the cluster. Technically webtask tokens are JWT tokens, but from the caller's perspective they can be treated as opaque blobs.


Tokens carry fine-grained information about permissions of the token holder with respect to operations on the webtask cluster. Currently webtask tokens allow following restrictions to be specified in the form for JWT token claims:


is a restriction on the webtask container name in which webtask requests authenticated with that token can execute code. You can provide a regular expression (e.g. /^foo[0-9]$/) or a comma-delimited list of string literals (e.g. foo1,foo2) which must match against the request webtask container name for the request to be authorized.


is a not-before time restriction in Unix time.


is a not-after time restriction in Unix time.


is an JSON object with string properties which specify parameters that will be provided to the webtask code at the time of execution. The properties are signed and protected from interference but not encrypted - anyone with access to the token can read their value.


is an JSON object with string properties which specify parameters that will be provided to the webtask code at the time of execution. The properties are both signed and encrypted, which makes them tamper-proof and inaccessible to third parties, including the bearer of the token. This is a convenient mechanism to pass secrets to the webtask code (e.g., database connection strings).


is the URL of the webtask code to execute. Webtask requests authenticated with a token that contains the url property must not specify the code to execute at all. The webtask cluster will obtain the code from the URL specified in url with HTTP GET. This is a mechanism you can use to fix the code a given token can execute.


controls parsing of the request body. If set to 1, then request bodies of requests with application/json or application/x-www-form-urlencoded will be parsed by the webtask infrastructure and stored in context.body parameter when the custom code is invoked. Using pb claim only makes sense when the code is specified through the url claim.


controls whether key value pairs resulting from parsing of the request body are merged into the context.data parameter. If set to 1, properties of the JavaScript object representing the body will be copied to context.data unless an identically named property already exists in context.data`. Using mb claim only makes sense in conjunction with url and pb claims.


The url, pb, and mb claims can also be specified as webtask_url, webtask_pb, and webtask_mb claims within the pctx or ectx structure. Values specified in the ectx structure take precedence over values specified in pctx structure, which in turn take precedence over values specified through token claims itself.

Encrypted code URL

Storing the URL of the code to execute as webtask_url property of ectx structure allows you to securely obtain the code from a secret URL (e.g., a URL with embedded basic authentication credentials or other credentials). Since the ectx structure is encrypted, owners of the token will not be able to access the location of the code. You can use this capability to obtain code from private GitHub repositories.