Which UI do you use?

Custom UI

Pre built UI

Paid Feature

This is a paid feature. For self hosted users, Sign up to get a license key and follow the instructions sent to you by email. This will start a SuperTokens subscription.

If you are using the development environment of our managed service you can use this feature for free. If you want to enable this feature for the production environment, please email us

Security considerations for automatic account linking

Below is the list of all points in time when we do account linking, and for each point, you can see the list of security checks that happen:

1) During sign up:

Case a

• Email is e1
• Email is verified: false (is the case with email password sign up or social login with a provider that does not require email verification)

Checks done:

• i) If there is no primary user with the same email, then we disallow sign up if there exists any other non-primary account with the same email and that account is not verified. We do this because if we didn't, there is a risk that if this user signs up and becomes a primary user, the other account (which could be malicious), might resend a verification email and the user might click on it (since they just signed up) and verify the malicious account, thereby linking it to their account. This way, the malicious user will have access to the victim's account.
• ii) If there exists a primary user with the same email, then we reject sign up of this new user. This is done cause if we allowed it, and this sign up is from a malicious user, then the actual user (the primary user owner) may get an email for verification, and might click it (since they did sign up previously). This will cause the new, malicious account to be linked, thereby giving the malicious user access to the victim's account.

What users see:

• i) In case of email password login, users see an account already exists error, in which case, they can try logging in with another method, or go through the password reset flow, which will create a new email password account for them as well as verify it.
• ii) In case of social login, users will see that they should try a different login method for security reasons.

Case b

• Email is e1
• Email is verified: true (is the case with social login with a provider that requires email verification, like google, or it could be a passwordless sign up)

Checks done:

• i) Same as in Case 1a, point (i) above.
• ii) If there exists a primary user with the same email, then we allow sign up only if there exists at least one login method in the primary user with email e1 which is verified. This is done because if we didn't, then the following account takeover is possible:
  • Malicious user signs up with email password, with email e2, verifies it, and becomes a primary user.
  • They then change their email to e1, and keep it in an unverified state.
  • Now the actual user (victim), does a google sign with email e1.
  • If we don't stop this sign up, then the new sign up will be linked to the primary user, and the malicious user will have access to the victim's account.

What users see:

• Users will see that they should try a different login method for security reasons.

2) During sign in:

Case a

• Email is e1
• Email is verified: false
• User is not a primary user

Checks done:

• If there exists another user with the same email, and they are not a primary user, but their email is unverified, we disallow this sign in because if we did, and this user verifies their email, it will result in this user becoming a primary user. If the other account then sends an email verification email, this user may click on it (they may not get too suspicious), and verify the other account, thereby linking it to their account. This way, the other account, which may belong to a malicious user, will have access to the victim's account.
• If there exists another user with the same email, and they are not a primary user, we disallow signing in. This is done cause if we allowed it, and this sign in is from a malicious user, then the actual user (the primary user owner) may get an email for verification, and might click it (since they did sign up previously). This will cause the new, malicious account to be linked, thereby giving the malicious user access to the victim's account.

What users see:

• For email password sign in, users will see a wrong credentials error message. This will prompt them to go through the password reset flow, which will also mark the email as verified, thereby allowing them to sign in. This will also block sign ins from malicious users, since the new password is only known to the actual owner of the email.
• For passwordless or social login, users will see that they should try a different login method for security reasons.

Case b

• The user first does a social login sign up with email e1.
• They then change their email to e2 on the provider and tries signing in again.
• The third party provider does not verify emails, so e2 is unverified.

Checks done:

• If the social login user is not a primary user, and there exists another primary user with email e2, then we disallow sign in here. This is done cause if we allowed it, and this sign in is from a malicious user, then the actual user (the primary user owner) may get an email for verification, and might click it (since they did sign up previously). This will cause the new, malicious account to be linked, thereby giving the malicious user access to the victim's account.
• If this user is a primary user, and there exists another primary user with email e2, we disallow sign in because there can't be two primary users with the same email. The email update which happens during sign in for social login, is rejected.

What users see:

• For the first point, users will see a message asking them to try a different login method, or contact support for security reasons.
• For the second case, users will see that email update is not allowed and to contact support.

3) During password reset flow:

• Malicious user has email password and a social login account with email e1, and they both are linked.
• They then change their email to e2 for the email passowrd login, which belongs to the victim.
• Actual owner of e2 tries to sign up, but sees that their account already exists (Case 1), they then try to sign in, but can't cause they don't know the password. So they try the password reset flow.

Checks done:

• In this case, we deny generating the password reset token because if we did, then the real user would change the password of the email password account, and also mark it as verified. They would have access to the account, however, the malicious user could also then login using social login (with email e1) to access the same account.

  More generally, during password reset, we do not generate a token if the email password account for that email is associated with a primary account that also has other emails / phone numbers, and the email for which the password is being reset is not verified for any of the login methods in that primary user.

What users see:

• They will see a message telling them that the reset password link was not generated becasue of account takeover risk, and to contact support.

4) During email update flow:

• A user has email e1, and they want to change it to email e2

Checks done:

• If the user's account is not a primary user, and there exists another primary user with email e2, then we disallow email update here. This is done cause if we allowed it, and this email update is from a malicious user, then the actual user (the primary user owner) may get an email for verification, and might click it (since they did sign up previously). This will cause the new, malicious account to be linked, thereby giving the malicious user access to the victim's account.
• If this user is a primary user, and there exists another primary user with email e2, we disallow email update because there can't be two primary users with the same email.

What users see:

• If the email update is happening during sign in of social login, users will see a message that email update is not allowed and to contact support.
• If this is happening post login (from a settings page), then you can send any message you want to the user, since this would be your custom API.