Skip to Content
Android SDKOperationsSecurity & privacy

Security & privacy

Credential handling

  • The SDK authenticates as the integrator. With ClientCredentialsAuth the clientSecret lives in the app process — acceptable for a controlled device/kiosk, not for an app shipped to untrusted users.
  • Keep secrets out of source control — inject at build time (e.g. local.properties → BuildConfig) and obfuscate release builds (R8/DexGuard).
  • If you can’t trust the device, mint the bearer on your backend and supply it via a plain AuthConfig callback.

The credential gate

Every SDK function is gated behind a working credential pair. See Authentication.

Data in transit

  • All calls go directly to the Slade ID service over HTTPS with a bearer. The SDK never runs a local server.
  • Images are encrypted before transmission by default; set encryptBiometrics = false to send base64.
  • The SDK sends a non-secret device identifier for attribution; you do not configure it.

Data at rest

The SDK does not persist biometric data — each capture is submitted and discarded. Templating, matching, and storage happen server-side in the Slade ID service.

Protecting the SDK itself

The high-value biometric logic (templating, embeddings, matching, thresholds) is server-side, so SDK extraction doesn’t expose it. The client-side device-handling code is protected by obfuscation (R8/DexGuard), the license-bound vendor binaries it depends on, and your integration agreement. Obfuscation raises the cost of reverse-engineering; it is not an absolute barrier.

TroubleshootingFAQ