Skip to content
Overview Integration flow Web SDK Android SDK iOS SDK API Reference

Security model

This page is the security model every iOS example in these guides follows. Use it as the checklist for your own backend and app.

Parties

Section titled “Parties”
Party Role
Your server Holds Prove ID API credentials, obtains an access token, starts the transaction, stores transactionId ↔ signed-in user, reads the result and decides.
Your app Runs camera / NFC / liveness screens, holds the token in memory only, sends images and videos straight to Prove ID.
Prove ID Verifies documents and faces; returns control results for the transaction.

End-to-end flow

Section titled “End-to-end flow”
  1. The user signs in to your app.
  2. The app calls your backend (session cookie / your JWT). Only signed-in users can call this.
  3. Your server obtains a Prove ID access token (POST /oauth/access_token in the API Reference — application / client_credentials flow) and starts a transaction (POST /id/start).
  4. Your server stores which user owns that transactionId and returns { accessToken, transactionId, gestureType } to the app.
  5. The app sets ProveIDApiClientAPI.customHeaders["Authorization"] = "Bearer \(accessToken)", runs the steps, and never writes the token or media to durable storage.
  6. The app sends the transactionId back to your server when the flow finishes.
  7. Your server checks ownership, then reads GET /id/id-info-with-tid/{transactionId} and decides. The app UI may show a summary; it is not the authority.

See the Quickstart for working server and app code, and Authentication for token handling in the app.

Rules that must hold

Section titled “Rules that must hold”
  • Prove ID client ID, client secret, API username or password never ship in the app bundle, Info.plist, .xcconfig files or the source repository.
  • Token: memory only (not UserDefaults, files or Keychain) → remove from ProveIDApiClientAPI.customHeaders when the flow ends → on 401, ask your server for a new token and retry.
  • Prefer a dedicated Prove ID API user for the mobile flow with only the permissions the verification steps need.
  • Never log tokens, Base64 images, MRZ, chip data or full API bodies (print, os_log, crash reports, analytics).
  • Delete liveness / hologram video files after upload (including failed uploads). Keep document images in memory only.
  • HTTPS only to https://test.api.proveid.io or https://api.proveid.io. No App Transport Security exceptions, no trust-all URLSession / Alamofire trust managers.
  • Approve the customer only from your server’s read of the transaction, never from a boolean the app reports.

Confirm with Prove ID

Section titled “Confirm with Prove ID”

State these with your Techsign contact before go-live; these guides do not invent answers:

  • Whether an application-flow (client_credentials) token from /oauth/access_token is accepted for the mobile id/* and face/* calls you use (sample apps sign in with username/password for demos).
  • Whether a transaction-scoped token can be issued instead of handing an organisation token to the device.
  • Which least-privilege roles exist for the mobile flow.
  • Which controls run for your organisation and which score thresholds you should treat as pass/fail (Results notes that thresholds are configured per organisation).
Section titled “Related pages”