标签：#auth0

Auth0’s direction is clear: new extensibility work should be built with Actions, not Rules. Auth0’s docs recommend migrating existing logic step by step, converting pieces of Rule code into Action code, testing in staging, and then rolling out one piece at a time. The platform also highlights that Actions give you modern JavaScript, inline documentation, richer type information, and access to public npm packages. I recently looked at the migration path with one question in mind: how do you move from “old but working” to “clean, testable, future-proof” without breaking login flows? This post is the practical version of that answer. Why Auth0 moved from Rules to Actions Rules were Auth0’s earlier customization layer for authentication flows. Actions are the next-generation extensibility platform, built to replace that model with a more structured developer experience. Auth0 positions Actions as a unified environment with version control, debugging, caching, Node 18 support, and access to millions of npm packages. The biggest shift is not just syntactic. Actions use a modern, promise-based programming model and are organized around triggers such as Post Login. That means you are no longer writing the same kind of callback-style Rule you may have used before; you are moving into a more explicit and modular workflow. The mental model change A Rule usually looks like this: it receives user , context , and callback it runs in a broader authentication pipeline it often mixes business logic with token customization, user metadata updates, and side effects An Action, by contrast, is built around a trigger such as onExecutePostLogin , and it receives an event object plus an api object. Auth0’s migration guide explicitly recommends converting Rule code into Action code in stages rather than copying everything at once. That one change matters because it forces you to separate concerns: what is read from the event what is changed through the API what should happen in this trigger

Every identity migration guide eventually reaches the same paragraph, and it's always a little apologetic: "users will need to reset their passwords." It gets treated like a law of nature. It isn't. It's a choice, usually forced by a tool that didn't want to do the harder thing. The harder thing is verifying your users' existing password hashes in place, so they sign in after the move with exactly the credentials they had before and never notice anything happened. Whether you can do it comes down to one question: can you get the old hashes, and can the new system verify them? Password hashes are more portable than people think A password hash isn't a secret algorithm. bcrypt is bcrypt. A bcrypt hash carries its own cost factor and salt inside the string, so anything that implements bcrypt can verify a hash any other bcrypt system produced. The same is true of the PBKDF2 format ASP.NET Identity uses: documented, versioned, self-describing. If you know what you're holding, you can check a password against it without ever knowing the password. So a migration that preserves logins doesn't need the plaintext (nobody has it) and doesn't need to re-hash everyone up front. It needs to obtain the stored hashes and verify against them on sign-in, upgrading each one to its own format quietly the first time a user logs in. That last part is lazy migration: carry the old hash, verify it once, replace it transparently. Over a few weeks of normal logins your user table re-hashes itself and the legacy formats age out, with zero resets and zero support tickets. The dual-path bit The wrinkle is that different sources hand you different formats, and a good importer verifies both: From self-hosted Duende / ASP.NET Identity: the V3 PBKDF2 hashes (and any legacy bcrypt) verify natively and rehash on first sign-in. This is the easy case, because it's the same scheme the destination already uses. Most teams are surprised it's that clean. From Auth0: bcrypt hashes verify verbatim. The catch