Lazy Migration

Basics

When migrating users from your existing authentication platform and onto Authproject, the second primary way is to perform a “lazy migration.”

What is a lazy migration?

Lazy migrations are a slow process of migrating users only as they sign in. This works well for those that are able to make changes to their existing authentication codebase, and for those that don’t mind hosting their infrastructure after Authproject is set up.

Advantages

When speed is not a concern, lazy migrations are beneficial for those that want a seamless experience. It allows users to sign in with their existing passwords, whereupon their password is checked and stored securely in our systems.

Disadvantages

The main disadvantage of lazy migrations are that it requires changes to be made to the existing authentication platform.

Code Changes

In order to authenticate a user, you must have an API endpoint available where we can submit the user email and password, and your authentication platform verifies it for us. If the password the user submits (and we proxy to you) is correct, you provide us with the rest of the user data to store in our system. If it is incorrect, the user will need to try entering their password again.

How does it work?

When a lazy migration is performed, we will make a request to an endpoint you develop to verify their password.

Verification Endpoint

The verification endpoint must accept URLEncoded form parameters, with the email being stored in email, and the password being stored in password.

email=email%40example.com,password=my-secure-password

Once this request arrives at the endpoint you have previously specified, we expect one of two responses in JSON format.

Success

{
  "success": true,
  "user_info": {
    "user_info_key_a": "user_info_value_a",
    "user_info_key_b": "user_info_value_b"
  }
}

Failure

{
  "success": false
}

User Info

Once the password is verified, you can return a dictionary of user information to us. This will be transparently stored next to the user in our systems, and can be queried at the /oauth2/userinfo endpoint of our API. It is further documented on our user info page.