Skip to main content

User Creation without password hashes

caution

The recommended method for migrating users to SuperTokens is by importing users with their password hashes. You should only use the following method if you do not have access to your user's password hashes and still have access to your previous identity provider.

SuperTokens also supports the "just in time" user migration strategy for when password hashes cannot be exported from your legacy provider.

We will need to make the following customizations to SuperTokens authentication flows to support this strategy:

  • Step 1) Prevent signups from users who exist in the external provider.
    • To prevent duplicate accounts from being created, we block signups from users who have existing accounts with the external provider.
  • Step 2) Create a SuperTokens account for users trying to sign in if they have an account with the external provider.
    • We will modify the signin flow to check if the user signing in has an existing account with the external provider and not with SuperTokens. If their input credentials are valid, we create a SuperTokens user and import their user data.
  • Step 3) Create a SuperTokens account for users who have an account with the external provider but have forgotten their password.
    • Some users who have an account with the external provider and not with SuperTokens may have forgotten their passwords and will trigger the password reset flow. Since SuperTokens requires an existing account to send the reset password email to, we will need to modify the password reset flow to check that if the user needs to be migrated. If they do, we create a SuperTokens account with a temporary password, import their user data and continue the password reset flow.
    • To ensure that users can only signin once they succesfully reset their passwords we add the isUsingTemporaryPassword flag to the account's metadata. We will also modify the signin flow to block signins from accounts with this metadata.
  • Step 4) Remove the isUsingTemporaryPassword flag on successful password reset
    • Once the password has been successfully reset we check if the user has the isUsingTemporaryPassword flag set in the metadata. If they do we will clear the flag from the user's metadata.
  • Step 5) Update the login flow to account for the isUsingTemporaryPassword flag
    • We also update the login flow to prevent signins from accounts who have the isUsingTemporaryPassword flag and if their input password does not match the one in the legacy auth provider. This is done so that users who started the password reset flow are forced to finish it.

Step 1) Prevent signups from users who exist in the external provider#

To implement this change we will override the function that handles signup when initializing the EmailPassword recipe on the backend.

import EmailPassword from "supertokens-node/recipe/emailpassword"

EmailPassword.init({
override: {
functions: (originalImplementaion) => {
return {
...originalImplementaion,
signUp: async function(input){
// Check if the user signing in exists in the external provider
if(await doesUserExistInExternalProvider(input.email)){

// Return status "EMAIL_ALREADY_EXISTS_ERROR" since the user exists in the external provider
return {
status: "EMAIL_ALREADY_EXISTS_ERROR"
}
}
return originalImplementaion.signUp(input);
}
}
},
},
})

async function doesUserExistInExternalProvider(email: string): Promise<boolean> {
// TODO: Check if user with the input email exists in the external provider
return false;
}

We modify the signUp flow to first check if the user signing up has an account with the external provider. If they do we return a EMAIL_ALREADY_EXISTS_ERROR

Step 2) Create a SuperTokens account for users trying to sign in if they have an account with the external provider#

To implement this flow we will override the function that handles login when initializing the EmailPassword recipe on the backend.

import SuperTokens from "supertokens-node"
import EmailPassword from "supertokens-node/recipe/emailpassword"
import EmailVerification from "supertokens-node/recipe/emailverification"

