Skip to main content

Auth0 Event Logs

Context

Auth0 offers the ability to set up a custom log stream using webhooks, allowing events to be delivered to an external webserver. This covers API calls, changes to user information, actions taken via the Auth0 dashboard and more - practically every event that happens in Auth0 is sent to the webhook integration. We can use these event logs for multiple purposes; we can define which events we send to Grafana for monitoring, we can retain all logs in an S3 bucket, we can send events on to other systems for teams such as BI, and we can use the events to trigger emails being sent via Exponea.

Since there is such a large number of events, we came together to define which events are useful to us as a business and how we want to handle those events. See resources for a detailed breakdown of every event we want to filter for.

Decision

Our two main purposes for event logs are monitoring and retention, and sending emails. Below is a diagram of how we will implement this event handling.

Design for Auth0 webhooks integration

The events in the middle section have been grouped by type simplify the diagram, for the full list of the events covered by each grouping see the documentation in the resources section.

Monitoring and retention

  • We want to retain all logs in an S3 bucket, without performing any transformation or normalisation of events. They will be kept for 90 days.
  • We want to send event logs to Grafana for monitoring purposes such as debugging authentication or management API errors.

Sending emails

  • We will use the two brute force events to send emails to users when their account has been blocked.
  • We will use the Success Password Change event to send emails to confirm with users that they have just changed their password.
  • Events will be sent to the Auth event bus, and the events above will trigger a lambda - the Email Transform Lambda - that will transform its shape to the correct schema to send a SendEmail event to the Email event bus. There is an existing Send Email lambda that will be triggered that we will use to send emails to Exponea.
  • We will use the Failed Change Password Request event to trigger the Hybris Reset Password Lambda. If a user hasn't migrated and doesn't exist in Auth0 yet, when they request a forgot password email from Auth0 it will fail, sending the Failed Change Password Request to EventBridge. We will use this event to target a lambda that checks if that user exists in Hybris, and if they do we will make a request to the Hybris API for Hybris to send them a reset password email instead.

Consequences and limitations

  1. We will refine the number of events that we are sending to Grafana once we have confirmation from QA which events will be the most valuable to them, and once we have monitored the number of events we are seeing in Grafana if there is too much noise. For now, we will send all events.
  2. We will not use the success sign up event for sending welcome emails - there is event driven logic in Exponea that handles this. The events are sent to the Exponea lambda directly from Hybris at the moment, and for the initial implementation we will not be making changes to how those events are sent. In future, it would be possible to send those events via the Auth event bus.

Resources