Taxonomy of a Webtask Token
Webtask token is required to execute webtasks
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/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
controls whether key value pairs resulting from parsing of the request body are merged into the
context.data unless an identically named property already exists in
mb claim only makes sense in conjunction with
mb claims can also be specified as
webtask_mb claims within the
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.