EmailPassword.init({
override: {
functions: (originalImplementation) => {
return {
...originalImplementation,
signIn: async function (input) {
// Check if the user exists in SuperTokens
let supertokensUser = await EmailPassword.getUserByEmail(input.email, input.userContext);
if (supertokensUser === undefined) {
// EmailPassword user with the input email does not exist in SuperTokens
// Check if the input credentials are valid in the external provider
let legacyUserInfo = await validateAndGetUserInfoFromExternalProvider(input.email, input.password)
if (legacyUserInfo === undefined) {
// credentials are incorrect
return {
status: "WRONG_CREDENTIALS_ERROR"
}
}

// Call the signup function to create a new SuperTokens user.
let signUpResponse = await EmailPassword.signUp(input.email, input.password, input.userContext)
if (signUpResponse.status !== "OK") {
throw new Error("Should never come here")
}

// Map the external provider's userId to the SuperTokens userId
await SuperTokens.createUserIdMapping({ superTokensUserId: signUpResponse.user.id, externalUserId: legacyUserInfo.user_id })
// Set the userId in the response to use the provider's userId
signUpResponse.user.id = legacyUserInfo.user_id

// We will also need to set the email verification status of the user
if (legacyUserInfo.isEmailVerified) {
// Generate an email verification token for the user
let generateEmailVerificationTokenResponse = await EmailVerification.createEmailVerificationToken(input.tenantId, signUpResponse.user.id, input.email, input.userContext);

if (generateEmailVerificationTokenResponse.status === "OK") {
// Verify the user's email
await EmailVerification.verifyEmailUsingToken("public", generateEmailVerificationTokenResponse.token, input.userContext);
}
}

return signUpResponse;
}

return originalImplementation.signIn(input)
}
}
}
}
})


async function validateAndGetUserInfoFromExternalProvider(email: string, password: string): Promise<{
user_id: string,
isEmailVerified: boolean
} | undefined> {
// TODO: Validate the input credentials against the external authentication provider. If the credentials are valid return the user info.
return undefined
}

The code above overrides the signIn function with the following changes to achieve "just in time" migration:

  • We determine if the user needs to be migrated by checking if an account with the input credentials exists in the external provider but does not exist in SuperTokens.
  • If the credentials are invalid in the external provider, we return a WRONG_CREDENTIALS_ERROR. If the credentials are valid we can call the SuperTokens signUp function with the input credentials to create a new SuperTokens user.
  • We now map the external userId(the userId from the external provider) to the SuperTokens userId. This will allow SuperTokens functions to refrence the user with the external userId.
  • Finally, depending on the email verification status of the user in the external provider we will also verify the user's email in SuperTokens.

Step 3) Create a SuperTokens account for users who have an account with the external provider but have forgotten their password.#

Some users who do not have an account with SuperTokens but have an existing account with the external provider may have forgotten their passwords and will initiate a password reset. Since password resets require an existing SuperTokens account to send the password reset email to, the password reset flow will need to be modified to create a SuperTokens account if the user exists in the external provider.

import SuperTokens from "supertokens-node"
import EmailPassword from "supertokens-node/recipe/emailpassword"
import EmailVerification from "supertokens-node/recipe/emailverification"
import UserMetadata from "supertokens-node/recipe/usermetadata"

EmailPassword.init({
override: {
functions: (originalImplementaion) => {
return {
...originalImplementaion
// TODO: implentation details in previous step
}
},
apis: (originalImplementation) => {
return {
...originalImplementation,
generatePasswordResetTokenPOST: async (input) => {
// retrieve the email from the input
let email = input.formFields.find(i => i.id === "email")!.value;

// Check if the user exists in SuperTokens
let supertokensUser = await EmailPassword.getUserByEmail(email, input.userContext);
if (supertokensUser === undefined) {
// check if the user exists in the external provider
let legacyUserInfo = await retrieveUserDataFromExternalProvider(email)
if (legacyUserInfo) {
// create a SuperTokens account for the user with a temporary password
let tempPassword = await generatePassword();
let signUpResponse = await EmailPassword.signUp(email, tempPassword, input.userContext);

if (signUpResponse.status === "OK") {

// Map the external provider's userId to the SuperTokens userId
await SuperTokens.createUserIdMapping({
superTokensUserId: signUpResponse.user.id,
externalUserId: legacyUserInfo.user_id
})

// We will also need to set the email verification status of the user
if (legacyUserInfo.isEmailVerified) {
// generate an email verification token for the user
let generateEmailVerificationTokenResponse = await EmailVerification.createEmailVerificationToken(input.tenantId, legacyUserInfo.user_id, email, input.userContext);

if (generateEmailVerificationTokenResponse.status === "OK") {
// verify the user's email
await EmailVerification.verifyEmailUsingToken("public", generateEmailVerificationTokenResponse.token, input.userContext);
}
}

// We also need to identify that the user is using a temporary password. We do through the userMetadata recipe
UserMetadata.updateUserMetadata(legacyUserInfo.user_id,{isUsingTemporaryPassword: true})

} else {
throw new Error("Should never come here")
}
}
}
return originalImplementation.generatePasswordResetTokenPOST!(input);
}
}
}
}
})

