Integration of user login and event validation with static password
With OneSpan Intelligent Adaptive Authentication you can implement functionality for your users to log in to your web application and validate events using a static password during the grace period or in concurrence with other one-time password (OTP)-based authentication.
The static password for your account is set at its creation, and can be modified on an as-needed basis. The use of the static challenge depends on the defined rules, which include the grace period parallel or exclusive use of the authenticator OTP solution.
The use of static passwords or other authentication methods depends on the rules Rules are used to define sets of criteria to verify if an event (transaction and non-monetary event) matches any fraudulent behavior. If an event matches a previously defined rule, an alert can be raised. set in the Risk Management component. The challenge must return the value set to 2.
The static password-based adaptive authentication can use the synchronous or asynchronous flow. Event validation refers to the POST /users/{userID@domain}/events/validate endpoint. The endpoint should specify the event type as LoginAttempt.
Synchronous login mode with static password
![](/sites/default/files/adaptive-authentication.integration-guide/Images/Login_Flow_Sync_Static_Pwd.png?timestamp=1725758573)
Login flow - synchronous mode and static password
The login sequence checks the browsing context and analyzes the risk of the user login. Depending on the rules set in the Risk Management component, the Login service challenges the user. If the user includes the provisioned static password in the authentication request, the second login request is successfully accepted.
Sequence of the synchronous login mode with static password
Before starting the operation, ensure the correct state of the user account by validating the output of the GET /users/{userID@domain} endpoint.
- The user initiates the adaptive authentication (AA) login operation and triggers the client application to send a login and event validation request. This request includes the following parameters:
- authenticator user
- authenticator domain
- CDDC data
- session identifier
- timeout
The user's credentials (static password) must not be included in the request input!
- The web service triggers a Risk Management component-event request for the login.
- The Risk Management component responds with a static password challenge (challenge value is 2).
- The web service returns a static password challenge to the client application.
- The server answers to the POST request with a HTTP 200 status code and includes the static password challenge in the riskResponseCode field.
- The client application collects the static password (provided by the user).
- The client application sends a new login request and includes the authenticator user, authenticator domain, CDDC data, same session identifier, request identifier, static password, and timeout to the Login web service.
- The web service validates the static password (using Intelligent Adaptive Authentication).
- Intelligent Adaptive Authentication returns that the static password validation has been successful.
- The web service returns to the client application that the authentication has been successful.
Asynchronous login mode with static password
![](/sites/default/files/adaptive-authentication.integration-guide/Images/Login_Flow_Async_Static_Pwd.png?timestamp=1725758573)
Login flow - asynchronous mode and static password
The login sequence checks the browsing context and analyzes the risk of the user login. Depending on the rules set in the Risk Management component, the Login service challenges the user setting in the riskResponseCode field, if the challenge value is set to 2. If the user includes the provisioned static password in the authentication request, the second login request is accepted.
Intelligent Adaptive Authentication follows these steps for the asynchronous login mode:
- The Intelligent Adaptive Authentication Login service is called with timeout set to 0. The login process is started, challenges the user (same process step as in the synchronous login mode), and immediately returns the current state of the session. In the Static Password use case, the check session state will always return Accepted.
- The Check Session Status service returns the current session and notification states of the login request immediately, without waiting for the notification process to complete.
Sequence of the asynchronous login mode with static password
Before starting the operation, ensure the correct state of the user account by validating the output of the GET /users/{userID@domain} endpoint.
- The user initiates the adaptive authentication login operation, triggering the client application to send a login and event validation request without providing credentials (including the authenticator user, the authenticator domain, CDDC data, and the session identifier).
- The Login web service triggers a Risk Management component-event request for the login.
- The Risk Management component responds with a static password challenge (value 2).
- The Login web service returns an HTTP 200 status code with the riskResponseCode field set to the static password challenge value.
- The client application sends a check-session request (concurrent with the HTTP response step above). For more information, see /sessions/{requestID}.
- The web service returns the HTTP 200 status code to the client application.
- The client application collects the static password (provided by the user).
- The client application sends a new login request (by providing their authenticator user, authenticator domain, CDDC data, same session identifier, request identifier, static password) to the Login web service.
- The web service validates the static password (using Intelligent Adaptive Authentication).
- Intelligent Adaptive Authentication returns the validation result of the static password.
- The Login web service forwards the validation result to the web service.
- The client application sends a check-session request. For more information, see /sessions/{requestID}.
- The session status is returned to the web service.
- The web service returns an HTTP 200 status code to the client application that the authentication has been successful.