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.
Possession is coordinated work: your app runs a client-side SDK (Web, iOS, or Android) while Prove’s Unify platform APIs advance the session and bind outcomes. Which endpoints apply depends on the integration variant—see the Unified Authentication implementation guide for the API surface and wiring.

​
Concepts and definitions

  • Prove Key: Non-extractable cryptographic key used for authentication 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 for the Web SDK that helps recover device registration when the Prove Key is unavailable, eliminating the need for SMS OTP or Instant Link re-authentication.

​
Prove Key validity and expiration

The Prove Key does not expire on a fixed calendar date. It stays valid with normal use, subject to the following:
  • Inactivity: Prove deactivates the key on our servers if the device remains inactive for 12 consecutive months. Each time the customer completes a new authentication, that 12-month period resets from that activity.
  • App uninstall and reinstall (native apps): If the user deletes the app and reinstalls it, behavior depends on platform:
    • iOS: The Prove Key remains on the device, so it is still available after reinstall. Fingerprint technology is not needed to reconstitute the key in that scenario.
    • Android: Device Context for recovering registration when the Prove Key is unavailable isn’t available for the Android SDK.
  • Forcing a possession check: You can require an active possession check even when a key may still be valid; the Unify request supports signaling that intent (see the /v3/unify reference and implementation guide).

​
Geographic availability

Prove Key is available in all countries.Mobile Auth is not supported in every country. Coverage varies by region—confirm availability for your markets when your flow depends on Mobile Auth.

​
Integration variants

Unified Authentication supports several integration models. They share the same conceptual stages—opening a session, proving possession (or reusing a key), resolving status, and optionally binding—but differ in who runs possession first, which channels are in play, and when the Prove Key is considered bound.

​
Prove’s possession flow

In scope: Prove Key; Mobile Auth and Prove OTP on mobile; Instant Link on desktop. Out of scope: Your own possession channel as the primary path.
Diagram illustrating Prove's unified authentication possession flow
In this model, Prove’s channels carry possession on each surface. The flow opens a protected session scoped to the phone number, then the client SDK tries the lightest path first: if a bound Prove Key already exists, the customer may authenticate without repeating a full possession ritual. If no usable key is present, possession depends on context. On desktop, that typically means Instant Link so the user can complete proof in the mobile environment. On mobile, Prove-led channels apply—commonly SMS OTP, and when Mobile Auth is enabled, silent network authentication may run ahead of OTP with OTP as fallback. The key may not be fully bound until status confirms the session, depending on how channels stack in your configuration. The status stage tells you whether authentication succeeded, whether possession is still outstanding, or whether the customer authenticated with an existing key—so your application knows what to surface next. After a successful bind or authentication, the same customer can usually return through Prove Key–based authentication on later visits.

​
Customer-supplied possession with force bind

Scope: Mobile channels where Prove still issues the Prove Key, but your possession vendor performs the primary possession step.
Diagram illustrating the Unify flow using customer-supplied possession
Here the session is shaped so Prove does not lead possession first; instead, your integration drives the primary possession experience. The SDK still checks for an existing key and may stage key state, but binding completes only after your possession succeeds. An early status outcome distinguishes “already authenticated with the key” from “possession still required.” When your customer completes your possession step, a bind phase registers the key in Prove’s registry. Subsequent visits behave like other Prove Key flows. Implementation options (for example, how the session signals that Prove-led possession is deferred) are documented in the implementation guide.

​
Prove passive authentication with customer-supplied possession fallback

In scope: Prove Key; passive Mobile Auth on mobile where available; Prove OTP where applicable; your possession when passive paths do not finish binding; a bind step when your possession is required to close the loop.
Diagram illustrating the Unify flow using customer-supplied possession
This variant layers strategies: Prove attempts passive mobile authentication first to minimize friction. If the session cannot complete on passive paths alone, status indicates that additional possession is needed; your channel can supply that proof, and bind finalizes registration when required. The same customer can then authenticate with the Prove Key on return visits. Session setup, request fields, status codes, and SDK configuration for each variant are covered in the Unified Authentication implementation guide. API contracts are in the reference for /v3/unify, /v3/unify-status, and /v3/unify-bind.