I’m currently implementing Auth0 to provide auth to many microservices. Including a ‘UserService’ that holds non-auth related data about each user.
Some of the other microservices need a user identifier to apply authorization - I don’t want to use the Auth0 id for this because I don’t want to rule out authenticating via other methods in the future, also it’s my understanding that the same user could authenticate with Lock via Google / another identity provider and end up with a differed ‘sub’ claim in their token. Ideally I want users to be able to login through Auth0 via any identity provider and still access the same user account on our side (if they choose to).
It would be great if we could put our own user_id inside the JWT access_token issued by Auth0 so I don’t need to be always calling the UserService to look it up when the JWT is validated.
On the User Data Storages docs it seems to recommend using a ‘custom database’ solution, but on this page it seems to define that approach as a ‘legacy’ approach (and you need enterprise?)
I’ve read that this can be achieved via ‘post-registration’ hooks, so every-time a user registers via Lock, it creates that user in our UserService (via HTTP POST?), then attaches the user_id returned to the app_metadata for inclusion in future access_tokens…but what if they login via Google / Facebook where a ‘registration’ doesn’t really happen?
Would this also work with ‘pre-registration’ hooks? I’m concerned that if user registers as part of a flow, the asynchronous nature of the ‘post-reg’ hook might not have been completed by the time they are redirected to the service that requires the user_id to be present in the JWT.
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.