Evaluate mobile SSO integration by following one session from sign-in to sign-out and asking, at each step, who checks what. Your identity provider confirms the user. The work app receives, stores and presents the tokens. Device management may decide which phones are allowed at all. Otukan strengthens the app’s part of that chain on Android and iOS: it confirms the app is genuine before sign-in, binds tokens to the device, protects them with platform key storage and repeats its checks at every renewal. Identity decisions stay with your identity provider, which now sees evidence about the app and the phone.
The step-by-step evaluation is in the mobile SSO integration solution guide.
Identity flow
Single sign-on on a phone is three connected problems. Solving one does not solve the others.
Federation
Federation establishes who the user is. On mobile, the sign-in page should open in the system browser component that Android and iOS provide, so the password is typed into your identity provider’s page and never into the app. The app receives an authorisation result, not the credentials.
Token handling
Once the redirect returns, the app holds tokens that act as the user for hours or days. That is where most mobile identity attacks aim. On Android, Otukan encrypts session tokens with a key held in the Android Keystore; on iOS, it stores them in the Keychain. It binds them to the device and app instance, and watches for hooks attached to the code that reads them.
Transport access
A valid session still needs a safe path to your services. Server identity checks and per-app tunnelling are separate controls with their own owners. For the network side, see enterprise access and per-app VPN.
Ownership
Write the split down before the pilot. Each gap in this table becomes a question nobody can answer during an incident.
| Responsibility | Identity provider | Work app with Otukan | Device management |
|---|---|---|---|
| Who the user is | Authenticates, issues tokens | Opens the system sign-in page | Not involved |
| Whether the app is genuine | Receives the evidence | Proves integrity before sign-in | Distributes the approved build |
| Whether the phone is safe | Uses the signal in policy | Checks root, jailbreak and hooking | Reports compliance where enrolled |
| Where tokens live | Sets their lifetime | Binds them and protects them in platform key storage | Not involved |
| Ending access | Revokes the account | Clears tokens at the next renewal | Retires the device |
Otukan does not replace your identity provider or your device management platform. It gives both of them evidence they cannot collect from outside the app.
Where decisions are made
Keep the final decision on the server side. The app collects evidence and can pause a step locally, but the identity provider decides whether a session is issued, renewed or ended. That way an attacker who silences a check on the phone still has to get past a server that expected to hear from it. Agree in advance which evidence triggers a step-up, which triggers refusal and which is only recorded.
Lifecycle
A pilot that only tests the first sign-in misses most of the risk. Test the full lifecycle, on Android and iOS separately.
Login
Sign in from the genuine app on a healthy phone and confirm the evidence reaches your identity provider. Repeat from a modified copy and from a rooted or jailbroken test device, and confirm each is stopped or stepped up as your policy says.
Renewal
Let a session age and renew. Change the device state between the two, for example by attaching an instrumentation tool, and confirm the renewal sees it. Copy a token to a second test device and confirm device binding refuses it.
Revocation
Disable a test account and confirm the next renewal fails, the app clears its tokens and stored corporate data is no longer shown.
Sign-out
Sign out from the app and confirm the tokens and their protecting keys are deleted, not just hidden from the interface. Reopen the app and confirm it asks for a fresh sign-in rather than silently restoring the previous session.
Recovery
Walk through a replaced phone and a device that fixes its own state. Confirm the user can return through the normal sign-in, and record devices, OS versions, expected results and the reviewer.