The diagrams below illustrate how session JWTs are used when an end user migrates from using a conventional user ID and password to FIDO authentication. The end user must be verified by your IDentity Management System (IDMS) before they can register their first FIDO authenticator. After they register a FIDO authenticator, the end user signs in using FIDO authentication.
Figure 1 shows how a JWT is used during conventional sign in.
(2).png?sv=2026-02-06&spr=https&st=2026-09-30T01%3A24%3A54Z&se=2026-09-30T01%3A37%3A54Z&sr=c&sp=r&sig=dS0vljpqqtqccRu3cAOCeZG71A1WreHNHeB%2FgTiZ5ac%3D)
Figure 1 How a JWT is Used During Conventional Sign In
The end user signs in with legacy authentication, typically an ID and password.
After your IDMS authenticates the user, it sends a JWT containing the session information to the client app. You can reference the JWT's claims as context data in an Adaptive Rule, see Digipass S3 Context Data.
The end user starts the registration process for a FIDO authenticator.
The client app sends the FIDO registration request along with the JWT to the Digipass S3 Server.
The Digipass S3 API Server evaluates all incoming requests to the Digipass S3 Server. It validates the JWT in one of two ways:
The API Server validates the JWT using either a shared secret key (if the JWT key is symmetric) or a public key (if the JWT key is asymmetric).
The API Server sends the JWT to your server to validate. This is accomplished using a custom session plugin.
If the JWT is valid, the API Server forwards the request to the Authentication Server.
The Auth Server processes the FIDO registration request. Assuming that it's successful, it registers the FIDO authenticator for the user and returns success. A JWT is not generated on a successful registration.
After the end user has registered a FIDO authenticator, they can sign in using the FIDO authenticator they registered. First, let's get an overview of what happens during FIDO authentication as shown in Figure 2.
.png?sv=2026-02-06&spr=https&st=2026-09-30T01%3A24%3A54Z&se=2026-09-30T01%3A37%3A54Z&sr=c&sp=r&sig=dS0vljpqqtqccRu3cAOCeZG71A1WreHNHeB%2FgTiZ5ac%3D)
Figure 2 FIDO Authentication Overview
The user initiates authentication from within the mobile app by clicking the login button
The Authentication Server sends an authentication request to the client. The request includes the challenge string and authentication policy that defines which authenticators the server is willing to accept
The authenticator verifies the user and unlocks the private key previously generated
The private key is used to sign the challenge and the generated authentication response is sent back to server
The server validates the received string is the same as the challenge that was sent using the public key
A JWT is generated after the Authentication Server validates the authentication response and returns success, as shown in the Figure 3 below. This is done in one of 2 ways:
The API Server generates a JWT containing session information.
The API Server sends a request to your server to generate the JWT via a custom session plugin.
Figure 3 The API Server generates the JWT after FIDO authentication
Next, the API Server sends the authentication response and JWT to the client app. Using the JWT, the end user can access functionality and resources available on your backend server. Your backend server validates the JWT using its key.
Alternatively, a user can utilize the FIDO authenticator in a step-up authentication scenario. In a step-up scenario, a user is already authenticated but performs an action that requires additional authentication such as transferring money. You can use Adaptive Authentication to determine when to perform a step-up authentication for a regular non-step-up authentication.
As long as there is a JWT with session information, the user can register additional authenticators or view or delete their existing registered authenticators.
If your IDS uses a different type of token for session information, you can continue to use that token with a custom session plugin. Or you can convert that token into a JWT in your backend server. Avoid converting JWTs in the client app because the client app is vulnerable to security breaches. For information about custom API Server plugins, see Creating a Custom API Server Plugin.