Actions - Beta
Actions are secure, tenant-specific, self-contained functions that allow you to customize the behavior of Auth0. Each action is bound to a specific triggering event on the Auth0 platform. Auth0 invokes the custom code of these Actions when the corresponding triggering event is produced at runtime.
Triggers
Triggers are events that, when they occur, prompt associated Actions to run; they are organized under flows. Each flow represents the logical pipeline through which information moves during a single point in the Auth0 journey. Examples of flows include logging in a user via the login flow and getting an access token using the client credentials grant via the machine-to-machine (M2M) flow.
Remember that:
Triggers are synchronous, or blocking, which means they execute the Actions as part of the flow's process and will prevent the flow from executing until the Actions are complete.
If you have configured your flow with triggered Actions combined with Rules and/or Hooks, your Rules will execute first, followed by your Hooks, and then your Actions.
Flow | Trigger | Description |
---|---|---|
Login | Post-Login | Allow custom actions to be executed when a user logs in. For example, you may want to implement MFA in an unconventional way, such as by enabling it only when a user is trying to log in from outside a list of allowed cities. |
M2M | Client Credentials Exchange | Allow custom actions to be executed when an Access Token is issued through the Authentication API POST /oauth/token endpoint using the Client Credentials Flow. For example, you may prevent the token from being issued, add custom claims to the Access Token, or modify its scopes. |
Bindings
Bindings are the association between deployed Actions and their corresponding Trigger. Bindings may be added, removed, and re-ordered before committing the updated set of Bindings to Auth0.
Action versions
Each Action has a draft version and zero or more deployed versions; each draft or deployed version is identified by an ordinal number. Draft versions may be tested and modified prior to being deployed. Newly-created actions will not be invoked until they have first been deployed and bound to a Trigger. Once an Action is bound to a Trigger, deploying subsequent versions of that Action will result in the new version being immediately effective at runtime.
Limitations
To ensure system performance and support platform stability, the following limits apply to Actions.
Entity limits
Each tenant may have a maximum of 100 Actions (including both deployed and undeployed). When an Action is deleted, it no longer counts toward the limit.
Each Action may have a maximum of 50 associated versions (both draft and active). Once the limit is reached, every additional version that is added will result in the oldest version being deleted.
Each flow may have a maximum of 5 active bound Actions.
Sub-entity limits
Secrets
Each key may have a maximum length of 128 characters.
Each value may have a maximum length of 2048 characters.
Code
Each action may have a maximum code size of 100KB.
Dependencies
Each action may have a maximum of 10 npm modules.
console.log output
As a part of executions, a maximum of 256 characters may be persistently stored.
User metadata/app metadata persistence
Each session may have a maximum of 4KB each of user metadata persistence.
Each session may have a maximum of 4KB of app metadata persistence.
Log limits
Logs are retained for 1 day.
Log streaming is not supported.
Listed log limits will apply to all customers during the Beta, regardless of subscription plan.