Skip to main content

Implementing account deduplication

The approach to implementing account deduplication is to override the backend functions / APIs which create a user such that:

  • We check if a user already exists with that email.
  • If a user does not exist, we call the original implementation; Else
  • We return a message to the frontend telling the user why sign up was rejected.

Add the following override logic to ThirdPartyPasswordless.init on the backend

import ThirdPartyPasswordless from "supertokens-node/recipe/thirdpartypasswordless";
import supertokens from "supertokens-node";

ThirdPartyPasswordless.init({
override: {
functions: (originalImplementation) => {
return {
...originalImplementation,
thirdPartySignInUp: async function (input) {
let existingUsers = await supertokens.listUsersByAccountInfo(input.tenantId, {
email: input.email
});
if (existingUsers.length === 0) {
// this means this email is new so we allow sign up
return originalImplementation.thirdPartySignInUp(input);
}
if (existingUsers.find(u =>
u.loginMethods.find(lM => lM.hasSameThirdPartyInfoAs({
id: input.thirdPartyId,
userId: input.thirdPartyUserId
}) && lM.recipeId === "thirdparty") !== undefined)) {
// this means we are trying to sign in with the same social login. So we allow it
return originalImplementation.thirdPartySignInUp(input);
}
// this means that the email already exists with another social or passwordless login method, so we throw an error.
throw new Error("Cannot sign up as email already exists");
}
}
},
apis: (originalImplementation) => {
return {
...originalImplementation,
createCodePOST: async function (input) {
if ("email" in input) {
let existingUsers = await supertokens.listUsersByAccountInfo(input.tenantId, {
email: input.email
});
if (existingUsers.length === 0) {
// this means this email is new so we allow sign up
return originalImplementation.createCodePOST!(input);
}
if (existingUsers.find(u =>
u.loginMethods.find(lM => lM.hasSameEmailAs(input.email) && lM.recipeId === "passwordless") !== undefined)) {
// this means that the existing user is a passwordless login user. So we allow it
return originalImplementation.createCodePOST!(input);
}
return {
status: "GENERAL_ERROR",
message: "Seems like you already have an account with another method. Please use that instead."
}
}
// phone number based login, so we allow it.
return originalImplementation.createCodePOST!(input);
},
thirdPartySignInUpPOST: async function (input) {
try {
return await originalImplementation.thirdPartySignInUpPOST!(input);
} catch (err: any) {
if (err.message === "Cannot sign up as email already exists") {
// this error was thrown from our function override above.
// so we send a useful message to the user
return {
status: "GENERAL_ERROR",
message: "Seems like you already have an account with another method. Please use that instead."
}
}
throw err;
}
}
}
}
}
})

In the above code snippet, we override the thirdPartySignInUpPOST and the createCodePOST API as well as the thirdPartySignInUp recipe function.

The thirdPartySignInUpPOST API is called by the frontend after the user is redirected back to your app from the third party provider's login page. The API then exchanges the auth code with the provider and calls the signInUp function with the user's email and thirdParty info.

The createCodePOST API is called when the user enters their email, or phone number during passwordless login. This API generates the passwordless OTP / link and sends it to the user's email / phone.

We override the thirdPartySignInUp recipe function to:

  • Get all ThirdParty or Passwordless users that have the same input email.
  • If no users exist with that email, it means that this is a new email and so we call the originalImplementation function which creates a new user.
  • If instead, a user exists, but has the same thirdPartyId and thirdPartyUserId, implying that this is a sign in (for example a user who had signed up with Google is signing in with Google), we again allow the operation by calling the originalImplementation function.
  • If neither of the conditions above match, it means that the user is trying to sign up with a third party provider whilst they already have an account with another provider or via passwordless login. So here we throw an error with some custom message.

Finally, we override the signInUpPOST API to catch that custom error and return a general error status to the frontend with a message that will be displayed to the user in the sign in form.

We also override the createCodePOST API to perform similar checks:

  • If the input is phone number based, then we call the originalImplementation function allowing sign up or sign in. This is OK since social login is always email based, so there is no scope of duplication.
  • Otherwise, we det all ThirdParty or Passwordless users that have the same input email.
  • If no users exist with that email, it means that this is a new email and so we call the originalImplementation function which creates a new user.
  • Else we check if the existing user is not a Third Party login user, implying that it's a Passwordless login user. So here, we also call the originalImplementation function to allow the user to sign in.
  • If neither of the conditions above match, it means that the user is trying to sign up with passwordless login whilst they already have an account with a third party provider. So here we return an appropriate message to be displayed on the frontend.
Multi Tenancy

For a multi tenant setup, the customisations above ensure that multiple accounts with the same email don't exist within a single tenant. If you want to ensure that there is no duplication across all tenants, then when fetching the list of existing users, you should loop through all tenants in your app, which you can fetch by using the listAllTenants function of the multi tenancy recipe.

Looking for older versions of the documentation?
Which UI do you use?
Custom UI
Pre built UI