Back to Resources

8 mins

The Difficulty of Switching Authentication Providers

By

Prashant Murali

The beauty of passwordless authentication is that the most difficult part of migrating user tables is eliminated; the migration of passwords. This makes switching authentication providers extremely easy if the new API provider is a passwordless authentication provider.

For the purposes of this post, we will take Email Magic Links as the form of passwordless authentication that we speak about.

Email Magic Links are defined as a “single-use URL sent to the user’s email that authenticates the user instantly when clicked”.

Password-based Migration

Traditionally, there would be two ways in which to migrate user tables.

  1. On-Demand Migration

This is where users are migrated dynamically to the new auth provider as the users login.

  1. Bulk Migration

This is where an IT admin would extract users from the old auth provider and load users to the new auth provider in a one-off migration.

Pros and Cons

There are some considerations on which option to choose between On-Demand Migration and Bulk Migration.

Bulk Migration vs On-Demand Migration

Passwordless Migration

When migrating to a passwordless authentication provider, regardless of whether or not the old authentication provider is password-based or not, the migration is far easier because there would be no passwords to migrate.

This is based the assumption that the old authentication provider uses email as the username and that the email was verified by the user.

Users can simply be migrated On-Demand as the new users would be authenticated with a Magic Link that gives them a verified email.

If attributes other than username and password are already accounted for and stored in a separate backend or CRM,

  • Bulk Migration would not be required at all in this case.
  • On-Demand Migration can be switched on and the old provider can be switched off straightaway. This is because:
    -> Every existing user will have to click on the magic link that verifies their email anyway.
    -> The verified email can then be used to perform authenticated requests tied to the the existing user with the same email address.

In the case where attributes other than username and password are required, then,

  • Bulk Migration can be used, but without the hassle of password migration. No password reset flows would be needed for the user due to passwordless login.
  • On-Demand Migration can simply create the user attributes in the new provider when the user attempts to login. The user will simply experience a Magic Link based authentication. In this case the old provider cannot be switched off straightaway as it is still required to hold the added user attributes.

How Bulk Migration would work

Password-Based Bulk Migration

Bulk migration of usernames and passwords is tricky because the passwords in the old provider would already be hashed. This means the same hashed password can be migrated to the new provider only if the new provider supported the same hashing algorithm.

If this is not the case, then a password reset flow would need to be triggered for the user the next time they login.

The diagram below explains the process.


Bulk Migration / Password-Based

Below is the user flow, if the user required a password reset flow.

Password Reset Flow

Passwordless Bulk Migration

If attributes other than username and password are already stored in a separate backend or CRM:

  • Bulk Migration would not be required at all in this case.
  • Only email would need to be migrated, but there is no advantage to do this in bulk instead of On-Demand, unless the old auth provider is the only source of the list of user emails (this is highly unlikely).

Bulk Migration / Passwordless / No extra user attributes

In the case where attributes other than username and password are required, then,

  • Bulk Migration can be used, but without the hassle of password migration. No password reset flows would be needed for the user due to passwordless login.

Bulk Migration / Passwordless / Extra user attributes

Since there is no password reset flow with passwordless migration, the user flow will simply be that of an Email Magic Link flow.

Email Magic Link Flow

How On-Demand Migration would work

Password-Based On-Demand Migration

On-Demand Migration with usernames and passwords requires the old auth provider to still be active so that user can prove association with their account with old auth provider with the new auth provider.

Password-Based / On-Demand

Passwordless On-Demand Migration

On-Demand Migration to a passwordless auth provider can be done without authenticating with the old provider, as we are getting a verified email with the new auth provider regardless.

If additional user attributes are required, then user attributes can be migrated on demand.

Passwordless / On-Demand / Extra user attributes

If there are no extra user attributes to be migrated (this is more likely, as a backend or CRM tend to have these extra user attributes), then there is no need to keep the old auth provider at all.

Passwordless / On-Demand / No extra user attributes

How can I migrate to a passwordless authentication provider?

EZiD is a passwordless authentication provider that uses Magic Links to log in your users. You can speak to us here.

Integrate now