Storing non-auth user data outside of auth0, custom user_id in tokens and multiple id providers for the same user

Get Help
, ,
2

Hi @brodge

The documents you link to talk about two different types of “custom database” concepts:

  • One is the custom database for authentication purposes. This is when your user authentication data (user id and password hash) is stored on an external database (because that’s the system you’ve been using before, and thus “legacy”). For this scenario, we provide the “Custom DB” connection type.

  • The other reference to “custom database” is talking about your application data, i.e. data outside of the Auth0 context. For instance, if you were building a calendar app, calendar entries and user settings related to the calendar app should probably go in the “custom database” for the calendar app, not in Auth0.

Pre and post registration hooks only run for database connections, not for social connections (because the registration happened before, at the social identity provider).
But you can create a rule that checks for this alternative user id on each login, and assigns that id if it’s not present. E.g.:

function (user, context, callback) {
  
  function addCustomClaim() {
    // add internal id in the ID Token
    context.idToken["https://yourapp.com/claims/internal_id"] = user.app_metadata.internal_id;
  }

  user.app_metadata = user.app_metadata || {};
  if (!user.app_metadata.internal_id) {
    var newId = generateNewId(); // you'll need to implement this
    user.app_metadata.internal_id = newId;
    // persist the changes
    auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
      .then(function(){
        addCustomClaim();
        callback(null, user, context);
      })
      .catch(function(err){
        callback(err);
      });
  } else {
    addCustomClaim();
    callback(null, user, context);
  }

That’ll give you an internal id for each user (whether that’s useful or not is another discussion). But it will also give you different internal ids when the user logs in with a different identity provider (because the user profile in Auth0 is different).
If you want the same user ID for cases where the email address is the same (or when the user can prove that the identity is equivalent by any other method) you might want to check Account linking, where you link two or more Auth0 identities so that regardless of the authentication method used by the user, the application sees the same identity.

Hope that helps!

1 Like