OneSpan Cloud Authentication September Release – 25.R2

For calls to create and/or update users, a new validation will be introduced for the USERFLD_EMAIL and USERFLD_MOBILE fields. Currently, the Authentication component is returning status code 200 HTTP status OK (RET_SUCCESS/STAT_SUCCESS) when the user’s email address or phone number is invalid. Once the new validation, implemented in the Authentication component, is integrated in OneSpan Cloud Authentication, these user data will be strictly validated and the following applies whenever you create or update user accounts:

• Email addresses are only accepted if they are well formed. Special characters are not allowed.

• Phone numbers are only accepted if they comply with ITU-T E.164.

If any of those two user data are invalid, the Authentication component will be returning the 400 HTTP bad request (RET_FAILURE/STAT_INVDATA) error messages.

This affects the following endpoints:

• PUT /users/{userID@domain}

• PATCH /users/{userID@domain}

Existing user info fields are kept as is and are only revalidated when you attempt to update them.

As of version 24.R2, the input in the fingerprintRaw and fingerprintHash input data fields is optional. This applies to the following endpoints:

• POST /events

• POST /users/{userID@domain}/events/validate

• POST /transactions

• POST /users/{userID@domain}/transactions/validate

• POST /users/{userID@domain}/login

• POST /users/register

• POST /users/{userID@domain}/unregister

Orchestration error handling with the POST /orchestration-commands endpoint is deprecated and will be removed on 31 March 2026.

The deprecated /user/unregister endpoint has now been removed from the OneSpan Trusted Identity platform API.

Incorrect definitions and/or configurations of the Authentication component reports has had a severe negative impact on the availability of OneSpan Cloud Authentication services on individual or all tenants. To improve the availability these services we have improved how reporting privileges are handled. The possibility to define and run reports on the Authentication component via the OneSpan Cloud Authentication administration user web interface has been removed for new tenants and for tenants that are not using the reporting functionality. In this cases, the run_report permission has been disabled for all tenant administrator accounts and any custom-created administrator accounts. With the removal of the run_report permission, reports cannot be generated for the aforementioned cases but does not affect the possibility to view report files.

If the OneSpan Cloud Authentication integration for your tenant(s) supports and/or includes the reporting feature and is used as designed, this removal will not impact you!

OneSpan Cloud Authentication now offers a fallback mechanism if authentication via push notification fails. This applies for user authentication operations with orchestration and push notification.

Until now, if the user either did not receive a push notification message, or rejected it, they could not proceed with the authentication but had to restart the login procedure. As of this version, OneSpan Cloud Authentication generates a Cronto image which the user can scan if the push notification is not delivered and can continue the authentication operation. The following updates have been made in the OneSpan Trusted Identity platform API:

• A new delivery method has been added, RequestMessageInSession.

• A new response field, requestMessage, has been added to the response for the check session query.

• The relevant endpoints for the following web services have been extended:

  • Events

  • Sessions

  • Transactions

A user account can become locked after a specified number of unsuccessful authentication attempts. To ease the unlock effort and reduce support incidents, you can allow users to unlock a locked user account themselves without administrative assistance using user auto-unlock.

If you would like to use this feature, please contact OneSpan Support who will enable it for you and apply to the relevant authentication policies.

For more information, see Unlock locked user accounts automatically.

To improve traceability and non-repudiation for transaction signing, OneSpan Cloud Authentication now returns the serial number of authenticators used for both synchronous and asynchronous authentication operations. This facilitates verifying the security status of the transaction and trace the identity of the transaction’s signer.

The following endpoints have been extended:

• GET /sessions/{requestID}

• POST/users/{userID@domain}/login

• POST/users/{userID@domain}/events/validate

• POST /users/{userID@domain}/transactions/validate

For more information, see the OneSpan Cloud Authentication Integration Guide.

OneSpan Cloud Authentication now offers the possibility to retrieve all authenticators and authenticator instances that are activated for a particular user, and the last time the authenticator instance was used.

The GET /authenticators endpoint has been extended and now includes the assignedUserID filter in the query.

To eradicate timeouts during different operations, the OneSpan Cloud Authentication implementation on Amazon Web Services (AWS) has been adapted.

The timeouts were related to issues with the connection between the Audit Logger service and the Amazon MQ broker, and occurred during maintenance windows of the broker. The adapted implementation has removed the dependency on the broker as now Amazon Simple Queue Service (SQS) is used instead.

OneSpan Cloud Authentication supports the integration of mobile applications based on Mobile Authenticator Studio and Mobile Security Suite. These applications might require a dedicated authenticator license instead of using the existing DAL10 license. To prevent collisions between different authenticator licenses, a new authenticator type has been introduced, TID10. This can be applied on all tenants.

