Account deduplication
Overview
Users may forget the initial method they used to sign up and may create multiple accounts with the same email ID - leading to a poor user experience. Preventing this from happening refers to account deduplication.
As an example, assume that your app has Google and GitHub login.
There exists a user who had signed up with Google using their email ID - user@gmail.com.
If this user then tries to sign up with GitHub, which has this same email (user@gmail.com), your app disallows this. It shows them an appropriate message like "Your account already exists via Google sign in. Please use that instead."
Comparison to account linking
Related to this problem is also the concept of account linking. The difference is that whilst deduplication prevents duplicate sign ups, account linking allows duplicate sign ups, but implicitly merges the duplicate accounts into one.
Steps
1. Override the authentication recipes
The approach to implementing account deduplication is to override the backend functions / APIs. This way you check if a user already exists and return an error to the frontend if the condition is true.
import ThirdParty from "supertokens-node/recipe/thirdparty"
import Passwordless from "supertokens-node/recipe/passwordless";
import supertokens from "supertokens-node";
let recipeList = [
Passwordless.init({
override: {
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);
},
}
}
}
}),
ThirdParty.init({
override: {
functions: (originalImplementation) => {
return {
...originalImplementation,
signInUp: 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.signInUp(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.signInUp(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,
signInUpPOST: async function (input) {
try {
return await originalImplementation.signInUpPOST!(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, override the signInUpPOST (third party recipe) and the createCodePOST (passwordless recipe) API as well as the signInUp recipe function.
The frontend calls the signInUpPOST API after the user returns 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 third-party info.
The system calls the createCodePOST API 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 signInUp 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 the system calls the
originalImplementationfunction to create a new user. - If instead, a user exists, but has the same
thirdPartyIdandthirdPartyUserId, implying that this is a sign in (for example a user who had signed up with Google is signing in with Google), the operation proceeds by calling theoriginalImplementationfunction. - 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. Here, the system throws an error with some custom message.
Finally, override the signInUpPOST API to catch that custom error and return a general error status to the frontend with a message 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 the system calls the
originalImplementationfunction allowing sign up or sign in. This is OK since social login is always email based, there is no scope of duplication. - Otherwise, 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 the system calls the
originalImplementationfunction to create a new user. - Else, check if the existing user is not a Third Party login user, implying that it's a Passwordless login user. Here, the
originalImplementationfunction is also called 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. Here, the system returns an appropriate message to display on the frontend.
For a multi tenant setup, the customisations above ensure that multiple accounts with the same email don't exist within a single tenant. To ensure no duplication across all tenants, when fetching the list of existing users, loop through all tenants in your app. You can fetch them by using the listAllTenants function of the multi tenancy recipe.