Introduction
This describes the integration of the Digipass S3 Server with your application's infrastructure, any Identity and Access Management system you may have, and your applications.
Deployment architecture
The Authentication Server should be deployed behind your application’s infrastructure and should not be directly exposed to the Internet. See Figure 1. This model provides additional security and also provides greater programmatic control over Authentication Server behavior.
.png?sv=2026-02-06&spr=https&st=2026-09-30T02%3A58%3A20Z&se=2026-09-30T03%3A11%3A20Z&sr=c&sp=r&sig=FguGeRGGKIcAxpQ1L5eeH3nd1c%2F494bVOR2DvMPLyZ8%3D)
Figure 1 Deployment Architecture
The API Server handles session management. To use your application infrastructure to handle session management, write a custom API Server session plugin. If your application infrastructure uses a static rules engine or a risk scoring system, your application infrastructure can use those systems to determine which Digipass S3 authentication policy to select.
Server installation
Installing the Digipass S3 Server requires configuring and running a setup script. As part of the installation process you may need to install and/or configure Apache Tomcat, databases like Oracle, MySQL, PostgreSQL, or CockroachDB, and other components.
The Digipass S3 Server also supports deployment on Docker containers. This container support further simplifies server deployment and maintenance updates for both on-premise and public-cloud.
Configuring authentication behavior
Configure Digipass S3 Software to support your apps using UAF or FIDO2 protocol, create FIDO policies to specify your organization's valid authenticators, define Adaptive Rules and their supporting objects, and more. See the Configuration Overview.
Session management integration
Session management is essential to control access to protected resources. In the case of FIDO, restrict the authenticator registration operation to known users who have already been identified when they successfully signed in. It is critical for the application infrastructure to determine if the user has an existing valid session before allowing registration to proceed. For example, session validity can be determined by validating JWTs or cookies that are sent to the user’s device when the user is authenticated. Once a valid session has been confirmed, the registration operation can proceed.
After successful authentication, the API Server creates a session for the user. The session is established by sending a JWT via the REST API response to the user’s device once the user is authenticated.
Transaction confirmation integration
The FIDO protocol supports a variant of the authentication operation known as secure transaction confirmation. This operation enables the Server and the Client to exchange transaction or payment details securely and to display the details on the user’s device for approval. The API Server provides a Transaction Plugin that you can integrate with your transaction systems. These details will be displayed by the Client on the user’s device. The user can then review and approve to proceed with the transaction.
The API Server Transaction Plugin also supports Secure Payment Confirmation. When you use SPC to authenticate a transaction and that authentication is successful, you receive important transaction details in the final assertion object. These transaction details include payee name, payee origin, the amount of the transaction, the currency used, and additional information.
Enabling scalability & availability
Digipass S3 Software is designed to enable organizations to support large authentication volumes and ensure high availability. In large scale deployments of Digipass S3 Software, an organization deploys multiple Authentication Server instances that, in conjunction with network infrastructure, enable authentication requests to be serviced by any Authentication Server instance. An example deployment architecture is shown in Figure 1.
In this architecture, a load balancer dispatches requests to Authentication Server cluster nodes and enables the Authentication Server to scale horizontally. New Authentication Server nodes can be added to the cluster to increase throughput and reduce response time. Also, as the Authentication Server performs mostly cryptographic operations, it is mainly CPU bound, and scales vertically. Machines with faster CPUs or higher number of cores can be used to increase throughput and decrease response time. To scale database storage across data centers, an RP may choose to deploy database mirroring or replication technologies from their database vendor.
Integrating with Identity and Access Management (IAM) infrastructure
Organizations that deploy IAM solutions (such as from vendors like IBM, CA, Oracle, Ping Identity, and so on) may choose to integrate the Authentication Server with those products, because they support integration of third-party authentication technologies using the vendor’s authentication adapter layer. In such a deployment, the Access Management software is responsible for proxying communications to the Authentication Server, as well as session management and policy control responsibilities.
Authorizing your mobile app with the Authentication Server
The Digipass S3 Server maintains a list of authorized applications based on a concept called a facet ID. When you add your app through the Admin Console, it automatically updates this list. This facet ID plays a critical role in ensuring that an external FIDO client can verify that only your client apps can perform authentication against your Server. See Configure apps for more details about apps and facet IDs.