Skip to main content

Migrate CS Cockpit functionality into Dixa

Overview

As described in the Spike - Integrating Auth0 User Management with Dixa we are able to add use custom cards to display information from external sources such as Auth0. This proposal describes how we can perform auth actions on behalf of a user such as triggering the reset password flow, changing the customers emails or even blocking an account from logging in.

Proposal

Unfortunately we cannot design this to be asynchronous without syncing auth0 user attributes to Dixa (which is outside the scope of delivering Auth). This is because many methods requires the auth0 user_id to operate. In our example we would use the Update a User PATCH method to block or change email. This means our proposal is tightly coupled to the Auth0 Domain in AWS.

  1. Dixa makes a GET request to the Search Users endpoint.
    1. We does this via the API Gateway with a Authorization Header and any other headers required by AWS.
  2. The API Gateway passes the request onto the getUser Lambda.
  3. The getUser Lambda makes a request to Auth0 and waits for a response. We should do some basic checks to make sure the user matches that in Dixa. We can also filter the response at this point. The response is passed back to Dixa and the Custom Card is rendered with user details. These can be email, email_verified, login_count, last_ip, last_login, connection and most importantly the user_id. This user_id as well as connection can be used in subsequent calls.
  4. We can then build custom ui to perform the following actions.
    1. Change email
    2. Trigger reset password
    3. Block or unblock the user account
  5. The patchUser Lambda makes a request to Auth0 and waits for a response. We can then update the UI accordingly.
    1. Change email - This will trigger other processes which are outside the scope of the Lambda such as triggering emails. You can read more about that in Custom Log Streams, EventBridge and Emails.
    2. Trigger reset password - Given a user's email address and a connection, Auth0 will send a change password email. This may need to be triggered using the custom log streams.
    3. In this proposal we use the Update a User PATCH method to change the blocked boolean. It should be noted we can also use the Unblock by identifier method.

Search Users

GET - /api/v2/users?include_fields=true&q=email%3Djohn.kilpatrick%40rapha.cc - Remember you must encode the query string parameters as they will contain invalid URL characters (eg. @ or + in the email).

Note If we were to sync auth0 attributes we would be able to use the GET - /api/v2/users/{id} method.

Search User Example Response

[
{
"created_at": "2023-03-17T17:29:59.041Z",
"email": "john.kilpatrick@rapha.cc",
"email_verified": false,
"identities": [
{
"connection": "Username-Password-Authentication",
"provider": "auth0",
"user_id": "6414a39713a5c42d363c6b3c",
"isSocial": false
}
],
"name": "john.kilpatrick@rapha.cc",
"nickname": "john.kilpatrick",
"picture": "https://s.gravatar.com/avatar/46d15faf6a778cc1e16c97d3c509c67c?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fjo.png",
"updated_at": "2023-03-21T10:30:26.537Z",
"user_id": "auth0|6414a39713a5c42d363c6b3c",
"last_login": "2023-03-17T17:29:59.038Z",
"last_ip": "212.132.236.38",
"logins_count": 1
}
]

Update a User

PATCH - /api/v2/users/auth0|6414a39713a5c42d363c6b3c - The user_id from the previous step.

Update a User Considerations

  • 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.
  • Updating the blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.

Update a User Example Response

{
"created_at": "2023-03-17T17:29:59.041Z",
"email": "john.kilpatrick@rapha.cc",
"email_verified": true,
"identities": [
{
"connection": "Username-Password-Authentication",
"provider": "auth0",
"user_id": "6414a39713a5c42d363c6b3c",
"isSocial": false
}
],
"name": "john.kilpatrick@rapha.cc",
"nickname": "john.kilpatrick",
"picture": "https://s.gravatar.com/avatar/46d15faf6a778cc1e16c97d3c509c67c?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fjo.png",
"updated_at": "2023-03-21T10:38:42.362Z",
"user_id": "auth0|6414a39713a5c42d363c6b3c",
"last_ip": "212.132.236.38",
"last_login": "2023-03-17T17:29:59.038Z",
"logins_count": 1
}

Considerations

  • How do we controll access to our API Gateway?
  • Do we add extra UI to unblock a user from an excessive amount of incorrectly provided credentials. This is different to just blocking and unblocking on user request. This might be the only use case which means our proposal changes to use the Unblock by identifier method.

Resources