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. Using the dev license key is free. We only start charging you once you enable the feature in production using the provided production license key.

For managed service users, you can click on the "enable paid features" button on our dashboard, and follow the steps from there on. Once enabled, this feature is free on the provided development environment.

Security considerations

SuperTokens enforces that a user has completed all the required factors by keeping track of and checking them in the user's access token payload.

There are several checks done in our sign in / sign up APIs to ensure safety and prevent misuse:

• When a sign in or sign up API is called for a particula login method, and if the user doesn't already have a session, we enforce that the current login method is a part of the first factors configuration, else we return a 401 status code.
• If a user is required to complete a MFA challenge, for example TOTP, if they already have a verified TOTP device, they cannot setup any other factor before completing this factor challenge, and if they do not yet have a verfied TOTP device, then the only action they are allowed to take is to create a new TOTP device. This ensures that a user cannot bypass the MFA challenges of the current or future step.
• When a user creates a new TOTP device, it cannot be used unless they first verify it by entering the inital TOTP code.
• If the email of the 2nd factor login method is not verified, by default, we do not allow it to be setup or used as a 2nd factor, unless the session user has a login method that has the same email which is verified.
• There is a fixed number of times (5 times by default) a user can enter an invalid TOTP code, after which they have to wait for 15 mins before trying again. This timeout and the max attempts count can be changed in the core config.
• During sign up (not sign in), for email / SMS OTP challenge, the email / SMS that the OTP is sent to is determined by the frontend. This is intentional because it allows you to easily create a flow in which the email the OTP is sent to may not be the same as the login method of the first factor. However, from a security point of view, it allows a malicious actor to send an OTP to a different email / phone number than the first factor's phone or email. This is not an issue if you are using email OTP as a method for email verification because the email verification recipe checks that the email of the first factor is verified, and in the case of the malicious user, the email of the first factor won't be verified because they entered a different email for otp-email challenge.