Rules, Hooks and Actions: Migration Common Questions

Knowledge Articles
1

Rules, Hooks and Actions: Migration Common Questions

  • How can I access the groups coming from Azure AD?
    The blogpost says that you can make more use of standard properties such as user.roles , user.groups , and user.permissions to understand customer profiles and protect user interests better. But the documentation page does not mention these new root properties at all.

Abovedmenionted attributes are not part of standard Auth0 profile, this is why they are not mentioned in our docs, but we do expose custom attributes that are coming from external IdPs. Make sure you are using an Action with the latest API (v3)

  • We need to be able to map employee roles that are set in Azure AD (Entra ID) to roles inside our application. As of today, we have not found a documented way to get the “appRoles” attribute from Azure AD with Actions. However, we are able to do it with Rules by calling the Microsoft Graph API at https://graph.microsoft.com/beta/servicePrincipals/{resourceId}. This is not possible with Rules because it doesn’t give us access to the original Azure AD access token. As an alternative, we would be fine with getting the AD groups with the Azure AD “groups” attribute that is passed in with the token. We just either need that attribute passed in, or access to the original Azure AD token.

The groups attribute should be available here:event.user.groups , make sure that your Action is on the latest API (v3).

  • We want to remove the nickname and picture claim from the id token after a user authenticates successfully. I successfully created a rule based on the remove attributes from user template. I migrated the code, by following the Auth0 documentation, to a Login Flow action script. The rule works fine, but the action script is not deleting the blacklisted keys.
    When will this functionality be available via an action script?

The event parameter in Actions is immutable, to change attributes on the idToken, use api.idToken.setCustomClaim('picture', undefined);

  • HWe need an Example using “Actions” to securely link accounts. We have a SPA page that uses the New Universal Login for logins/signups, users can sign in either with an email/password or with social connections (Google, Github), and we are trying to implement the process of linking accounts at signup. It would also be helpful to have a working demo with a basic front end and back end in a git repository, rather than just snippets of code around.

We have example code provided in the following doc and they need to be adjusted to the business case of the client. As such getManagementApiToken is a place holder to get a token for Management API.

  • I know you have Actions Marketplace but do Auth0 have any plans for also having a kind of open-source version of that marketplace so that the community around Actions can be more involved?

We are actively working on an open source marketplace repo to allow developers and partners to contribute to the integration ecosystem around Actions, and this should be something to expect in 2024.

  • From the technical perspective, what will exactly happen to Auth0 users that have Rules and Hooks in their pipeline once Rules and Hooks reach end of life?

After Nov 2024, Rules and Hooks will not be available to all tenants. We will end of life these features and the login pipeline that involves Rules and Hooks will stop functioning. All users must migrate their legacy Auth0 pipeline to Actions before the date.

  • Any news or announcements around what changes, improvements we can expect from Actions in the near future?

You can now unlock deeper identity customization with Auth0 by Okta. Starting today, you can use advanced features in Auth0 Actions, which include SAML Mapping, Root-Level User Attributes, and Access Token Scope. These new capabilities enable you to seamlessly upgrade from Rules to Actions - our flagship extensibility product. You can learn more from our blogpost

  • I haven’t checked now, but the reason we couldn’t migrate from rules to actions was because we had a few special cases where we have to set the scopes manually (reduce the number of consented scopes). Is it possible to set scopes manually or override them now?

Access token scope modification is available in Actions now. Developers can freely add or remove claim scopes with custom APIs, enhancing the ability to meet overall security needs. Learn more about Access Token in our docs.

  • As Auth0 is getting closer to the full deprecation of Rules and Hooks, we can see new docs being rolled out and YouTube videos helping us migrate to Actions. Do you plan to also release more FAQs on that topic?

We have a resourceful Developer Relations Youtube Channel with information and tutorials on Actions and how to migrate to Actions, while we are adding more tutorials, you can also check out Templates for Actions to start off your migration. You can find specific videos such as how to Migrate Hooks and Rules.

  • In the post login action, is it possible to make authenticated calls to a secured backend service? We are currently facing a use case in which we want a user to answer security questions that are generated by our backend before they log in and gain access to the main application. We are able to pass information to the middle UI with a session token using the function provided by auth0: api.redirect.encodeToken({}). the issue with this, is that the token is signed in hs256 which is not accepted by our backend. Is there a way to accomplish this use case ? Maybe there is a way to access the user token in the redirected middle UI and then assign the roles onContinuePostLoginAction? Synopsis of use case: require authenticated users to answer custom generated security questions before authorizing them to use our app, ideally leveraging redirect in Actions

Actions provides utility methods to encode and decode a JWS token, but you can encode your token and pass it to the external service following the code snippet below:

api.redirect.sendUserTo("https://my-app.exampleco.com", {
    query: { session_token: token }
  });
  • Hello - Will this break existing Auth0 extensions that use Rules .- e.g. Account Linking?

Any product or feature that is running on Rules and Hooks will not be impacted and will follow its product development cycle.

  • What will be the way to link user accounts? e.g. when user registered via email/password and later on signs-up/logs in via oidc or oauth2 with same email (& vice versa).

Auth0 supports the linking of user accounts from various identity providers. This allows a user to authenticate from any of their accounts and still be recognized by your app and associated with the same user profile. We recommend you to use Account Linking in Actions but you can also use Account Linking Extension. You can find more implementation details in Auth0 Docs.

  • It would be nice to have the possibility to set to false the user.verify_email attribute in a pre-registration Action in order to prevent the automatic send of the verification email. Today the attributes verify_email and email_verified are not available in the pre-registration event object. Use case is about sending verification email only after specific business conditions (checked in post-login actions). You can also check this community topic. The suggested workaround is to disable the email templates, precluding us the possibility to use the API /api/v2/jobs/verification-email.

