Skip to main content

Auth0 Event Logs

Context​

We want to move CS cockpit functionality into Dixa, our Customer Support platform, using custom cards. As we move to Auth0 we needed a way to integrate actions related to customer accounts and account details with Auth0. Doing this via custom cards will enable agents to handle a number of customer related actions in a single screen, saving time and effort. Through the use of middleware we can tie API-initiated actions into our event-driven architecture.

After reviewing the requirements of the CS team and the proposal completed by the tech team we have defined what functionality we will require for the Dixa Auth0 integration. Using Dixa custom cards and middleware, we will interact with the Auth0 API to allow the CS team to update email addresses, trigger password reset emails, unblock users, add or remove user groups and view customer information.

Decision​

We have decided to move forward with architecture based on our proposal.

Design for Auth0 Dixa integration

  1. Dixa makes a GET request to the API Gateway with an Authorization Header and any other headers required by AWS.
    1. The Get Customer Step Function is executed
    2. The Get Customer Step Function is composed of 4 Lambdas that make requests to 4 different endpoints to fetch the data that we need to render the Dixa Card UI
    3. The Get User Lambda will fetch most of the customers information such as email, connection and user_id. The user_id and connection can be used in subsequent calls. We should do some basic checks to make sure the user matches that in Dixa.
    4. The Get User Blocks Lambda will fetch any blocks on the customer that were imposed as a reult of automatic attack detection i.e. brute force
    5. The Get User Roles Lambda will fetch the current list of roles assigned to the customer
    6. The Get All Roles Lambda will fetch all of the available roles that we have created in our Auth0 tenant. This will provide the list from which an agent can choose when they are assigning new roles to a customer.
    7. The response is passed back to Dixa and the Custom Card is rendered with user details. These will be email, last_login, blocked, blocked_for and user_id.
  2. We can then build custom UI to perform the following actions.
    1. Change email
    2. Trigger reset password
    3. Unblock a user account that has been automatically blocked (brute force detection or incorrect credentials)
    4. Add or remove user roles
  3. When a CS agent interacts with the Dixa UI to perform an action, the following occurs:
    • Change email - The updateUser Lambda is executed and calls the Auth0 API to update the user. On success, a "success change email" event will automatically be generated by Auth0 and sent to Auth0 event bus which will trigger other processes which are outside the scope of the Lambda such as triggering emails. You can read more about that in Auth0 event logs. We need connection and user_id to call the API to update email.
    • Trigger reset password - The requestChangePassword Lambda is executed. Given a user's user_id and connection, we can get a magic link for password reset from the API. We will send SendEmail event to the Platform event bus that contains this link and the necessary user data, which will send an Exponea email to the customer via our middleware.
    • Unblock user account - To unblock a user that has been blocked through automatic anomaly detection e.g. entering their password incorrectly too many times, the removeAutomaticBlock Lambda is executed. This makes a call to the User Blocks endpoint to remove the block. We need user_id to call the API to remove an automatic block.
    • Add or remove user roles - The updateUserRoles Lambda is executed. We will call either the assign or remove role for user API to add or remove user roles. The agent will only be able to choose from the list of roles that were fetched in the Get Customer Step Function and will not be able to create a new role to assign to a customer. We need user_id and the ID of the role to be assigned or removed.

Consequences and limitations​

  • All of the Lambdas will make requests to Auth0 endpoints, however it is only displayed for the Get Customer Step Function so that is clear that we have to wait for this information to be returned before we can proceed with building the UI. It is a synchronous process.
  • Since we want to send all emails via Exponea to avoid direct integrations, we cannot use the Authentication API to directly trigger an email to be sent by Auth0. Instead we need to call the Management API to get the magic link that we will build into our own email to be sent from Exponea.
  • When we update a user's email address, we must also set email_verified to true.
  • We need to authenticate every request to the Management API with an Auth0 Management API token.
  • When updating a user via PATCH request the properties of the new object will replace the old ones. We should use shallow cloning to avoid issues. The metadata fields are an exception to this rule (user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.

Resources​