Skip to main content
The mobile auth SDK runs an explicit state machine per (app_id, device). Transitions are validated; invalid transitions throw InvalidStateTransition. The state is persisted alongside device_id so the SDK can resume across app restarts.

States

Allowed transitions

Any other transition throws InvalidStateTransition.

Mapping to public API

Persistence

The current state is stored alongside device_id, key alias, platform, registered_at, key_rotated_at, and clock_offset_ms. Private key bytes are never persisted in app-managed storage β€” they live only in hardware.

Key invalidation detection

The SDK transitions registered β†’ keyInvalid automatically when the OS reports the key is no longer usable. On detection:
  1. SDK emits KeyInvalidated error.
  2. State transitions to keyInvalid.
  3. The next registerDevice(appId) call wipes local state (keyInvalid β†’ unregistered) and starts fresh.
The SDK never silently retries with the invalid key.

State after resetDeviceIdentity

resetDeviceIdentity(appId) is the one-step path from any state back to unregistered. It is allowed only when:
  • Server explicitly instructs identity reset (e.g. DEVICE_REVOKED).
  • User explicitly requests it (β€œsign out of all devices”).
  • Key invalidation is detected and rotation is impossible.
It MUST NOT be called as a convenience retry. After it returns:
  • The hardware key is deleted (best-effort; on hardware failures the alias is abandoned).
  • device_id and metadata are cleared.
  • Next API call requires a full re-registration.
  • Registration β€” happy-path transitions.
  • Errors β€” KeyInvalidated, InvalidStateTransition, recovery paths.
  • Signing β€” only registered enables this.