Database To SSO Migration

We have Auth0 installed in production using database connections. We will be giving existing clients the option to use enterprise SSO. I need guidance on the best way to migrate the existing database users to the enterprise SSO connection.

Based on my tests, after configuring enterprise SSO for the client domain, the next time a user in that domain logs on, Auth0 creates a new user in the SSO connection. From that point on, Auth0 will authenticate using the new SSO connection since it associates the user’s email domain with enterprise SSO. This makes the user entry in the database connection effectively obsolete as it will no longer be reachable as long as SSO is enabled for that domain.

I understand that I can link the two users, but I see no point in doing that since the entry in the database connection is effectively obsolete.

What are some approaches to removing the database connection user? Maybe in a post login action? Is it worth doing that, or is there any harm in just keeping it?

Hi @john.boldt

Be careful with security here: if it is possible that a bad actor created an email/password account with an emai address from a SSO domain, then you switch to using SSO, automatically link accounts, the bad actor MAY be able to gain access to the SSO account (by calling /authorize with a connection ID for the DB connection, forcing it to skip the SSO).

WIth that caveat, you could link the accounts (preferably forcing them to authenticate to both before linking, see the security caveat above). There is nothing wrong with keeping the DB account around.

Or you could have a rule that copies the metadata from the DB account to the SSO account, this avoids the security issue (as the accounts are not linked). If you go this route, make sure you only do the copy a single time, otherwise you may hit management API rate limits.


1 Like

Hi @john.gateley - thanks for the response!

Here’s the enterprise SSO flow currently under test:

  1. The user is registered within our application
  2. The user logs in for the first time using SSO
  3. A post login action calls makes a REST call into our application passing the login email to retrieve metadata (internal tenant ID, internal user ID, and application permissions). The call requires a bearer token containing a permission that only the identity provider (Auth0 in this case) knows. If the email is not registered within the application, the action issues an api.access.deny and returns. If the email is registered within the application, it applies the metadata and assigns the associated roles to the user.
  4. If the user resides in the existing database connection, delete it from the database connection.
  5. All subsequent logins do not require the metadata call and the post login action exits immediately.

In addition, when a user is removed from the application, or if their permissions are updated, then we remove the user from Auth0 and step 2 kicks in the next time they log in.

So my question is: is step 4 worth the effort? On the one hand, I think it’s a good idea to clean up obsolete database connection users. On the other hand, the delete call is relatively expensive, so does the benefit exceed the cost?

Hi @john.boldt

I don’t have a strong opinion on this. Leaving it is messy, but doesn’t impact performance.

If you use the existence of the email in the database connection as a test for whether to move the metadata, then it must be deleted of course.

There are many solutions I have seen that have this “messy database” issue, I wouldn’t spend too much time on it.


1 Like