Theoretically you would have three options, first one a direct migration, second and third option a gradual migration. All three allows Password Managers to recognise your site if you set a Custom Domain under Branding that is a sub domain of your current domain, for example login.example.com
as the Auth0 domain for your main site at example.com
.
Your three options are:
- Move the salt and the password hashes to Auth0 Have Auth0 to use the same salt and hashing algorithm as Drupal on the passwords of incoming login requests, and compare that result to the stored hash.
- Switch to Auth0. If a user is not present in Auth0, check with Drupal. Each time a user is logging in on Auth0, if the user does not exist in Auth0, use an endpoint to check if the user exists in Drupal. If it does, store the provided name and password as a new user in Auth0. Once enough users are migrated, turn off the extra check towards Drupal. Copy across the rest of the users with a random password, enforcing them to reset their password upon next login.
- Each time a user is logging in on Drupal, send their login credentials to Auth0 and create a new user there. Once enough users are migrated, switch over to Auth0 login. Copy across the rest of the users with a random password, enforcing them to reset their password upon next login.
Option 1
At point of writing, this option is not possible. The main problem seams to be that Drupal crops the password hashes to fit in a legacy DB table designed for smaller hashes, discussed here on SO and in Auth0 user forum. Unfortunately neither API based not "Import/Export Extension"-based migration will work. This has also been verified by Auth0 support, writing that:
Auth0 Developer Support, 2023-04-20
As far as I can see, you cannot bulk-import users from Drupal into Auth0. This appears to be due to the very particular way that Drupal generates hashes.
Support for custom password hashes is definitely on the roadmap. but the target date has been delayed due to competing priorities.
It looks like at the moment, the only option that I can see is to treat Drupal as a custom database source and enable Automatic Migration. Let me know if you would like to explore this option further.
Regards, EMEA Developer Support, ref:_00D37JYbE._500Ho1BhzB9:ref
Option 2
For this technique, you need to expose an endpoint in Drupal that can verify a users login credentials. Then you need to enable a "Custom Database" in Auth0 (that would be the Drupal API, an API is a type of "custom database" in Auth0) and tick the box "Import Users to Drupal". The details of each implementation is omitted, but this article describes the scripts needed pretty well, and this Auth0 documentation describes the format if you for example want to treat your Drupal e-mail addresses as verified or not. However, a custom database calls to an enterprise subscription at Auth0. Pricing is only reviled after "Getting In Touch", but each steps add about one zero. One important part here is that once you think enough users are migrated and you turn off the check towards Drupal, you still cannot turn off the option "Use my own database" and switch to a lower tier subscription, you can only no-op the Drupal check. This means you may need to negotiate prices for the lifetime of the product. (Compare to GCP or AWS where list prices are public.) On the other hand, only here you get an SLA, Enterprise Support etc, so it may be your only option anyways.
Option 3
This option will always work, but it will require your users to login twice, and it will enforce you to wait with the Auth0 migration until enough users are migrated. First you need to implement the hook_user_login
in Drupal to grab the users login credentials. Then you need to create a Management API application in Auth0, that can create users. Once everything is setup, you need to logout all your users, enforcing them to login again. When enough users has logged in again, you need to switch over to Auth0, and all your users will need to login a second time. Two logins, but at least they kept their passwords!
Summary
Avoiding bumps on the road for your users is hard. Depending on your expected churn rates from different actions, the loyalty of your users, the budget and the size of your services, your choice will differ. Option #2, in combination with leaving your old "custom Database (the Drupal API) active until all users have loged in at least once, is the only option that would give our users a seamless experience.
Although not being an option that fullfils the request, the option to just transfer your users and set random passwords may end up as the least bad option here. This will of course require all your users to reset their passwords upon next login. With some CRM stressing that you do some work for the users' security, you may even get some goodwill from this.
Or maybe even some better options appears here after a while. Maybe new ways evolves, new features are released, or maybe I missed some options. Fingers crossed!