FIDO2 in the Production environment

Overview of the Production environment

A typical FIDO2 deployment for the Production environment involves the following parties:

  • Client infrastructure. This includes the platform and cross-platform authenticators, as well as the web browser(with WebAuthN support). By default, OneSpan supports the FIDO2 authenticators which are part of the FIDO Alliance Metadata Service version 3.0.
  • Relying Party Service. This is the web server application which provides the registration and authentication features. Its back end communicates via a secure connection (TLS certificates) with the OneSpan Trusted Identity platform API. The Relying Party Service hosts
  • OneSpan Trusted Identity platform API. This REST API exposes the FIDO2 Server functionality via dedicated FIDO endpoints that are available in Intelligent Adaptive Authentication.

For more information about FIDO concepts, refer to the specifications and technical glossary provided by the FIDO Alliance.

Configuring FIDO2 in the Production environment

To enable the integration of FIDO2-based functionalities with Intelligent Adaptive Authentication for the Production environment, the following information must be provided to properly configure FIDO2:

  • Tenant name
  • URL of your web application
  • (If required) Metadata statements

To enable FIDO2 for the Production environment, submit a support ticket on the Product Support page by clicking the SUBMIT A SERVICE REQUEST button.

Tenant name

Ensure that you have already created a tenant. To enable FIDO2, provide the tenant name to OneSpan support—our support staff will activate FIDO2 for you.

To demonstrate the onboarding steps, the name example-tenant is used in the steps describing the procedure.

Web application URL

Provide the URL of your web application that will be used to perform the FIDO2 ceremonies (registration and authentication). Based on the provided URL OneSpan deduces the Relying Party IDClosed A relying party identifier is a valid domain string identifying the Relying Party on whose behalf a given registration or authentication ceremony is being performed. As the registration ceremony is generating credentials on the client side (authenticator) these are scoped to the Relying Party that was conducting the registration ceremony. and the OriginsClosed An origin indicates where a request originated from. An origin should not include any path information, and it should use the https protocol. and configures the FIDO2 Server accordingly.

Examples of valid configurations for the Relying Party ID and Origins are:

  • RP ID:
  • Origins=

Relying Party ID

To demonstrate how the Relying Party ID can be retrieved, the following URLs are used as examples:


The Relying Party ID can be extracted from your web application URL. To obtain the domain, remove the protocol and the paths from the URL. This domain can be used as the Relying Party ID.

Extracting the Relying Party ID
Protocol Domain Path
https:// /register

In addition to the Relying Party ID extracted above, another valid Relying Party ID can be deduced, with a more generic structure as it only includes the domain, i.e. The following table lists examples of extracted valid Relying Party IDs.

Examples of valid Relying Party IDs
# Valid Relying Party ID Invalid Relying Party ID

The advantage of using the more generic Relying Party ID ( is that this allows you to use the same Relying Party ID with multiple websites. These can be hosted under the subdomains of



To avoid phishing attacks, FIDO2 has important checks on the client side, where the client verifies that the Relying Party ID matches the origin. If there is a mismatch, the request will be rejected.

The Relying Party ID and the origin are part of a client structure (clientData) which is hashed and signed by the authenticator and validated again on the FIDO2 Server side. Here, the origin from the clientData is checked against the set of Origins defined during the Relying Party configuration phase. The set of Origins needs to be collected so that the Origins can be properly configured on the FIDO2 Server.

The set of Origins must include the same domain that has been defined in the Relying Party ID.

The following table contains valid Origins examples for the valid Relying Party IDs defined above:

Examples of valid Origins
# Relying Party ID Valid Origins

For the Relying Party ID, two valid origins are available as part of the set of Origins. Note that port numbers are also valid and can be included as part of an origin.

Metadata statements

The FIDO2 Server works out-of-the-box with a list of supported FIDO2 authenticators which are part of the FIDO Alliance Metadata Service version 3.0.

If you intend to use authenticators that are not included in the FIDO Alliance Metadata Service, ensure that you provide the relevant metadata statements to OneSpan in the v3 format.

For more information about FIDO2 authenticators supported by the FIDO Alliance Metadata Service, see FIDO2-supported authenticators.

Next steps

With this, FIDO2 is enabled and you are ready to use the supported FIDO2 operations. For more information on these operations, see the following articles: