Deadline Alert: Migrate Auth0 Rules and Hooks to Actions Before November 18

On November 18, 2024, Auth0 tenants will no longer be able to run custom code stored in Rules and Hooks. Organizations need to migrate to Actions before the deadline to avoid failing logins, broken integrations, and unhappy customers.

In this article, we’ll look at:

• The difference between Rules, Hooks, and Actions
• How to know if you’re affected
• How to migrate to Actions

If you need help migrating by the deadline, talk to us to learn more about how we can help you do this safely while improving your Auth0 best practices.

What are Rules, Hooks, and Actions?

Rules, Hooks, and Actions all allow customisation of Auth0’s behaviour through snippets of JavaScript. They allow claims to be added to tokens, third party APIs to be consulted, MFA enforcement, redirects, and so on. Rules was Auth0’s basic solution for customization, first released in 2014. Hooks came along in 2019 and expanded what could be achieved with custom code. Actions was released in 2021 as a more flexible and modern successor to both.

Am I affected?

If you created a tenant on or after October 16, 2023, you are not affected. If your tenant is older, log in to the Auth0 Dashboard and navigate to the Auth Pipeline. There you’ll find Rules and Hooks. You’ll need to migrate each of these to Actions before the deadline.

Migrating to Actions

Auth0 has done a good job outlining the steps involved:

• https://auth0.com/docs/customize/actions/migrate/migrate-from-rules-to-actions
• https://auth0.com/docs/customize/actions/migrate/migrate-from-hooks-to-actions

Mostly, this involves fairly straightforward changes to accessors (e.g. user.email becomes event.user.email).

Beyond the basics, we have some advice we recommend organizations follow while completing this migration.

Automated testing for Actions

We strongly recommend adding an automated test suite to your Auth0 Actions to cover edge cases and error handling.

You can do this with Kilterset’s Auth0 Actions Testing library, which will also let you develop Actions locally. Coupled with a CI/CD pipeline, Auth0’s a0deploy CLI tool, and good peer review for code changes, you can build a robust process around safely making changes to Actions with relatively small effort.

You’ll also want to test manually using a pre-production tenant, to give yourself confidence there is no negative impact to users.

Read our tutorial on Auth0 automated Actions testing.

Migrating from modified context to stateless Actions

Hooks and Rules have ways of passing in-memory information from one Hook or Rule to another. For example, in a Rule you can add properties to the user and context objects, which can be read by a subsequent Rule. In Actions, any modifications you make will not survive changes between one Action and another.

Solutions will depend on what you’re trying to accomplish, but possible solutions are:

• Set secrets (accessed via event.secrets) to persist fixed configuration that will be global to all instances of a particular Action (e.g. long-lived API tokens such as OAuth refresh tokens).
• Use api.cache.set(name, value) and api.cache.get(name) to persist short-lived API access tokens that periodically expire, such as access tokens. By default, these are kept for 15 minutes, but you use the expires_at or ttl options to keep them for up to 24 hours.
• Use api.user.setAppMetadata(name, value) as a way to store state specific to a user. Be warned, though – this will store the metadata against the user and therefore be available to all Actions. This may not be suitable for ephemeral states tied to a specific chain of Actions.
• For some situations, Auth0 Forms' programmable logic may make sense. Forms is a relatively new feature of Auth0, one with its own a distinct notion of “actions”. They can also be triggered by an Auth0 Action.
• As a last resort, you can use a fetch or api.redirect.sendUserTo(url[, options]) (see docs, supports encoding state) to relocate logic outside of Auth0.

A good rule of thumb is that if there is conditional logic based on the state of a user, that should live in metadata and conditionals should check the metadata. If you are dealing with API tokens: long-lived ones live in event.secrets and short lived ones should be in theapi.cache. If there is something specific to a particular event (e.g. a specific instance of a login for a user), you may need to a more complicated solution.

Migrating calls to auth0 or the Auth0 Management API

Rules include an auth0.accessToken value that you can use to access the Management API. In Actions, you solve this the same way you would in an external application that needs to use the Management API: by registering a new Machine-to-Machine application, and setting the client ID and client secret as secrets for your action. You can then add auth0 as a dependency, and instantiate a ManagementClient as you did before.

Looking for help

We hope this information helps Auth0 practitioners migrate. If your organization is looking for expertise or a quick win, you can hire us to help you migrate before the deadline. We can help you migrate with confidence, and help your team adopt best practices for managing Auth0 in the process – with version-controlled changes, a CI/CD pipeline, and a full test suite for your Actions.

‍