A mobile security team should evaluate mobile SSO integration by separating three things that are often bundled together: federation with your identity provider, how the app handles and protects tokens, and how the device reaches internal services. Then assign each part to an owner, and test the whole session lifecycle, not only the first sign-in. This guide is for enterprise security, identity and mobile teams rolling out single sign-on to workforce or partner apps on Android and iOS. It focuses on the app side of the flow, where Otukan works. Identity provider configuration stays with your identity team.
Feature detail for single sign-on is in mobile SSO integration. Workforce app protection as a whole is covered on enterprise application protection.
Identity flow: federation, tokens and transport access
Federation
Federation answers one question: who is this user? On mobile, the recommended pattern for native apps opens the sign-in page in a system browser component, Custom Tabs on Android and the web authentication session on iOS, so the app never sees the password.
- Which protocols does your identity provider support for native apps, and which does each app use today?
- Do any apps still collect the password in a native screen or an embedded web view?
- Is multi-factor authentication enforced by the identity provider, the app or both?
Token handling
The token is what an attacker actually wants. Once issued, it lives in the app.
- Where are access and refresh tokens stored on each platform, and are they protected by the Android Keystore and the iOS Keychain?
- Can a token copied from one device be used from another?
- Is the app checked for hooking, debugging, root or jailbreak before it requests or renews a token?
Transport access
- Does the app reach internal services through a gateway, a per-app VPN or the public internet?
- Which layer decides whether this device may reach those services at all?
How Otukan answers. Otukan protects the app that receives, stores and presents your tokens. It checks app integrity and runtime conditions before sign-in and before renewal, and watches for instrumentation attached to the code that handles tokens and redirects. Tokens are protected by the Android Keystore on Android and held in the Keychain on iOS, and device binding detects a token presented from a device or app instance it was not issued to, so a copied token is refused.
Ownership: identity provider, app and device management
Mobile SSO spans three teams. Gaps between them become incidents.
| Responsibility | Identity team | App team | Device management team |
|---|---|---|---|
| Sign-in policy and MFA | Owns | Follows | Informed |
| Token storage and renewal in the app | Sets lifetimes | Owns | Informed |
| App integrity and runtime checks | Informed | Owns | Informed |
| Device enrolment and compliance | Consumes signal | Informed | Owns |
| Session revocation | Owns | Honours it | Triggers on device loss |
- Is the table above filled in, with names, for every workforce app?
- Which signals does each team need from the others, and through which system do they arrive?
- How are unmanaged devices treated, for contractors or partners who will never enrol?
How Otukan answers. Otukan sits with the app team. It sends runtime signals to your backend so that the identity side can step up or revoke a session based on what the app observed. It works alongside your device management and does not replace your identity provider. For managed fleets, see device management.
Lifecycle: login, renewal, revocation and recovery
Test each stage on both platforms, on managed and unmanaged devices.
Login and renewal
- First sign-in, sign-in after reinstall and sign-in after an OS update.
- Silent token renewal in the background and after a long offline period.
- Renewal attempted from a hooked, debugged, rooted or jailbroken environment: what does each option do?
Revocation
- A user leaves the organisation: how quickly does each app stop working, and who triggers it?
- A device is reported lost: are all sessions on it revoked, including in apps not currently open?
- A signed-out user presses back or restores from the app switcher: does any protected content remain visible?
Recovery
- A legitimate user fails a device check: what message do they see and which support path do they follow?
- Account recovery after a lost device: does it go through the identity provider rather than the app?
How Otukan answers. At every renewal, the protected app checks with your backend whether the user and device are still entitled, and clears cached tokens when the session has been revoked. You set a response per flow for sign-in and renewal: observe, warn, restrict or terminate. That lets you start by observing, then restrict renewal on compromised environments once your support path is ready. Protection slots into the release pipeline your app team already runs, with signing keys held by your team.
Authentication step protection is covered on MFA and authentication protection.