Skip to main content

FIDO2 Settings

A La Mode

FIDO Settings can be configured from more than one mode in Control Center:

  • In Standard Mode: Control Center Settings under the FIDO2 Settings tab
  • In Advanced Mode: Advanced Config: FIDO2 Settings for the Application selected under Choose an App
API Calls

FIDO2 Settings, including enabling and disabling individual AAGUIDs, can be administered via these APIs contained in the HYPR Passwordless API.

FIDO2 registration, authentication, and deregistration calls, including out-of-band (OOB) calls, can be found in the FIDO2 RP API.

FIDO2 is a set of standards defining the use of mechanisms such as security keys and biometric recognition in multi-factor authentication. By default, the only mechanism administrators can choose for logging into the HYPR Control Center is a mobile device. If you would like them to be able to log in with a security key, FIDO2-enabled smart-card, or through biometric recognition on their computer (Touch ID for Mac or Windows Hello, for example), you must enable FIDO2 authentication for the Control Center.

FIDO2 and HYPR Integrations

Some Integrations may include FIDO2 settings separate from those in HYPR Application settings. Integration FIDO2 Settings function identically to Control Center FIDO2 Settings.

  1. In the Control Center, click Control Center Settings in the left navigation pane.

  2. Go to the FIDO2 Settings tab.

  3. Slide the Enable Fido2 button to the On position. The following fields become active.

    • Client Origin URL
      The original URL at the time of registration plus any (comma-separated) additional Android Package Key (APK) hash keys; used to first to register and later to validate future authentication requests. This URL is entered automatically as part of the HYPR onboarding setup, so you typically don’t need to edit it. If you decide to change it, the URL value must be all lowercase. If users are unable to pair FIDO2-based devices successfully, check this URL does not contain any uppercase characters.

      For additional information on generating APK hashes, see this article.

      Example
      https://fido2.highlandsbank.com[,android:apk-key-hash:<hash_string>,android:apk-key-hash:<hash_string>,...]

    • Discoverable Credentials
      Required: The Relying Party requires a client-side discoverable credential
      Preferred: The Relying Party strongly prefers creating a client-side discoverable credential, but will accept a server-side credential
      Discouraged: The Relying Party prefers creating a server-side credential, but will accept a client-side discoverable credential

    • User Verification Mode
      Required: The Relying Party requires user verification for the operation and will fail if the response does not have the user verification flag set
      Preferred: The Relying Party prefers user verification for the operation if possible, but will not fail the operation if the response does not have the user verification flag set
      Discouraged: The Relying Party does not want user verification

    • Attestation Type
      Direct: The Relying Party wants to receive an attestation statement that may include uniquely identifying information
      Indirect: This indicates that the Relying Party wants to receive the attestation statement as generated by the authenticator
      None: This indicates that the Relying Party is not interested in authenticator attestation

    • Attestation Timeout
      Time, in milliseconds, that the Relying Party is willing to wait for the attestation call to complete. The value is treated as a hint, and may be overridden by the browser. Minimum value is 30000 milliseconds.

    • Assertion Timeout
      Time, in milliseconds, that the Relying Party is willing to wait for the assertion call to complete. The value is treated as a hint, and may be overridden by the browser. Minimum value is 30000 milliseconds.

    • FIDO2 Enforced Settings Toggle the desired allowances for the application in question (when making changes in Control Center, the application will default to Control Center Admin). Using this functionality assumes you have appropriately configured FIDO2 policies.

      • Allow Synced Passkeys

        • Enabled by default

        • Enables passkeys consisting of multiple devices

        • If disabled, only one device will be allowed per user with the affected application

        • Keycloak web logins will not work with synced passkeys

      • Allow None Attestation

        • Enabled by default

        • Users can register a passkey with no attestation

      • Allow Self Attestation

        • Enabled by default

        • Users can register a self-attesting passkey

      • Allow Untrusted Attestation (not recommended)

        • Disabled by default

        • Users can register passkeys with no root of trust

  4. Once the fields and toggles are set to your satisfaction, click Save.

Users will now have the option to register and use passkeys (including the HYPR Enterprise Passkey) and built-in computer biometric devices according to the limitations you configured here.

FIDO2 RP API​

All of the above settings can also be managed with the HYPR API. See the section FIDO2 RP API for descriptions of the calls.

FIDO2/WebAuthn-related service errors in HYPR fall in the 1203xxx range. Error 1203012 is associated specifically with FIDO2 policy behaviors in HYPR.

Failing to meet FIDO2 policy requirements will log an Audit Trail Event for the Application in question: FIDO2_DEVICE_REG_COMPLETE. See Event Descriptions for a full list of HYPR Events.

See also Log Monitoring Best Practices.