Otukan ties each sign-in, factor and session to a genuine installation of your app, so a stolen password or lifted token no longer opens the account from somewhere else. It binds sessions to a verified installation, protects biometric and one-time code flows against hooking and, on Android, overlays, recognises cloned instances and reports all of it to your identity service with each sensitive request. Your identity provider still decides who the person is. Evaluate it moment by moment, from enrolment to device change. Otukan covers Android, iOS, Flutter and React Native apps, and scopes every signal per platform, because the two platforms offer different identity building blocks.
Identity moments and trust boundaries
An account is attacked at the moments your app decides to trust someone. Each moment has its own boundary, the point where the app hands a claim of identity to your backend.
| Identity moment | What an attacker tries | Trust boundary | Otukan signal |
|---|---|---|---|
| Enrolment | Register a new installation against a stolen account | New installation to identity service | Installation integrity, device state, automation |
| Sign-in | Replay leaked passwords, capture one-time codes | Credential check | Genuine app evidence, overlay and hooking detection |
| Step-up | Fake a biometric match in a tampered app | Factor verification | Key-backed biometric result |
| Session | Lift a token and use it on another device | Token presentation | Device binding |
| Device change | Move the account to an attacker’s phone | Re-binding | Integrity of the new installation, step-up |
Device change and enrolment deserve the most care. They are built to let a customer in without the usual context, which makes them the favoured door for account takeover. For the full takeover path, see account takeover prevention.
Who holds each part of identity
In the app
The protected app is where identity evidence is born. Otukan creates a key-backed identity for each genuine installation, checks app integrity and device risk signals before a factor is accepted, and detects hooking, overlays and cloning around sign-in screens. Because a modified app could forge any of these results, integrity checks run first and travel with every result.
In the platform
The platforms supply strong primitives. On Android, the Keystore holds keys that can be bound to biometric approval, and key attestation describes where a key lives. On iOS, the Keychain can require biometric approval before a key is used, and App Attest lets your server confirm a genuine app instance. Otukan builds on these rather than around them, and uses each one only on its own platform.
On your identity servers
Your identity provider and authentication service hold the account, its factors and its history. They decide whether to allow, step up or refuse. Otukan’s evidence arrives with the request, so those decisions stay on servers you control and hold even when the device is in hostile hands. For binding tokens to devices, see device binding.
How to evaluate identity and account protection
Signals per platform
Ask for a signal-by-signal list for Android and iOS. Cloning checks, overlay detection and accessibility signals are Android concerns; App Attest is an iOS mechanism. A shared label such as “biometric protection” should break down into two separate, documented implementations.
Evidence to request
Run the attacks yourself in a test environment. Hook the biometric result in a protected test build and confirm the server refuses the approval. Copy a session token to a second device and confirm the mismatch is reported. Install the app in a cloning container on Android and confirm the instance is recognised. Each test should produce a record your identity team can read without help.
Then check the paths an attacker would try next. Register the same account from a fresh installation on an emulator and confirm enrolment is stepped up. Drive a code entry screen with an automation tool and confirm the attempt is marked. Compare what each test produced on Android with what it produced on iOS, and make sure your team knows which signals exist on only one platform.
Customer friction
Strong identity controls fail when they punish real customers. Measure how often legitimate sign-ins are stepped up per platform and app version before enforcing. Check the device change journey end to end with real support staff. Make sure people using accessibility tools can still sign in, with their assistive services treated as trusted where your policy allows. Signals are logged against a pseudonymous installation identifier, which keeps investigation possible without spreading personal data.
For how identity signals feed wider fraud decisions, see mobile fraud prevention.