PingAM Auth node reference

Device Signing Verifier node

The Device Signing Verifier node verifies possession of a registered bound device.

What are the differences between device binding/signing and WebAuthn?

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 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

SafetyNet

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.

The node requires the device to sign a challenge string using the private key that corresponds to a stored public key.

The user might need to unlock their cryptography keys with biometric security — such as a fingerprint — or a PIN.

This node can be used in usernameless authentication flows.

The Ping SDKs store and provide the identity when handling the callbacks from this node. If the device has been registered by more than one user, the SDK displays a list of the registered keys to choose from on the client device.

Learn more about using this node with the Ping SDKs for Android and iOS in Implement device binding.

Example

This example demonstrates using the Device Signing Verifier node to perform multi-factor authentication (MFA) after a user has authenticated with their username and password.

Device signing verifier MFA journey

  • The Page node containing the Platform Username node and Platform Password node prompts for credentials.

  • The Data Store Decision node validates the username-password credentials.

  • The Device Signing Verifier node challenges the user to prove possession of a bound device. The user must unlock the private key on their device, for example, by using biometrics.

    • If the user successfully signs the challenge, evaluation continues along the Success outcome path, and the user is authenticated.

    • If the user fails to sign the challenge, evaluation continues along the Failure outcome path.

    • If the user has no devices registered, evaluation continues along the No Registered Device outcome path. This path could lead to a device registration flow using the Device Binding node.

Availability

Product Available?

PingOne Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

If you want the device to sign a custom challenge, its value must be available in shared state. Enter the variable name in the Shared state attribute for Challenge property.

Dependencies

This node requires that you have bound devices using the Device Binding node.

Configuration

Property Usage

Sign Random Challenge

Select this option to use a random value as the challenge for signing.

Shared state attribute for Challenge

Use the value from the named attribute in shared state as the challenge for signing.

Application IDs

The Android package names and iOS bundle IDs of applications that are allowed to perform device binding.

For example, com.example.app.

Title

(Optional) Add a title to display to the user when asking them to bind the device.

Add instructions

  1. Click .

  2. In the Key field, enter the locale. For example, en-gb.(1)

  3. In the Value field, enter the message.

  4. Click Done.

  5. Repeat to add more messages and save your changes when you’re done.

Leave blank to use the default message.(2)

Subtitle

(Optional) Add a subtitle to display to the user when asking them to bind the device.

Add instructions

  1. Click .

  2. In the Key field, enter the locale. For example, en-gb.(1)

  3. In the Value field, enter the message.

  4. Click Done.

  5. Repeat to add more messages and save your changes when you’re done.

Leave blank to use the default message.(2)

Description

(Optional) Add descriptive text to display to the user when asking them to bind the device.

Add instructions

  1. Click .

  2. In the Key field, enter the locale. For example, en-gb.(1)

  3. In the Value field, enter the message.

  4. Click Done.

  5. Repeat to add more messages and save your changes when you’re done.

Leave blank to use the default message.(2)

Timeout

The number of seconds to wait for a response from the client during binding.

If the specified time is reached, evaluation continues along the Timeout outcome path.

Capture Failure

Select this option to add the failure reason to the shared state variable DeviceSigningVerifierNode.FAILURE and continue evaluation along the Failure outcome path.

If not enabled, the journey halts with an exception, and the journey does not continue along an outcome path.

Reasons for failure include:

INVALID_CLAIM

Failed to validate one or more claims presented in the token.

For example, the challenge claim didn’t match the value set in the node configuration, or the issuer (ISS) claim didn’t match a value in the Application IDs list.

INVALID_SIGNATURE

Failed to validate the token signature.

INVALID_USER

Account doesn’t exist.

NOT_ACTIVE_USER

Account isn’t active or locked out.

INVALID_SUBJECT

Failed to validate the token subject.

Client Error Outcomes

The client error outcomes available to this node. Find more information in Error handling.

(1) Specify a locale that Java supports, such as en-gb. Otherwise, the node throws a configuration exception with an Invalid locale provided message.

(2) Learn more about customizing and translating default messages in Internationalize nodes.

Outputs

If you enable the Capture Failure property, the node outputs a failure reason string in a variable named DeviceSigningVerifierNode.FAILURE.

Callbacks

The node sends a DeviceSigningVerifierCallback to request that the device sign the challenge using the stored private key. Learn more in DeviceSigningVerifierCallback.

Outcomes

Success

The response from the device is verified as coming from a bound device.

Failure

The node can’t verify that the response was signed by a bound device.

No Registered Device

The user doesn’t have any bound devices. The user is determined either previously in the authentication journey, or by reading the sub claim from the response when doing usernameless flows.

Key not found

The client device can’t access the cryptography keys, or the key ID that AM requested can’t be located.

Unsupported

This outcome is available only if listed in the Client Error Outcomes property.

The user’s client doesn’t support the requested operation. For example, the node is configured to require biometric authentication, but the device doesn’t provide support.

Abort

This outcome is available only if listed in the Client Error Outcomes property.

The user cancels authentication.

Timeout

This outcome is available only if listed in the Client Error Outcomes property.

The node doesn’t receive a response from the user’s device within the Timeout specified in the node configuration.

ClientNotRegistered

This outcome is available only if listed in the Client Error Outcomes property.

The client device doesn’t have the keys present to be able to sign the challenge.

Errors

The node can log the following warnings:

  • Device Signing failed

    The node encountered an error while processing or verifying the signed data from the device.