Thank you the feedback and use case, we don’t support this feature right now but will look for future opportunities!

  • The pre-registration Action is very limited compared to the post-login Action. For example it does not support redirect to an external page to collect additional user data and perform business oriented checks. Use case: we want to limit the registration to a specific set of users (like they have to be doctors). In this case, we can ask their professional ID and check its validity before we let them to create a new account. The suggested workaround is to implement additional data collection and custom checks using post-login Actions and external pages. If the checks fail, the user login is blocked. This solution creates unwanted accounts and it has side effects like user is blocked because they are not a doctor but they receive the welcome and the verification emails.

We are continuously adding more use cases to the pre-registration trigger but please do understand we have significantly more use cases and traffic in the post-login trigger. You can refer to this Auth0 Management API v2 doc on how to delete the unwanted accounts using the Management API.

  • In testing I have found that the post user registration Action does not run on passwordless signups. Will this be supported?

We don’t have support for Post User Registration Actions with Passwordless Signup yet. It is not supported in Early Access but the team is working on adding support for that.

  • I was able to successfully link the accounts however after linking I was unable to switch the user account. According to some community post I saw, linking in Actions will be supported in Q3.

HAccount Linking is done through management API and switching the user account is available through api.authentication.setPrimaryUser() . This feature is only available in the latest version of the APi for Post-login, so please make sure that you are using v3 . You can find out more information in this doc

  • There still seems to be a bit of a parity gap between Actions when compared to Rules/Hooks. Can you tell us more about this? What is the current state of this and can we expect complete parity eventually?

We are working closely with the developer community to close off all feature parity gaps between Rules and Actions, while making our product secure with best practices. We have closed off major parity gaps but evaluating some minor ones that might lead to risk against best practice. All valid parity gaps will be addressed before the end of the life of Rules, please check our latest parity release

  • Hi there! I want to use an Action to reject any request to change the role attribute in our app_metadata from our API. Basically I want roles to be set exclusively from the Auth0 dashboard. Is that possible? What would be the trigger?

Thank you for the feedback and use case, we don’t support this feature right now but will look for future opportunities!

  • You are moving away from Rules and Hooks, towards Actions. In terms of that, does Auth0 have any plans related to Actions and Auth0 pricing plan that we can expect this year?

Hello James, We are working on our pricing and packing for extensibility and will provide updates with a plan to align developer experience with development productivity.

  • Is there like a single source / doc where we can find all the information about migrating to Actions? No matter if that’s about Rules or Hooks.

Wee have prepared technical detailed documents on how to migrate to Actions, you can follow the steps below and keep your Actions in the same order as your original Rules, the functionality should be identical.

https://auth0.com/docs/customize/actions/migrate/migrate-from-rules-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.

  • I really like the format of Auth0 Blog. Do you plan to release more Actions related content through Auth0 blog articles?

Hello Leila, thanks for your feedback. We are continuously providing new feature highlights and coverages throughout Auth0 Blog. Please see some of the highlights below.

  • Do Actions support modifying the scope? In RuleS, we were having ‘Rule config’ section to store global config. How are we going to manage this with Auth0 Actions? Does Action execute during the ‘Client Credentials Flow’? As Rules were not executing during ‘Client Credentials Flow’.

Actions now support Access token scope modification and you can find out more information here

We don’t have a global configuration in Actions as of now. Actions offer Machine to Machine as equivalent to Client Credentials Flow.

  • I still have the question about the delegated administrations extension.I need to convert the Delegated Administration Extension’s hooks to actions but I don’t see anything in the documentation about how to map the various hooks to appropriate actions or what methods in an action to use for them. There are: Filter Hook, Access Hook, Membership Query Hook, Settings Query Hook and Write hook. I can’t find any information on which type of action to rewrite them into, is it a Login/Post login or M2M or a specific method on one of these actions? How would they fit into the flow are there any specifics to be aware of? Are there examples anywhere I can refer to?

The Delegated Administration Extension (DAE) allows you to grant administrative permissions to a selected group of people without providing access to any other area. Delegated administration extension can be leveraged through Actions, and you can find out more information throughout our Docs.

You can use the Authorization Core feature set to create and manage roles for the DAE using Actions.

  • Actions console logging is very limited. Max log line is 127 char. In a Post-Login Action, if you console log in the onContinuePostLogin function, all logs in the onExecutePostlogin function is now shown the in the monitoring → logs events. Logging is very useful for debugging. I understand performances issues at production but during development it is essential.

Thank you for the feedback and use case, we don’t support this capability right now but will look for future opportunities.

  • How far are we in implementing pre-login hooks? This is useful if I want to be able to inject last_login into app_metadata.previous_login before actually accessing them later. This is because, the last_login quickly get written over once the user logged in and we have no opportunity to utilize that info for something else. Second one, how far are we in the journey of writing the Actions in Typescript? It would greatly increase developer productivity if we decided to move into that direction. If you have decided otherwise, do you mind to walk us through why you decided to ditch Typescript?

We are looking into adding new pre-login triggers in Actions to meet your use case to access app_metadata.previous_login data, however, we don’t have a plan for Typescript at this moment.
Hooks as a legacy extensibility will no longer receive active development and will be deprecated in Nov, 2024.