Skip to main content

Prove Unified Authentication solution

Prove Unified Authentication simplifies and strengthens your authentication security by automatically choosing the right authenticator based on trusted device recognition and authenticator availability—reducing friction while protecting against fraud.

Concepts and definitions

  • Prove Key: Non extractable cryptographic key used for verification by Prove.
  • Bind: Establishes possession of the phone number to register the Prove Key.
  • Customer-Initiated Bind: Registry of a Prove Key based on customer-supplied possession of the phone number.
  • Device Context: Browser fingerprinting technology that helps recover device registration when the Prove Key is unavailable, eliminating the need for SMS OTP or Instant Link re-authentication.

Methods of integration

You can integrate Prove Unified Authentication in a way that best suits your business needs.

Prove’s possession flow

The scope of this feature is mobile and desktop channels using the Prove Key and Prove’s possession checks.
1

Unify Call

The Unify call generates the OAuth token, initiates the session, and accepts the phone number input.
2

Client-Side SDK

The client-side SDK initiates the authentication.
  • Mobile Channels: Checks for a bound Prove Key first. If one isn’t present, it falls back to SMS OTP and places the Prove Key.
  • Desktop Channels: Uses Instant Link for the possession check.
3

Unify Status Call

The Unify Status call results indicate whether authentication passed or failed. success=true indicates either the customer passed the possession check and completed the bind or authenticated using the Prove Key.
4

Subsequent Authentication

If authentication passed, this customer is eligible to authenticate using the Prove Key on future authentications.
Diagram illustrating Prove's unified authentication possession flow
1

Unify Call

The Unify call generates the OAuth token, initiates the session, and accepts the phone number input.
2

Client-Side SDK

The client-side SDK initiates the authentication.
  • Mobile Channels: Checks for a bound Prove Key first. If one isn’t present, it falls back to Mobile Auth, followed by SMS OTP, and places the Prove Key. This key isn’t bound until the Unify Status call.
  • Desktop Channels: Uses Instant Link for the possession check.
3

Unify Status Call

The Unify Status call results indicate whether authentication passed or failed. success=true indicates either the customer passed the possession check and completed the bind or authenticated using the Prove Key.
4

Subsequent Authentication

If authentication passed, this customer is eligible to authenticate using the Prove Key on future authentications.

Customer-supplied possession with force bind

The scope of this feature is mobile channels using Prove Key and your fallback possession vendor.
Diagram illustrating the Unify flow using customer-supplied possession
1

Unify Call

The Unifycall with possessionType=none initiates the session and accepts the phone number input.
2

Client-Side SDK

The client-side SDKinitiates the authentication. It checks for a bound Prove Key first, then places the Prove Key if not already present. This key isn’t bound until the Unify Bind call.
3

Unify Status Call (First)

The Unify Statuscall either indicates the customer authenticated using the Prove Key or that possession is required.
4

Customer Possession Check

If Prove couldn’t authenticate the customer using the Prove Key, your app needs to perform a customer-supplied possession check such as SMS OTP. If the customer passes the possession check, proceed to the Unify bind step.
5

Unify Bind Call

The Unify Bindcall completes the customer-initiated bind registering the Prove Key.
6

Subsequent Authentication

This consumer authenticates using the Prove Key.

Prove passive authentication with customer-supplied possession fallback

The scope of this feature is mobile channels using Prove Key, Mobile Auth, and your fallback possession vendor.
Diagram illustrating the Unify flow using customer-supplied possession
1

Unify Call

The Unifycall generates the OAuth token, initiates the session, and accepts the phone number input.
2

Client-Side SDK

The client-side SDKinitiates the authentication.
  • Mobile Channels: Checks for a bound Prove Key first. If one isn’t present, it falls back to Mobile Auth and places the Prove Key. This key isn’t bound until the Unify Status/Bind call.
3

Unify Status Call

The Unify Statuscall results indicate whether authentication passed or failed. success=true indicates the customer authenticated via Mobile Auth or via the Prove Key. success=possession_required indicates that you must perform possession.
4

Customer Possession Check Fallback

If possession is required, your app must perform a customer-supplied possession check such as SMS OTP. If the customer passes the possession check, proceed to the Unify bind step.
5

Unify Bind Call

The Unify Bindcall completes the customer-initiated bind registering the Prove Key.
6

Subsequent Authentication

This consumer authenticates using the Prove Key.