Integration considerations

The OneSpan FIDO UAF SDK contains many features, not all of which may be applicable to your specific use case. The SDK has been designed to offer you functionalities that are scalable to the needs of your organization. The following articles provide information on considerations when integrating the SDK.

Challenge replay attacks

The OneSpan FIDO UAF SDK does not provide replay attack security by itself, but facilitates the implementation of protection against such attacks if required.

From a high-level perspective, when implementing the SDK-based logic, the registration and authentication requests (first incoming messages) must be correlated with their corresponding responses (second incoming messages). However, this is not enough to resist replay attacks. Only one response should be expected for a given request, and therefore a mechanism must be implemented to reject second incoming messages that have already been handled once. Additionally, a good practice is to reject second messages after a certain amount of time (process timeout), and always reject incoming second messages that are unrelated to any process initiated by the first message.

One possible approach to successfully challenge a replay attack is to use a JWT Token, which allows you to set its expiry date, append some identification data that can be used to correlate the messages, and sign everything with a cryptographic algorithm to secure data and prevent it from being easily manipulated. This identification data must also be preserved, either in the server memory (not recommended), or any kind of database. This JWT Token can be sent in UAF messages in the serverData field, a designated field for passing data relevant only to the server. Therefore, the JWT token should be generated after the request message, and it should be appended as server data in the response to that message. Ultimately, the second message from the client should contain that token within its [registration/authentication]Response object. At this point, it should be verified that the token was registered or has expired. Finally, identification data from that token should be validated against another token stored by the server.