Enroll new authentication factors and build challenge verification.
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:
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!
As a best practice, your WorkOS API key should be kept secret and set as an environment variable on process start. The SDK is able to read the key automatically if you store it in an environment variable named WORKOS_API_KEY; otherwise, you will need to set it manually. The Client ID should also be set dynamically based on the release environment.
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.
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.
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.
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.