Rules for Authorization Policies
The End of Life (EOL) date of Rules and Hooks will be November 18, 2024, and they are no longer available to new tenants created as of October 16, 2023. Existing tenants with active Hooks will retain Hooks product access through end of life.
We highly recommend that you use Actions to extend Auth0. With Actions, you have access to rich type information, inline documentation, and public npm packages, and can connect external integrations that enhance your overall extensibility experience. To learn more about what Actions offer, read Understand How Auth0 Actions Work.
To help with your migration, we offer guides that will help you migrate from Rules to Actions and migrate from Hooks to Actions. We also have a dedicated Move to Actions page that highlights feature comparisons, an Actions demo, and other resources to help you on your migration journey.
To read more about the Rules and Hooks deprecation, read our blog post: Preparing for Rules and Hooks End of Life.
You can append Rules to the pre-configured authorization policy to exercise additional control over permitting or denying user access. A rule contains custom code that makes an authorization decision based on appropriate logic. When combined with other rules, it helps define what happens in different contexts.
Rules can restrict access based on any combination of attributes you store for users, such as user department, time of day, location, or any other user or API attribute (like username, security clearance, or API name).
For example, if you were using rules to provide finely-grained access control at a non-profit organization, you could give only W2 employees working in the Research and Development department in the New Delhi office access to an application.
For samples of rule implementations with authorization policies, read Sample Use Cases: Rules with Authorization.
Rules in the authorization process
Based on the order in which they run, rules can change the outcome of the authorization decision prior to the permissions being added to the Access Token. The basic process with rules injected is as follows:
The user tries to authenticate with the application.
Auth0 brings the request to the selected identity provider.
Once the identity provider confirms that user credentials are valid, all created rules run in the order in which they are configured in the Dashboard.
Assuming no rule has restricted the user's access, the user is authorized to access the application.