Mobile-First Authentication
Product Description
May 04, 2025
Product Overview
Mobile-first authentication by Wultra, also branded as PowerAuth, is a system designed to provide multi-factor authentication (MFA), ensuring compliance with the most stringent global regulatory requirements for secure authentication. This includes Strong Customer Authentication (SCA) under PSD2 in the European Union, as well as other relevant security regulations and standards worldwide.
Solution High-Level Architecture
Wultra’s authentication solution consists of backend components and SDKs that can be easily integrated into mobile applications. These components work together to provide secure authentication services and ensure smooth communication between mobile applications and backend systems, leveraging the PowerAuth protocol for strong customer authentication (SCA).
The solution can be deployed on-premise, in the client’s cloud infrastructure, or provided by Wultra as a SaaS.
Backend Components
The backend infrastructure for the Wultra authentication solution consists of several components:
PowerAuth Cloud
The component provides the private API on the /powerauth-cloud context. A trusted customer backend system calls the private API. Its primary function is to manage user registrations and initiate operations such as device activation or authentication requests. Communication is secured and requires Basic Authentication or OAuth 2.x authorization before other systems can interact with it.
PowerAuth Server
The core back-end component and counterpart of PowerAuth Mobile SDK, it is responsible for device registration, activation lifecycle, application management, operation approval, and signature verification.
Enrollment Server
This component exposes the public API under the /enrollment-server context that facilitates communication between mobile SDKs embedded in mobile apps and the backend system. Unlike the Private API, the client (or mobile app) does not need to interact directly with the Public API. Instead, it serves as a standardized interface for secure communication via the PowerAuth protocol.
The enrollment server publishes the following services:
- PowerAuth Standard RESTful API
- Push Registration API
- Mobile Token Operations API
PowerAuth Push Server
PowerAuth Push Server is an optional application that facilitates sending APNs / FCM/ HMS messages alongside the PowerAuth Server installation. It uses PowerAuth Server to obtain information about users and device activation state and to provide extra security features.
PowerAuth Mobile Libraries
Wultra provides a set of SDKs that can be integrated into the client’s mobile application. These SDKs handle various tasks related to device activation, operation signing, and other tasks related to the authentication lifecycle.
PowerAuth Mobile SDK
This SDK provides essential features for authentication, device activation, and data signing in mobile apps. SDKs are available for both iOS and Android, as well as React Native Bridge.
PowerAuth Mobile Token SDK
This SDK is built on top of the PowerAuth Mobile SDK. It communicates with the Mobile Token API and helps you integrate out-of-band operation approval into an existing mobile app.
Activation Spawn SDK
This SDK installs and activates another application’s PowerAuth instance from an already activated mobile application. This process eliminates the need for the user to go through the onboarding process again. The activation spawn process relies on a service within the main application to fetch an activation code and pass it to the secondary application for activation.
Proximity Transfer SDK
The SDK secures data transfer between two devices in close proximity using Bluetooth and QR scanning. It is typically used for a seamless new device activation using the old(activated) device.
Dynamic SSL/TLS Pinning SDK
This SDK manages a dynamic list of SSL/TLS certificates that are fetched from a remote server. All entries are signed with a private key on the server side and validated in the client side using the public key, ensuring that all certificates are validated using public key (we’re using the ECDSA-SHA 256 algorithm).
This optional solution provides an easy-to-use fingerprint validation on the TLS handshake, enhancing security for mobile app communication.
Device Fingerprint SDK
The SDK generates a unique device fingerprint based on device-specific attributes such as carrier, operating system version, and hardware details.
Passphrase Meter
A multi-platform library for evaluating the strength of a user’s passphrase. It operates offline and can be integrated into mobile apps to ensure users choose strong passphrases.
PowerAuth Networking SDK
A high-level networking SDK that simplifies communication with PowerAuth-based endpoints in mobile apps.
Solution Functionalities
The functionalities of PowerAuth are grouped into two main areas:
| Functionality | Description |
|---|---|
| Device Management and Secure Binding | This aspect focuses on securely linking any app integrated with the PowerAuth SDK to its corresponding backend representation through cryptographic methods. It ensures that each device is authenticated and bound to the server securely, enabling trusted communication between the mobile app and the backend system. |
| Approval Operations for Business Transactions | PowerAuth uses a concept called Approval Operations to verify business transactions, whether a login attempt, payment, or any other sensitive operation, such as a 3D secure or open banking transaction. For each transaction, the system creates an operation that the user must approve, ensuring that the bank can trust the transaction’s legitimacy and that the authenticated user initiated it. |
Device Activation
During the device activation in PowerAuth, a shared secret called the activation code must be exchanged between the backend server and the mobile application. There are several methods for securely transmitting this activation code, depending on the context of user authentication and the available channels:
| Feature | Description |
|---|---|
| Data Channel Exchange | If the user’s authenticity has already been verified, the activation code can be transmitted directly through a secure data channel. This is suitable for scenarios where the communication between the client and server is already established and trusted. |
| QR Code | When the user has access via another channel, such as a web application or a printed contract, the activation code can be shared as a QR code. The user can then scan the QR code using the mobile app to complete the activation process securely. |
| Manual Typing | The activation code can also be manually retyped by the user, such as from a printed document or another trusted source, providing flexibility in conveying the code. |
| OpenID Connect (OIDC) Flow | The activation code can be issued following a successful OIDC flow, where the user’s identity has been authenticated via an external identity provider (e.g., Google or other federated login services), ensuring a seamless and secure activation process. |
| Optional OTP (One-Time Password) | An OTP can be required during the activation process as an additional security measure. In this case, the user must provide both the activation code and an OTP to complete the device activation. However, using an OTP is optional and can be enabled based on the security policies. |
This flexible activation process allows PowerAuth to adapt to different security needs while ensuring the device is securely bound to the backend via cryptographic means.
Migration
Legacy solutions are typically migrated to PowerAuth on the fly, where users log into the new mobile application using their old credentials. Once the user is verified, a new activation code is generated, and the PowerAuth registration is activated on the backend without the user noticing, ensuring a seamless transition with no additional activation friction.
However, if the legacy solution lacks MFA or there is concern about compromised accounts, a dedicated activation process can be initiated to enhance the user’s security profile during the migration (e.g., a face recognition scan compared against stored data).
Device Binding
When the activation code is exchanged and verified between the mobile app and the backend in PowerAuth, both the mobile client and server generate ECDH (Elliptic-Curve Diffie-Hellman) key pairs.
These key pairs are used to compute a shared master secret via cryptographic operations securely. This key master secret is crucial but serves only as a foundation for deriving various other keys used within the system.
The master secret is never used directly; instead, it helps derive:
- Asymmetric Signing Keys: These keys are used to verify signatures for secure communication and transaction approvals.
- Symmetric Signing Keys: These keys are applied in operation approvals, ensuring the integrity and authenticity of operations like login, payments, and other sensitive actions. The keys are derived for each factor, i.e., one for possession, one for knowledge (PIN or Passphrase), and one for biometric authentication (protected by the device’s biometric chip).
- Temporary Encryption Keys: These keys are used to establish end-to-end encryption, enabling secure communication between the mobile client and the backend. This feature supports forward secrecy, meaning that even if the encryption key is compromised in the future, past communications remain secure.
By deriving specific keys from the master secret, PowerAuth ensures that each key is tailored for a particular security purpose. This isolates different types of operations and prevents key reuse across contexts, significantly enhancing the system’s security.
Operation Signing
After the user activates the mobile app, it is ready for its main use case, operation/ transaction signing. Transaction signing is technically used for all types of operations - login, payments, configuration changes, etc. In all cases, the user needs to enter a PIN code set during the activation or use biometrics on the mobile device to compute an authentication code for the data. The authentication code is later verified on the server side.
In the case of the login, the authentication code is computed only from the authentication factor keys. In the case of the payment (or other similar operation that generally has some data assigned to it), both authentication factor keys and operation data are reflected in the resulting authentication code.
Auditing
The auditing services provide detailed tracking of all critical actions, such as transaction approvals or logins, ensuring that security and compliance requirements are met.
The audit logs can be accessed via a dedicated API, allowing for seamless integration with external monitoring and reporting tools.
Testing
PowerAuth can be manually tested once integrated into a bank’s mobile application. However, for automated testing, security components like authentication are often skipped due to the complexity of integrating security solutions into test environments.
To address this, PowerAuth provides several tools to support automated testing, the most notable of which is the PowerAuth Test Server.
The test server simulates devices by offering an API to perform actions like device activation, signature generation, and operation approval. Since it’s API-based, it can be easily incorporated into automated test pipelines or used in performance testing scenarios, ensuring thorough testing without compromising security.
Documentation
All components are documented on the Wultra Developer Portal. The documentation contains:
- Installation Instruction - how to install the product with HW requirements.
- Configuration - configuration of the product setup.
- API Description - documentation of provided API.
- Database Structure - all database structures on DB column level.
- Migration Instructions - list of all changes and instructions for migrating from the previous version.
The documentation is versioned for each minor product release.
