Andy Garcia · freelance dev
FRENES
Back to the blog
Security

Auth0 Stops Running Rules and Hooks After November 18. A Rule That Denies Logins Stops Denying Them.

October 19, 2026 6 min read

Auth0's Deprecations and Migrations page lists three dates for Rules and Hooks: deprecated on May 16, 2023, read-only since November 18, 2024, end of life on November 18, 2026. The sentence under them is short: "After November 18, 2026, Rules and Hooks will stop being executed and removed."

The warning at the top of the Rules and Hooks documentation adds who is concerned. Neither product has been available to tenants created as of October 16, 2023. Existing tenants that had them kept them, and the replacement is Actions, which Auth0 introduced in 2020.

So the population is precise: any Auth0 tenant created before October 16, 2023 that still has an active Rule or Hook. Before Actions, Rules were how you customized an Auth0 login, so this is often old code in a critical path.

I am CTO of a LegalTech and I ship iOS apps as an indie developer. Login is the part of a product I least want to see changed by a vendor's calendar. Here is how I read the deadline, and what I would check before it.

"Stop being executed" is not "fail"

Note what the page does not say. It does not say logins will fail on November 19. It says the code stops running. That sounds safer than it is.

Rules run in the post-login pipeline. They typically do four kinds of things: add custom claims to ID and access tokens, trigger multi-factor authentication, write user metadata, and deny access. Hooks cover other moments: client credentials exchange, pre-user registration, post-user registration, post-change password and sending phone messages.

When that code stops running, each effect disappears on its own, and none of them announces itself:

  • A Rule that added a roles claim stops adding it. Nothing on the page says the login fails, so plan for it to succeed and for your API to receive tokens without the claim, and what happens next depends on how your API treats a missing claim.
  • A Rule that set context.multifactor for some users stops triggering MFA for them. Unless MFA is required some other way, they log in without it.
  • A Rule that refused logins (unverified email, wrong domain, blocked account flag) stops refusing them.
  • A pre-user-registration Hook that filtered sign-ups stops filtering.

A broken login gets reported fast. A check that quietly stopped running gets found by someone else, later.

The code has been frozen for almost two years

According to the same deprecations page, Rules and Hooks have been read-only since November 18, 2024. You can turn them on and off and change their configuration values or secrets, but you cannot edit their source code, not in the Dashboard, not through the Management API, not with Terraform or the Auth0 Deploy CLI. The page also warns that automated CI/CD flows must not attempt unsupported management operations on them.

Put differently: every Rule still running is code that, according to Auth0, nobody has been able to edit since November 18, 2024. If one of them has a bug, the only remedies left are disabling it or migrating it.

The date has moved before. Auth0's blog post of May 15, 2023 said Rules and Hooks would be removed from all tenants on November 18, 2024. That date became the read-only switch instead, and the deprecations page still carries the line "Auth0 has delayed the removal of Rules and Hooks functionality to a future date." Auth0's general Migration Process page also says end-of-life dates can vary between plan types. I would not plan on a second delay. If you are on an Enterprise contract and think you have different terms, get them in writing.

What the migration guides do not put up front

Auth0 publishes two guides, Rules to Actions and Hooks to Actions, plus a "Migrate to Action" tool in the Dashboard. They are good. Four details deserve more attention than they get.

Order matters. Rules run before Actions. Auth0's migration tooling page says to migrate in reverse order: the last Rule in the flow first, then work back to the first. Migrated Actions can call api.rules.wasExecuted() with the Rule ID so the same logic does not run twice while both are active.

The guides name stale runtimes. The Rules guide still tells you to select Node 16 when creating the Action, the Hooks guide Node 18, a version the Node.js project stopped supporting on April 30, 2025. The same deprecations page says the Node 12 and 16 extensibility runtimes reached end of life on August 15, 2025, and that once they are removed, extensibility code is forced to run on Node 22. I would write and test every migrated Action on Node 22.

Some Rule habits do not survive. Actions get no Management API access token and no global auth0 object. To call the Management API, you register a machine-to-machine application and authorize it. Secrets are set per Action, while Rules shared one global configuration. The Actions cache keeps items for 24 hours at most, 20 entries per trigger, 8 kB in total, and is not guaranteed between executions. A trigger must finish in 20 seconds. On the Hooks side, Actions cannot persist data such as access tokens across executions.

Some things have no equivalent yet. Auth0's Actions Migration Limitations page lists them: no replacement for context.connectionOptions, no access to upstream identity provider tokens through user.identities, standard claims of an ID token cannot be deleted, Actions return "access denied" but not "unauthorized", and for linked accounts, Actions only support modifying the primary user. A Rule that depends on one of these is not a copy and paste. It is a redesign, and it should be the first one you look at, not the last.

What I would check before November 18

If I inherited an Auth0 tenant on a freelance project, this is the order I would follow.

  1. List every tenant, not just production. Development, staging, the old demo tenant a client still uses. Note each creation date. Anything created before October 16, 2023 gets checked.
  2. List every enabled Rule (Auth Pipeline > Rules in the Dashboard) and every enabled Hook. Copy each one's code: read-only code can still be read, and Auth0's own guide starts by copying it.
  3. Write down each effect and its consumer. "Adds https://example.com/roles to the access token, read by the billing API." The consumer is where the failure will show, so that is what you test.
  4. Decide what a missing claim means. If your API treats a missing roles claim as an ordinary user, a removed Rule downgrades people. If it treats it as "no restriction", you have a hole. The safe default is to refuse, and you can ship that before migrating anything.
  5. Migrate last Rule first, on Node 22, in a development tenant. Use the Dashboard tool, keep wasExecuted in place, then disable the Rule.
  6. Compare tokens. Decode an ID token and an access token issued before the migration and one issued after, for the same test user. Every custom claim present before should still be there after.
  7. Clean the deployment config. If Terraform or the Deploy CLI still declares Rules or Hooks, remove them once the Actions are live, so your pipeline stops managing resources Auth0 removes after November 18.

This is also the kind of inventory I would hand to Claude Code: read the copied Rules, list every claim, denial and external call they make, and grep the codebase for every consumer of those claims. The judgment stays with me. The reading goes faster.

For a small business that had an app built by an agency before late 2023, the question is simpler. Ask whoever holds the Auth0 account whether the tenant has active Rules or Hooks. If nobody knows who holds it, that is the first thing to fix.

Auth0 gave this code two extra years. Spend the last weeks finding out what it was doing.

Sources

A project like this one?

I design and deploy products like this. Let's talk.

Let's talk