Judge session risk signals on three things: do they keep watching after sign-in, do they reach the place where decisions are made, and do they behave sensibly when uncertain. Otukan is built for all three. It repeats integrity, tooling, remote-access and continuity checks during the signed-in session and sends the current risk with each sensitive call. Your backend decides, using rate, challenge, retry and failure rules set per session stage. Scope is the live session in Android and iOS apps, with signals labelled per platform; login-time checks and user authentication are separate controls.
For the request evidence this builds on, see mobile API protection.
Abuse path
Most session abuse starts after a perfectly normal login. Sorting what happens next into three groups keeps the response proportionate.
Automated requests inside a session
A valid session token is lifted and fed to a script that repeats calls: balance checks, transfers, reward claims. Otukan exposes this when requests stop carrying fresh proof from the installation the session belongs to, or when the same call arrives twice.
Invalid clients inside a session
The session stays on the right phone, but the client changes underneath it. A hooking framework attaches after launch, a debugger connects, or a remote-control service starts while the customer is guided through a payment. Otukan’s in-session re-checks catch conditions that were not there at login.
Legitimate automation
Not every unusual session is abuse. Accessibility services, password managers, test rigs and customers who move between Wi-Fi and mobile data all create signals. Otukan labels each signal by source, and the rollout records known legitimate patterns before any rule is enforced.
| Session event | Likely meaning | Typical rule |
|---|---|---|
| Tools attach after login | Invalid client | Restrict sensitive steps |
| Requests lose installation proof | Session moved elsewhere | Re-authenticate |
| Remote control during a transfer | Social engineering in progress | Pause and warn |
| Duplicate request | Replay | Refuse the duplicate |
| Network change to a relay | Interception or travel | Hold high-value actions |
Enforcement boundary
Session risk is produced in one place and used in others. Getting that split right is what makes it trustworthy.
- In the app. Otukan gathers signals, and can act at once when the customer needs protection in the moment, such as pausing a transfer while a remote-control service is active.
- At the gateway. The gateway reads the current session risk and can refuse replays or unverified calls before they reach services.
- In the backend. Business services combine session risk with account history and the value of the action, and make the final call. That decision stays where an attacker on the device cannot reach it.
Where each signal comes from
Android and iOS expose different information inside a running app. Otukan builds its in-session checks separately for each platform and tags every signal with the platform and check that produced it. On Android, remote-control and overlay services are visible to the app in ways that iOS does not allow, so the iOS view of a remote session leans on screen-sharing state and runtime integrity instead. Your backend never has to guess whether a missing signal means “safe” or “not measured on this platform”.
A related runtime view is covered on runtime threat signals.
Continuity
A session policy that logs out genuine customers is worse than a risky session. Otukan writes four rules for each session stage before enforcement.
- Rate. How often sensitive calls may repeat within a session before risk rises.
- Challenge. Which step-up a risky session meets, and at which stage, so browsing is rarely interrupted.
- Retry. How the app retries after a refused or challenged call, without duplicating a payment.
- Failure. What happens when signals are missing: continue and record for browsing, challenge for account changes, wait for fresh evidence on payments.
Testing before enforcement
Otukan works with your team to reproduce each session abuse case in an authorised lab, repeat the same journeys on legitimate devices with assistive tools and network changes, then run install, update, sign-in and your riskiest in-session flow on the protected release. Results are recorded with versions, devices, expected outcomes and the reviewer, and each stage moves from observe to enforce on its own schedule.