Auth0 Rules and Hooks to Actions before end of life
Cohash moves Auth0 Rules and Hooks to Actions before Auth0 retires them on 18 November 2026. We export each rule and hook and map it to the Actions trigger it belongs on. Actions have no global object and no built-in Management API token, so we replace those with Action secrets and a machine-to-machine client. Redirects get rebuilt. Then we compare ID and access token claims before and after, so your applications see no change.
- 01Export and read every rule and hook
- 02Map to triggers
- 03Replace what Actions don't provide
- 04Rebuild redirects and claims
- 05Test and switch in one deploy
The story
Told without the client's name or anything that could identify them.
A software company's customer identity team had an Auth0 tenant that predated Actions, still full of Rules and Hooks, with the 18 November 2026 end-of-life date close. Several rules used the global object, called the Management API with the built-in token, or redirected users with context.redirect, and nobody was sure which rules still mattered. We exported every rule and hook with the Deploy CLI into source control and marked each one keep, merge or delete. The survivors were rewritten as Actions on the right triggers, with a machine-to-machine client and Action secrets for Management API calls. Each cut-over disabled the rule and bound the Action in the same deploy, and ID and access token claims matched the captured tokens from the old rules.
why it was urgentAuth0's documentation sets 18 November 2026 as the end-of-life date for Rules and Hooks, which have not been available to tenants created since 16 October 2023. Auth0 also says new Rules or Hooks should only be created in development tenants to test a migration. Any tenant still running them has weeks, not months.
- openThe tenant still shows active Rules or Hooks in the dashboard.
- recurringRules use the global object or call the Management API with the built-in token.
- blockedA rule redirects users to a consent, profile or MFA page with context.redirect.
- openNobody really knows which rules still matter. The tenant has been running since before Actions existed.
The estate, before and after
Before: Rules and Hooks ran every login
Rules ran in sequence on each login, passed state through shared objects and called the Management API with the built-in token. Hooks handled client credentials and registration events, and both stop running on 18 November 2026.
Read the diagram as text
- Customer apps → Rules pipeline: login
- API clients → Hooks: token request
- Rules pipeline → Management API: every login
- Rules pipeline → Consent and profile pages: redirect
- Rules pipeline → ID and access tokens: add claims
- Hooks → ID and access tokens: add scopes
After: Actions bound to the right triggers
Rules and Hooks are gone. Post-login and credentials-exchange Actions do their job, deployed from source control with the Deploy CLI. A dedicated machine-to-machine client makes the Management API calls, and its secret sits in Action secrets.
Read the diagram as text
- Actions code repo → Post-login Actions: deploy
- Actions code repo → Credentials-exchange Action: deploy
- Action secrets → Post-login Actions: secret
- Post-login Actions → Management API: scoped calls
- Post-login Actions → Consent and profile pages: api.redirect
- Post-login Actions → ID and access tokens: set claims
- Credentials-exchange Action → ID and access tokens: set scopes
How we run it, phase by phase.
5 phases take you from Auth0 Rules and Hooks to Auth0 Actions. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Export and read every rule and hook
We export Rules, Hooks, their configuration values and execution order into source control with the Auth0 Deploy CLI. Then each one gets marked keep, merge or delete. Old tenants tend to carry rules that do nothing now.
- phase 02
Map to triggers
Rules become post-login Actions. Client Credentials Exchange hooks move to the credentials-exchange trigger, and pre-registration, post-registration, post-change-password and send-phone-message hooks map to their matching triggers.
- phase 03
Replace what Actions don't provide
Actions don't get a Management API token or a global object. Anything that needs the Management API goes through a machine-to-machine application whose credentials sit in Action secrets. We also cut the number of calls, because tokens can't be cached between executions.
- phase 04
Rebuild redirects and claims
Any context.redirect flow is rebuilt as an api.redirect call with an onContinuePostLogin handler. Custom claims get set with the Actions API, and we check them against tokens we captured from the old rules.
- phase 05
Test and switch in one deploy
Each Action is tested in a development tenant against recorded logins. In production, the same deploy disables the rule and binds the Action to its flow, and we keep the export for rollback until the end-of-life date.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Logins run on Actions before the deadline
We turned Rules into post-login Actions and moved Hooks to their matching triggers. So when Rules and Hooks hit end of life, nothing stops adding claims or blocking logins.
- result 02
Applications see the same tokens
ID and access token claims were checked per application against tokens we captured from the old rules. Nothing downstream had to change.
- result 03
Management API calls use a scoped client
The built-in token is gone. A machine-to-machine application with its credentials in Action secrets does that job now, and per-login calls were cut back to stay under the rate limits.
- result 04
Tenant logic lives in source control
Actions code and Deploy CLI configuration are in version control now. Dead rules from earlier years were deleted, not carried forward.
- result 05
Redirect flows were tested in a browser
We rebuilt consent and profile completion redirects with api.redirect and onContinuePostLogin and tested each one through the continue step.
Risks we plan for
-
Shared state between rules
A lot of rules hand data to the next rule through the user or context objects. That doesn't carry over. Auth0 says data changed on the event object isn't visible to other Actions, so chained logic gets redesigned.
-
Management API rate limits
A rule that called the Management API on every login can start hitting rate limits once each Action fetches its own token. We cut those calls, or move the data to app metadata, before go-live.
-
Redirect flows that half work
Auth0's own guide says getting every redirect right in Actions is beyond its scope. So consent and profile completion flows get full browser tests, continue step included.
-
The deadline
Rules stop running after 18 November 2026. Whatever hasn't been migrated stops adding claims or blocking logins that day. It can fail open, or fail closed.
Where AI helps, and where it needs guardrails
Auth0 for AI Agents, generally available since 19 November 2025, adds Token Vault and asynchronous authorization, and Auth for MCP went GA on 21 May 2026. Actions are where agent-specific claims and checks will live, so the rewrite should leave room for them. Coding assistants can translate rule JavaScript to Actions syntax quickly, but each translation is judged by comparing real token claims, not by reading the code.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Exported inventory of Rules and Hooks with a keep, merge or delete decision
yours to keep - code02
Actions code in source control with Deploy CLI configuration
yours to keep - design03
Machine-to-machine client and secrets design for Management API calls
yours to keep - document04
Before-and-after token claim comparison per application
yours to keep - runbook05
Cut-over and rollback runbook
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01What happens if we miss 18 November 2026?
That's the end-of-life date Auth0 set for Rules and Hooks. Logic still in them stops running, and the claims, blocks and redirects they handled go with it. Plan to be done with time to spare.
02Can Rules and Actions run side by side?
Yes, during the migration. We move one rule at a time, disabling it and binding its Action in the same deploy, so the tenant is never without the logic.
03How long does the rewrite take?
It depends on how many rules and hooks you have, how many call the Management API or external services, and how many redirect. Simple claim rules convert quickly; redirect and enrichment flows take longer to test.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyCentrify and Delinea Server Suite zones to modern server identity
Untangling Centrify and Delinea Server Suite zones, UID maps and dzdo roles, and moving Linux and Windows servers to a server identity model you can run.
read the case study2da70361 - 01Auth0 docs: Rules (end-of-life notice)auth0.com ↗
- 02Auth0 docs: Migrate from Rules to Actionsauth0.com ↗
- 03Auth0 blog: Auth0 for AI Agents is generally available (19 Nov 2025)auth0.com ↗
- 04Okta newsroom: Auth0 product innovations (21 May 2026)okta.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it