OneSpan Cloud Authentication December Release – 25.R3

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.

In version 26.R1, OneSpan Cloud Authentication will provide Asynchronous Push Notification, accelerating Push Notification workflows. With this, the asynchronous delivery of push notifications will be enabled globally, i.e. for all customers, by default. This is not a breaking change as it does not entail changes in the API integration; however, in some cases, the detection of failed push notification deliveries will change.

Affected endpoints

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

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

• POST /users/{userID@domain}/send-push-notification

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

Current behavior

When a request that is sent to any of these endpoints immediately causes the push notification delivery to fail with the push notification provider (Google, Apple), the failure state is communicated directly with the request response (HTTP status code 409 and generic error message). The causes of these immediate failures include, for instance, invalid configuration data or credentials, the mobile app no longer being registered with the provider, unavailability of provider etc.

Other failures can prevent push delivery at a later stage, e.g. the mobile phone not being available, but these failures are no longer visible on the TID Platform API.)

Future behavior

As of version 26.R1, this type of failure will no longer trigger the 409 response to the initiating request. Instead, all push notification requests will be initially accepted for asynchronous processing. The actual status and result of the push notification delivery will be available via the GET /sessions/{requestID} endpoint, which will contain a new list of events, with one entry per notified mobile app, identified by the device PNID. The possible status values for each push notification will be Queued, Processing, Sent, and Failed.

If you are currently relying on specifically detecting push delivery failure in the response to the initial request, you will not be able to detect these failures anymore as of version 26.R1. The reason is that the requests will typically result in the creation of a pending session and generation of a requestID value which is the same behavior as that for successful requests. Detecting and evaluating failures of push notification delivery will only be possible by parsing the output of the GET /sessions/{requestID} endpoint.

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.

With the FIDO UAF Self-Service Onboarding feature, you can now configure FIDO UAF by using the OneSpan Trusted Identity platform REST API endpoints for managing Relying Party Resources. In addition, you can enable FIDO UAF-based functionalities with OneSpan Cloud Authentication for the Sandbox and Production environments. To use UAF, you need at least one match criteria, one policy which regulates what is allowed or disallowed, and one relying party. These can be created and managed with the endpoints listed below. For more details about endpoint payloads, mandatory input, and possible responses, refer to the Interactive API Reference.

• POST /uaf-authenticator-types

  For more information about match criteria and available endpoints, see Manage FIDO UAF authenticator types.

• POST /uaf-policies

  For more information about the FIDO UAF policies and available endpoints, see Manage FIDO UAF policies.

• POST /uaf-relying-parties

  For more information about relying party resources and available endpoints, see Manage FIDO UAF Relying Party resources.

Once you created all necessary components, your web application is ready to use the supported FIDO UAF-based operations with OneSpan Cloud Authentication.

With FIDO2 it is possible to log in to a system without a user name by means of Discoverable Credentials. With these, the client system detects available FIDO2 passkeys, extracts the user name out of these credentials, and prompts the user to log in. Discoverable credentials make the login process more seamless as the user does not have to type in their user name. This feature has been added to OneSpan Cloud Authentication, and the following endpoints have been added:

• Generate authentication request for the requested FIDO protocol. Generate an authentication request without user name by calling the following endpoint:

  POST users/generate-fido-authentication-request-usernameless

  This endpoint accepts userVerification as payload.

  The responses for this endpoint include the following:

  • 200: Authentication request generated.

  • 400: The input is invalid.

  • 500: Internal error, sub service failure, server crash.

• User login without user name. Enable the user to login without having to enter their user name by calling the following endpoint:

  POST users/fido-login-usernameless

  This endpoint accepts the following parameters as payload:

  • authenticationResponse

  • objectType

  • requestID

  • tokenBinding

  The responses for this endpoint include the following:

  • 200: Login request successful.

  • 403: The command is prohibited for the tenant administrator account.

  • 409: Failed to log in user.

  • 500: Internal error, sub service failure, server crash.

For more information, see FIDO-based user login without user name: discoverable credentials.

You can now disallow the usage of an authenticator for instance while it is being sent to the user, or while a user, who should have an authenticator that is marked as lost, is being tracked. You can also limit the usage duration so the authenticator can be replaced before its battery is empty.

• Set validity time attributes for an authenticator. To disallow usage or limit usage duration for an authenticator, set dates for the start of its validity and when it expires by calling the following endpoint:

  PATCH /authenticators/{serialNumber}

  The endpoint accepts startTime and expirationTime as payload.

• Query OneSpan Cloud Authentication. To view authenticators with disallowed usage or limited usage duration, call the following endpoint:

  GET /authenticators/{serialNumber}

  The response now includes the start time and expiration time of the authenticator validity.

OneSpan Cloud Authentication now provides the possibility to disable the synchronization window for software authenticators via policy settings.

For new customers, this functionality will be enabled by default. For existing customers OneSpan Support will enable it upon request.

OneSpan Cloud Authentication now supports sending FIDO authentication requests as Secure Challenge for orchestration, combining regular authenticators and FIDO.

The POST /users/{userID@domain}/generate-secure-challenge endpoint has been extended to raise the character limit in the Secure Messaging service from 350 to 500. And if the text string is too long, OneSpan Cloud Authentication now also sends a more meaningful error message, instead of status code 500, it sends status code 400: The input is invalid. Input string is too long.

The performance and reliability of OneSpan Cloud Authentication have been improved by introducing auto-scaling for web services. This feature allows the system to dynamically adjust computing resources in response to real-time traffic. As a result, it optimizes resource usage and enhances system stability under heavy load.

By introducing retry mechanisms, there is no longer any service downtime during a database and/or database cluster failover operation. With the new mechanisms, OneSpan Cloud Authentication retries the relevant database operation when the database is in failover status.

Description: In the Integration Guide, the description for the self-serviced onboarding procedure was missing.

Status: This issue has been fixed. The description has been added again.

Description: The FIDO UAF signature counter indicates how many times an authenticator has performed signatures in the past. It is validated by the server when receiving authentication requests to verify that the authenticator's use counter has not been tampered with, preventing replay attacks by ensuring a signature is new.

For certain devices, OneSpan Cloud Authentication denied the authentication response with the [Assertion_Verification_Error] Invalid signature counter error. Analysis showed that the error occurred when OneSpan Cloud Authentication did not receive a mobile authentication response, e.g., because of network issues. The reason for this was that the sign counter validation enforced a strict increment by 1: “client counter = server counter + 1” which does not allow lost responses.

Status: This issue has been fixed. The sign counter validation has been relaxed and verifies whether the signature counter has incremented, but not necessarily by exactly 1.

Description: When a user unsuccessfully attempted to authenticate often enough to trigger the failed authentication attempts threshold, OneSpan Cloud Authentication locked the account and returned the 409 User account is locked response. The user as not able to generate a challenge and unlock their account again. The issue was that OneSpan Cloud Authentication applied the user locked-check also to generate challenge-operations via the POST /users/ {userID@domain}/generate-challenge endpoint.

Status: This issue has been fixed. The check if the user is locked has been removed from generate challenge-operations.

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.

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.