Multi-Factor Authentication
A composable API for implementing multi-factor authentication.
The Multi-Factor Authentication (MFA) API is intended to be a composable, unopinionated set of endpoints that can be integrated into existing application/session management strategies.
The available types of authentication factors are:
totp– Time-based one-time passwordsms– One-time password via SMS message (US only)
In this guide, we’ll walk you through the process of enrolling new authentication factors for a user, and the challenge/verification process for existing authentication factors.
This guide will show you how to:
- Create an Authentication Factor
- Challenge the Authentication Factor
- Verify the Challenge
- Authentication Factor
- A factor of authentication that can be used in conjunction with a primary factor to provide multiple factors of authentication.
- Authentication Challenge
- A request for an Authentication Factor to be verified.
WorkOS offers native SDKs in several popular programming languages. Choose a language below to see instructions in your application’s language.
Don't see an SDK you need? Contact us to request an SDK!
Install the SDK using the command below.
| npm install @workos-inc/node |
| yarn add @workos-inc/node |
| gem install workos |
| gem "workos" |
| <dependency> | |
| <groupId>com.workos</groupId> | |
| <artifactId>workos</artifactId> | |
| <version>{version}</version> | |
| </dependency> |
| dependencies { | |
| implementation 'com.workos:workos:VERSION' | |
| } |
To make calls to WorkOS, provide the API key and, in some cases, the client ID. Store these values as managed secrets, such as WORKOS_API_KEY and WORKOS_CLIENT_ID, and pass them to the SDKs either as environment variables or directly in your app’s configuration based on your preferences.
Use the TOTP type when the user is using a third-party authenticator app such as Google Authenticator or Authy.
The response returns a qr_code and a secret. The qr_code value is a base64 encoded data URI that is used to display the QR code in your application for enrollment with an authenticator application.
The secret can be entered into some authenticator applications in place of scanning a QR code.
Use the SMS type when the user wants to receive one time passwords as SMS messages to their mobile device.
Phone number must be a valid US number. An error will be returned for malformed or invalid phone numbers.
Now that we’ve successfully created an authentication factor, we’ll need to save the ID for later use. It’s recommended that you persist the factor ID in your own user model according to your application’s needs.
Next we’ll initiate the authentication process for the newly created factor which we’ll refer to as a challenge.
When challenging an SMS authentication factor, you can pass an optional SMS template to customize the SMS message that is sent to the end user. Use the {{code}} token to inject the one time password into the message.
Now that we’ve successfully challenged the authentication factor, we’ll need to save the challenge ID for the last step, challenge verification.
The last step in the authentication process is to verify the one time password provided by the end-user.
If the challenge is successfully verified valid will return true. Otherwise it will return false and another verification attempt must be made.
If a challenge was already successfully verified, it cannot be used a second time. If further verification is needed in your application, create a new challenge.
For SMS authentication factors, challenges are only available for verification for 10 minutes. After that they are expired and cannot be verified.
We’ve now successfully verified an end-user’s authentication factor. This authentication factor can now be used as a second factor of authentication in your application’s existing authentication strategy.
The ID of the authentication factor should be persisted in your application for future authentication challenges.