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. Architecturally, Unify is one coordinated session across client SDKs (Web, iOS, Android) and Unify platform APIs such as /v3/unify, with channel fallbacks—Instant Link, SMS OTP, Mobile Auth where enabled—so you are not maintaining a separate integration path for every surface and channel. Unify focuses on phone possession, device trust, and Prove Key lifecycle for that session. It does not replace your full identity provider, authorization (scopes, roles, entitlements), or every downstream fraud policy—you still map Prove outcomes into your own accounts, sessions, and risk stack.
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.

​
What the Prove Key is associated with

On Prove’s systems, each Prove Key is correlated with:
  • phoneNumber: the one used when the key is bound or authenticated
  • proveId: Prove’s identifier for the consumer when it is known
  • clientCustomerId and clientHumanId: when passed in the API request, these client-supplied identifiers are correlated with the same Prove Key
Pass optional identifiers on your API requests when you want that linkage recorded for the session.

​
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 differ in who runs possession first, which channels are in play, and when the Prove Key is considered bound, but the stages below describe the same mental model for all of them.

​
Stages every variant shares

  • Open a protected session — Typically scoped to the phone number so possession and downstream checks stay tied to one line.
  • Possession or key reuse — The SDK and server work to either reuse a bound Prove Key or complete a possession step through the channels your configuration allows.
  • Status — /v3/unify-status (and your app logic) resolve whether authentication finished, possession is still required, or the customer used an existing key.
  • Bind when needed — /v3/unify-bind finalizes registration of the key when your flow requires an explicit bind after possession.
  • Return visits — A bound key often allows lighter re-authentication until policy or rebind forces a full possession ritual again.

​
Choosing an integration model

Use this as a decision lens, not a rigid rule:
  • Prove’s possession flow — Prefer when you want Prove-led channels (Instant Link, OTP, Mobile Auth) to carry primary possession and you do not need your own vendor in the critical path.
  • Customer-supplied possession with force bind — Prefer when you already run your own possession (or must) and still want Prove to issue and register the Prove Key after your step succeeds.
  • Prove passive authentication with customer-supplied possession fallback — Prefer when you want passive Mobile Auth first on supported mobile networks, with your possession channel only when passive paths cannot complete binding.

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

Related topics

Get started with Prove API authenticationImplement ProveXIntegrate the Unified Authentication client SDKBuild Prove with LLMsUnified Authentication Sandbox Testing