The delivery of virtual one-time-passwords can be customized for specific users. Before, it was not possible to set this value to None and/or reset this value again to default settings via the OneSpan Trusted Identity platform API without SMS delivery issues. With this version of OneSpan Cloud Authentication, it is now possible to have an empty value for the mdcProfile field, the PATCH /users/{userID@domain} endpoint has been extended accordingly.

If a FIDO2 registration or authentication failed because no matching policy was found, i.e., policy validation failed, OneSpan Cloud Authentication used to return the generic 400 Data validation failed message. This has been improved and if policy validation fails now, a 409 HTTP status code with more precise information, for instance Authenticator was rejected by a policy, is returned.

Occasionally OneSpan Cloud Authentication ran into timeouts in different operations. These timeouts were related to the Audit Logger service which had issues to connect with Amazon MQ broker. This only happened during the maintenance window of the broker.

Status: This issue has been fixed with the implementation of Amazon SQS (see also above). Messages are now queued without a broker for audit logging.

Description: When you deleted an authenticator license or authenticator instance, the operation was not shown in the recent activity of the user to whom the authenticator was assigned.>

Status: This issue has been fixed.

Description: Some potential issues related to restricting authenticators via policy were detected:

• The verification against the list of applicable authenticator applications was inaccurate in the sense that authenticator application names could incorrectly be accepted if they evaluated partial names allowed by the policy. For instance, if the policy allowed VOTP64, an authenticator application named OTP6 would incorrectly be accepted.

  This issue applied to restrictions on authenticator application names and on authenticator types.

• The tracing message for a policy disallowing an authenticator application based on the application name was incorrect.

• If a response was verified to synchronize the offline authentication data state, the restriction by the policy was not correctly evaluated.

Status: These issues have been fixed.

Description: Encoding the signature request failed when the message title and/or data fields contained special characters, such as Eastern European characters. This request failed because the policy's font table index was ignored. Any attempt of the client to decrypt the request failed with an error.

Status: This issue has been fixed.

The response and error codes for the /users/{userID@domain}/login endpoint have been added to the documentation. For more information, see User Login Error Messages.

Description: An issue was detected when assigning an authenticator with the Assign DIGIPASS wizard via the Administration Web Interface of the Authentication component for OneSpan Cloud Authentication. When you wanted to assign an authenticator to a user via this wizard and selected the Search now to select DIGIPASS to assign option, the Select DIGIPASS page also incorrectly listed authenticators that had already been assigned to a user. If you selected such an authenticator, the Authentication component displayed an error message when you attempted to complete the wizard.

Status: This issue has been fixed.

The OneSpan Trusted Identity platform API has maintained the deprecated RegisterUserInput and RegisterUserOutput payloads for the POST /users/register endpoint. These payloads and the microservice that was handling them, irm_macroservices_userregisterv2 have now been removed from the API.

Description: An connection issue to the DynamoDB database and a long timeout span of the database caused an error during user registration.

Status: This issue has been fixed. The timeout value has been decreased, and logging has been adapted to receive information for all affected web services.

Description: For a login request with one-time password (OTP), the Authentication component checked all authenticators and applications. Amongst other issues, this approach carried the risk that a wrong application (type) would tackle the login request.

Status: This issue has been fixed. The TID Challenge-Response Authentication policy has been modified to explicitly allow only the Challenge/Response application type.

Until now, when checking the logs, it was a very time-consuming process to obtain information about which mobile operating system and version was used and which version of the Orchestration SDK were used.

Status: This issue has been fixed. Additional fields for the used platform and version and for the version of the Orchestration SDK have been added to the logging system. The logs can now also be filtered separately for these fields.

Description: When the policy of a client was changed with the corresponding checkbox and the Change button, the action failed with the message that the client policy was not valid. A workaround was to open the client component itself and change the policy there.

Status: This issue has been fixed.

For a detailed list of fixed vulnerabilities, see the relevant Knowledge Base article(s) in our Customer Support Portal.

The POST /users/{userID@domain}/transactions/validate endpoint returns an incorrect error message if the transaction amount field is provided from the data type number, and if the transaction amount is large. In this case, the endpoint should return the error message "Invalid value type", because the transaction amount field was provided as a number and not as a String. Instead, it returns the incorrect error message "Amount: Value must follow -^-?[0-9]{1,20}(\\.[0-9]{1,3})?$,".

Solution: The transaction amount fields in the request body of the transactions/validate endpoint need to be provided as a String. Ensure that the value in the JSON request body is wrapped in double quotes.