- 17 Jan 2025
- 1 Minute à lire
- SombreLumière
- PDF
Integration considerations
- Mis à jour le 17 Jan 2025
- 1 Minute à lire
- SombreLumière
- PDF
The OneSpan FIDO2 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
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.
The FIDO2 SDK also supports the Token Binding mechanism, which is another layer of protection against MITM and replay attacks. However, to work properly, this feature needs to be supported by the client, the authenticator, and the server at the same time.
The FIDO2 SDK does not support any storage or deregistration mechanism on its own, or suggest an interface to implement one. Therefore, any application that wants to use the authentication functionality of OneSpan FIDO2 SDK has to provide some kind of storage (for both the temporary session and the permanent session), together with methods to manage that data and save the resulting credentials received from the SDK.