async function generatePassword(): Promise<string> {
// TODO: generate a random password
return ""
}

async function retrieveUserDataFromExternalProvider(email: string): Promise<{
user_id: string,
isEmailVerified: boolean
} | undefined> {
// TODO: retrieve user data if a user with the input email exists in the external provider.
return undefined;
}

The code above overrides the generatePasswordResetTokenPOST API. This is the first step in the password reset flow and is responsible for generating the password reset token to be sent with the reset password email.

  • Similar to the previous step, we need to determine whether to migrate the user or not.
  • The next step is to create a SuperTokens account with a temporary password, the password can be a random string since it will be reset by the user when they complete the reset password flow.
  • We now map the external userId(the userId from the external provider) to the SuperTokens userId. This will allow SuperTokens functions to refrence the user with the external userId.
  • Depending on the email verification status of the user in the external provider we will also verify the user's email in SuperTokens.
  • We assign the isUsingTemporaryPassword flag to user's metadata since the account was generated with a temporary password. This is done to prevent signins until the password is successfully reset.

Step 4) Remove the isUsingTemporaryPassword flag on successful password reset#

If the password reset flow is successfully completed we will need to check if the user has isUsingTemporaryPassword set in their metadata and remove it if it exists.

import EmailPassword from "supertokens-node/recipe/emailpassword"
import UserMetadata from "supertokens-node/recipe/usermetadata"

EmailPassword.init({
override: {
functions: (originalImplementaion) => {
return {
...originalImplementaion
// TODO: implentation details in previous step
}
},
apis: (originalImplementation) => {
return {
...originalImplementation,
// TODO: implementation details in previous step
passwordResetPOST: async function (input) {
let response = await originalImplementation.passwordResetPOST!(input);
if (response.status === "OK") {
let usermetadata = await UserMetadata.getUserMetadata(response.userId!, input.userContext)
if (usermetadata.status === "OK" && usermetadata.metadata.isUsingTemporaryPassword) {
// Since the password reset we can remove the isUsingTemporaryPassword flag
await UserMetadata.updateUserMetadata(response.userId!, { isUsingTemporaryPassword: null })
}
}
return response
}
}
}
}
})

The code above overrides the passwordResetPOST API and is a continuation of the password reset flow:

  • On a successful password reset we check if the user has the isUsingTemporaryPassword flag set in their metadata and remove it If it exists.

Step 5) Update the login flow to account for the isUsingTemporaryPassword flag#

Apart from the changes we made in Step 1, we also need to account for users who have a initiated password reset but have not completed the flow. There are two cases we need to handle:

  • Prevent signin from accounts that have temporary passwords.
    • If, for any reason, the user tries to sign into their account with the temporary password, then the login method should be blocked.
  • If a user initiates a password reset but remembers their password, they should be able to sign in.
    • In this case the user should be able to login and the database should be updated to reflect the new password.
import SuperTokens from "supertokens-node"
import EmailPassword from "supertokens-node/recipe/emailpassword"
import EmailVerification from "supertokens-node/recipe/emailverification"
import UserMetadata from "supertokens-node/recipe/usermetadata"


