FIDO authentication release notes

26.2.0

What's new?

• Device-Bound Key (DBK) support: A new Thales FIDO extension (thalesgroup_dbk_ext) allows hardware-backed cryptographic keys to be associated with FIDO credentials. DBKs can be created during registration and used during authentication, providing an additional layer of device-level security.

You can view and manage DBK bindings through the Authenticator Admin API. A new endpoint, DELETE /authenticators/{credId}/dbk/{dbkKid}, allows you to remove a specific DBK binding without deleting the authenticator.

Authenticator policies can also enforce DBK usage with deviceType: ["device-binding"] and limit the number of DBKs that can be associated with an authenticator.

• Authenticator lockout policies: Authenticator policies now support lockout configuration. You can configure the system to automatically lock an authenticator after a specified number of failed authentication attempts within a defined time window, and set the lockout duration. When multiple policies are applied with authenticatorLockout, the first policy's lockout settings are used. You can check lockout status through the authenticator admin API.

• API and policy refinements: The deprecated username query parameter has been removed from the assertion (authentication) API — use userId for user identification (the username field remains required in attestation/registration). The maximum number of policies per assertion options request is now server-configurable (default remains 1).

• FIDO2 Web SDK: A new browser-only JavaScript SDK, idc-fido2-web-js-lib-bundle.js, is now available for web integrators. It simplifies FIDO2 integration by handling WebAuthn API calls, Device-Bound Key (DBK) management, and FIDO2 Server format conversions.

This release includes the following enhancements:

• getDeviceBoundKeyId() now returns a dbkExist flag along with dbkKid, allowing integrators to check whether a DBK exists before initiating authentication.
• registerDeviceBoundCredential() now supports an optional onFallbackConfirmation callback, allowing integrators to replace the default browser confirmation dialog with a custom UI.

For more information, see the Web SDK documentation.

Improvements and fixes

This release includes new policy samples for device binding and lockout configurations. It also provides performance improvements for user searches with date-range filters by using query index hints for tighter time ranges.

Additional improvements include more accurate DBK clientType evaluation against the policy deviceType, database type alignment fixes, and general dependency upgrades.

25.3.0

What's new?

• Tenant delete management: Admins can now remove a tenant via lifecycle APIs with guardrails (validation, soft-lock window) and full audit coverage to prevent accidental or partial deletion.

• FIDO API availability: FIDO authentication APIs are now exposed in the OneWelcome Identity Platform (OIP), making it easier to integrate FIDO flows alongside your existing OIP services and credentials management.

Improvements and fixes

This release also includes general improvements and defect fixes that enhance logging, audit robustness, and configuration safety.

25.2.0

What's new?

This release delivers key enhancements to tenant and user lifecycle workflows. From streamlined tenant creation and updates to proper user data cleanup on deletion, these features help organizations manage identities more efficiently and securely.

• Tenant lifecycle: Support for tenant lifecycle management is now available, enabling API-based creation and updates of tenant records. This simplifies onboarding and configuration changes in multi-tenant environments.

• User lifecycle: In addition, user deletion lifecycle management is now available. When users are removed, associated data is properly cleaned up, helping you stay compliant with retention and privacy requirements.

25.1.0

What's new?

This release brings two key improvements: FIDO authentication policies for enhanced security compliance, and multi-user push notifications to ensure personalized notifications on shared devices.

• FIDO authentication policies: Administrators can now define and enforce FIDO authentication policies to ensure compliance with security standards, offering granular control over which operations or accesses are allowed.

• Multi-user push notifications: Users with different accounts on the same mobile device will now support receiving push notifications respectively without conflict.