Ping SDKs

Web biometrics

Applies to:

  • Ping SDK for Android

  • Ping SDK for iOS

  • Ping SDK for JavaScript

What are web biometrics?

Web biometrics let users authenticate by using an authenticator device. For example:

  • The fingerprint scanner on a laptop or phone.

  • Face ID.

Communication with the authentication devices is handled by the SDK. You can configure the nodes in PingAM to request that the SDK activates authenticators with certain criteria. For example, the authenticator can be:

  • Built into the platform.

  • A cross-platform USB device.

  • Bluetooth.

  • NFC.

You can also configure PingAM to request that the device verify the identity of the user, or that a user is present.

To use web biometrics, users must first register their authenticators. If recovery codes are enabled, users must also make a copy of their codes.

Registration involves the selected authenticator creating or minting, a key pair. The key pair is specific to the origin of the site that uses it. This helps fight against phishing attacks.

The public key of the pair is sent to PingAM and stored in the user’s profile. The private key is stored securely, either in the authenticator itself or in the platform managing the authenticators. The private key does not leave the client at any time.

When authenticating using web biometrics, PingAM sends a challenge to the authenticator, expecting it to use this challenge to create a signed assertion with its stored, private key.

The assertion is then sent to PingAM for verification using the public key stored in the user’s profile. If the data is verified as being from the correct device, and passes any attestation checks, the authentication is successful.

Differences between web biometrics and device binding

There are many similarities between WebAuthn and Device Binding and JWS verification. We provide authentication nodes to implement both technologies in your journeys.

Both can be used for usernameless and passwordless authentication, they both use public key cryptography, and both can be used as part of a multi-factor authentication journey.

One major difference is that with device binding, the private key never leaves the device.

With WebAuthn, there is a possibility that the private key is synchronized across client devices because of Passkey support, which may be undesirable for your organization.

For more details of the differences, refer to the following table:

Comparison of WebAuthn and Device Binding/JWS Verification
Feature WebAuthn / FIDO Device Binding / JWS Verifier Details

Industry-standards based

✅

❌

You can refer to the WebAuthn W3C specification.

Device binding and JWS verification are proprietary implementations.

Public key cryptography

✅

✅

Both methods use Public key cryptography.

Usernameless support

✅

✅

After registration, the username can be stored in the device and obtained during authentication without the user having to enter their credentials.

Keys are bound to the device

❌

✅

With WebAuthn, if Passkeys are used, they can be shared across devices.

With device binding, the private keys do not leave the device.

Sign custom data

❌

✅

With device binding, you can:

  • Customize the challenge that the device must sign. For example, you could include details of a transaction, such as the amount in dollars.

  • Add custom claims to the payload when signing a challenge. This gives additional context that the server can make use of by using a scripted node.

    Refer to Add custom claims when signing.

Format of signed data

WebAuthn authenticator data

JSON Web Signature (JWS)

Integration

❌

✅

With device binding, after verification, the signed JWT is available in:

  • Audit Logs

  • Transient node state

This enables the data within to be used for integration into your processes and business logic.

Platform support

✅ Android

✅ iOS

✅ Web browsers

✅ Android

✅ iOS

❌ Web browsers

As it is challenging to store secure data in a browser as a client app, device binding is not supported in web browsers.

Authenticator support

Determined by the platform.

Configuration limited to:

  • Biometric with Fallback to Device Pin

Determined by the authentication node.

Full configuration options:

  • Biometric Authentication

  • Biometric with Fallback to Device Pin

  • Application Pin

  • Silent

With device binding, you can specify what authentication action the user must perform to get access to the private keys.

This provides greater flexibility in your security implementation and can reduce authentication friction for your users.

Key storage

Web browsers and iOS synchronize to the cloud.

Android has the option to synchronize to the cloud.
Android

KeyStore

iOS

Secure enclave: hardware-backed and not synchronized to the cloud.

Both technologies store the private keys securely on the client.

WebAuthn supports synchronizing the private keys to the cloud for use on other devices.

This can reduce authentication friction for your users but may also increase the risk of a breach.

Managing device keys

Managed by the device OS.

Apps cannot delete local client keys programmatically and do not have a reference to the remote server key for deletion.

Managed by the Ping SDKs.

Provides an interface to delete local client and remote server keys.

The ability to programmatically delete both client and server keys can greatly simplify the process of registering a new device if an old device is lost or stolen.

Passkey Support

✅

❌

WebAuthn supports synchronizing the private keys to the cloud for use on other devices.

Device binding keeps the private key locked in the device.

App integrity verification
Android

Requires an assetlinks.json file.

iOS

Requires apple-app-site-association file.

Not provided by the device binding or verification nodes.

It can be added as part of the journey by using app integrity nodes.

App integrity verification helps ensure your users are only using a supported app rather than a third-party or potentially malicious version.

Key attestation
Android

SafteyNet

iOS

None
Android

Uses hardware-backed key pairs with Key Attestation.

iOS

It can be added as part of the journey by using app integrity nodes to support key attestation.

Key attestation verifies that the private key is valid and correct, is not forged, and was not created in an insecure manner.

Complexity

Medium

Low

WebAuthn requires a bit more configuration, for example, creating and uploading the assetlinks.json and apple-app-site-association files.

Device binding only requires the journey and the SDK built into your app.

Before using web biometrics

  • The device must have a biometric (platform) authenticator.

  • The OS must provide access to the platform authenticator via the API.

  • The browser must support WebAuthn capabilities, and support the OS’s platform authenticator’s API.

If any of the above prerequisites is missing, web biometrics will not work.

For more information on support in PingAM, see Minimum Web Authentication User Agent Versions in the PingAM documentation.