EmailPassword.init({
override: {
functions: (originalImplementation) => {
return {
...originalImplementation,
signIn: async function (input) {
// Check if the user exists in SuperTokens
let supertokensUser = await EmailPassword.getUserByEmail(input.email, input.userContext);
if (supertokensUser === undefined) {
// EmailPassword user with the input email does not exist in SuperTokens
// Check if the input credentials are valid in the external provider
let legacyUserInfo = await validateAndGetUserInfoFromExternalProvider(input.email, input.password)
if (legacyUserInfo === undefined) {
// credentials are incorrect
return {
status: "WRONG_CREDENTIALS_ERROR"
}
}
// Call the signup function to create a new SuperTokens user.
let signUpResponse = await EmailPassword.signUp(input.email, input.password, input.userContext)
if (signUpResponse.status !== "OK") {
throw new Error("Should never come here")
}

// Map the external provider's userId to the SuperTokens userId
await SuperTokens.createUserIdMapping({ superTokensUserId: signUpResponse.user.id, externalUserId: legacyUserInfo.user_id })
// Set the userId in the response to use the provider's userId
signUpResponse.user.id = legacyUserInfo.user_id

// We will also need to set the email verification status of the user
if (legacyUserInfo.isEmailVerified) {
// Generate an email verification token for the user
let generateEmailVerificationTokenResponse = await EmailVerification.createEmailVerificationToken(input.tenantId, signUpResponse.user.id, input.email, input.userContext);

if (generateEmailVerificationTokenResponse.status === "OK") {
// Verify the user's email
await EmailVerification.verifyEmailUsingToken("public", generateEmailVerificationTokenResponse.token, input.userContext);
}
}

return signUpResponse;
}
// Check if the user signing in has a temporary password
let userMetadata = await UserMetadata.getUserMetadata(supertokensUser.id, input.userContext)
if (userMetadata.status === "OK" && userMetadata.metadata.isUsingTemporaryPassword) {
// Check if the input credentials are valid in the external provider
let legacyUserInfo = await validateAndGetUserInfoFromExternalProvider(input.email, input.password);
if (legacyUserInfo) {
// Update the user's password with the correct password
EmailPassword.updateEmailOrPassword({
userId: supertokensUser.id,
password: input.password,
applyPasswordPolicy: false
})

// Update the user's metadata to remove the isUsingTemporaryPassword flag
UserMetadata.updateUserMetadata(supertokensUser.id, { isUsingTemporaryPassword: null })

return {
status: "OK",
user: supertokensUser
}
}
return {
status: "WRONG_CREDENTIALS_ERROR"
}
}

return originalImplementation.signIn(input)
}
}
}
}
})


async function validateAndGetUserInfoFromExternalProvider(email: string, password: string): Promise<{
user_id: string,
isEmailVerified: boolean
} | undefined> {
// TODO: Validate the input credentials against the external authentication provider. If the credentials are valid return the user info.
return undefined
}

The code above adds the following changes to the signIn function:

  • Adds an additional check where if a user exists in SuperTokens, we check if they have the isUsingTemporaryPassword flag set in their metadata.
  • If the flag exists, we check if the input credentials are valid in the external provider. If they are we update the account with the new password and continue the login flow.
  • If the input credentials are invalid in the external provider, we return a WRONG_CREDENTIALS_ERROR.

User migration edge cases that are addressed#

This stratergy takes into account the following edge cases to ensure a smooth migration experience:

  • Users who have not been migrated over to SuperTokens forgets their passwords and tries the password reset flow
    • In this situation, the regular password reset flow will not work since password resets require an existing account.
    • The changes proposed in Step 3 and Step 4 resolve the this edge case.
  • User starts the password reset flow and attempts to sign in with a temporary password
    • If, for any reason, the user tries to sign into their account with the temporary password, then the login method should be blocked.
    • The changes proposed in Step 5 allows for this flow
  • User starts the password reset flow but they remember their password and try to login with the valid password.
    • In this scenario if the user starts the password reset flow, a new SuperTokens account with a temporary password is created. Instead of completing the password reset flow they remember their password and try to sign in. In this case the user should be able to successfully sign in and the account should be updated with the valid password.
    • The changes proposed in Step 5 allows for this flow.

When can I stop using my legacy authentication provider?#

Your migration period could be decided by either of the following factors:

  • A time window (2-3 months) within which "just-in-time" migration is active.
  • A user migration threshold where, after a certain percentage of the userbase is migrated, the migration period ends.

After the migration period ends you have to make the following changes to stop automatic user migration:

  • Remove all migration related override changes in your backend.
  • Take the remaining users' emails and call the signup function with a secure randomized password.
  • Email users encouraging them to go through the password reset flow.