As a bit of context, we are migrating from our existing OWIN-based authentication using an MSSQL database to Auth0. Having looked at material on migrating from a custom database (here and here), I understand that the default is for the Auth0 record to be set up on-the-fly when each user first signs in via Auth0 since the deployment.
Our intention is to set up ‘stub’ user records in Auth0 via the Management API and still use the custom DB connection for that first password verification if possible, since:
- We have an existing user ID that is referenced by other records in other parts of our system, hence we want to maintain referential integrity with the user_id (which we can set when creating the user via the Management API)
- We want to efficiently populate referential data from our Azure CosmosDB into the app_metadata field on a many-to-many basis, so that custom rules can append the relevant claims to the User identity returned to the web application.
- If the source data in CosmosDB changes, our system now updates corresponding user records in Auth0 instead of the SQL database; we cannot rely on old claims in the UserClaim SQL table since that is no longer being used by the application. Therefore we need the relevant User records in Auth0 from the start.
We still expect the users to have a seamless experience signing in with their existing password. Is it possible for us to maintain this sign-in experience via the custom DB, if our user records are bulk-migrated to Auth0? If so, how do we ensure that the custom DB is still consulted for that first post-deployment sign-in per user (i.e. how do we mark the corresponding Auth0 record as ‘dormant’)?
If these needs are mutually exclusive and we cannot create user records in Auth0 as part of our deployment, how do we ensure that the Auth0 record contains the data (user_id, app_metadata and user_metadata) that we need? Can we explicitly set the user_id to maintain referential integrity as we could when creating the user via the Management API?
Many thanks.