A mobile security team should evaluate MFA and authentication protection by following one sign-in from the first screen to the token your app holds afterwards, and asking where along that path a factor or token could be read, faked or replayed. Otukan protects the app side of that path. It guards password, one-time code and approval screens against hooking, overlays and automation, keeps tokens in platform key storage behind pinned connections, and attaches app and device evidence to sign-in and renewal requests. Your identity provider still verifies the person and applies its own policies. Signals are built and documented separately for Android and iOS.
The identity flow, piece by piece
Authentication in a mobile app is three separate problems. Evaluating them together hides where the weaknesses sit.
| Layer | What it covers | Where it goes wrong | What Otukan adds |
|---|---|---|---|
| Federation | The sign-in exchange with your identity provider | Credentials captured on a spoofed or overlaid screen | Overlay, accessibility and hooking checks on sign-in screens |
| Token handling | Access and refresh tokens after sign-in | Tokens read from storage or memory and reused | Key-wrapped storage and tamper checks on read |
| Transport | Every request carrying credentials or tokens | Interception proxies on hostile networks | Pinned connections and a reported failure |
Federation
Sign-in either runs in the system browser or in native screens your team builds. The system browser keeps the password away from app code; native screens give a smoother experience but put the credential inside your process. Otukan protects either choice and reports which checks ran. When the browser route is used, the code exchange that follows returns to your app, and that is where Otukan’s hooking and integrity checks apply before the token is accepted.
Tokens and transport
After sign-in, the token is the account. Otukan wraps tokens with a key held in the Android Keystore on Android and in the Keychain on iOS, checks them for tampering when the app reads them, and sends them only over connections that match the certificates you pinned. For binding the token to the device that received it, see device binding.
Who owns which part
Authentication fails in the gaps between teams. Write the ownership down before you evaluate any product.
Identity provider
Owns accounts, factors, session lifetimes and step-up rules. It verifies the person and issues tokens. It sees the request but not the app that sent it.
The app and Otukan
Owns the screens where factors are entered and the storage where tokens live. Otukan adds the integrity of the app, the state of the device and the context of the session, and passes all three to your identity provider with the request.
Device management
Where phones are managed, your management system reports whether the device meets your rules. That is a statement about the device, not about your app’s integrity. Otukan’s evidence stands on its own on personal phones and adds detail on managed ones.
Test the whole lifecycle
Login and step-up
In an authorised lab, overlay the Android code screen, hook the verification result and drive code entry with an automation tool. Confirm each attempt reaches your identity provider marked. Then sign in normally on a clean phone and confirm no step-up fires.
Adding a new factor
Registering a new authenticator or phone number is an attacker’s favourite first move after a successful sign-in. Run it from a tampered build and from an emulator, and confirm the change is stepped up before the new factor becomes active.
Renewal
Copy a refresh token to another installation and try to renew with it. Confirm the renewal is refused or stepped up, and that the attempt is visible to your security team.
Revocation and sign-out
Sign out and confirm Otukan has removed the stored tokens from key storage. Revoke a session on the server and confirm the app stops using it at the next request.
Recovery
Recovery is the quietest door into an account. Run the recovery flow from a hooked build and from a phone under remote control, and confirm both are held for a trusted channel. Record device, OS version, expected result and reviewer for every test.
For the full picture of account security, return to identity and account protection. For superapps, where one login opens several services, see superapps application security.