App and API controls reduce automated login abuse by making every sign-in attempt prove where it came from. Otukan attaches evidence of your genuine app, the device environment and request freshness to login calls, so your backend can tell a customer signing in from a script working through a leaked password list. Your servers keep throttling and checking passwords, and your identity controls decide when to ask for more. Otukan covers Android and iOS apps, including Flutter and React Native, and turns stuffing into a slow, costly campaign your team can see.
For the evidence model behind login calls, see mobile API protection.
Login attack flow
Automated login abuse is not one attack. Each type leaves different traces, so each needs a slightly different response.
Stolen credentials
Credential stuffing replays username and password pairs leaked from other services. The attacker’s advantage is volume and reuse: most pairs fail, a few succeed. Otukan removes the cheap route by making calls without genuine app evidence stand out on arrival, and by reporting emulators and automation tools behind calls that do carry it.
Guessing
Password spraying tries a handful of common passwords across many accounts, staying under each account’s lock-out limit. Brute force hammers one account. Both look different when grouped by install rather than by account, which is why Otukan gives your backend a pseudonymous install reference alongside the attempt.
Session attacks
A successful login produces a token, and a stolen token skips the password altogether. Otukan binds the session to the install it was issued to and keeps checking the runtime after sign-in, so a token lifted into another client, or tools attached after login, trigger your policy.
Shared enforcement
Stuffing protection works when each layer does what it is best at and nobody assumes another layer has it covered.
| Decision | App evidence from Otukan | Backend throttling | Identity controls |
|---|---|---|---|
| Is this a genuine app on a real device? | Owns it | Uses the verdict | Uses the verdict |
| Is this client sending too many attempts? | Supplies the install reference | Owns it | Informed |
| Is the password correct? | Never sees it | Owns it | Owns policy |
| Should we ask for a second factor? | Supplies risk context | Informs | Owns it |
| Is this session still in the right hands? | Reports binding and runtime changes | Enforces | Re-authenticates |
The app never holds the final say, because a device in an attacker’s hands can be studied. It supplies the evidence your server cannot gather any other way, and your server acts on it. Otukan’s evidence is labelled by source and scoped per platform, so a signal from Android is never read as if it came from iOS.
Sector patterns are covered on fintech app security and ecommerce mobile app security.
Evaluation
The quickest way to buy the wrong login protection is to measure only what it catches. A control that catches scripted attempts but also turns away a share of real customers becomes a customer-service problem.
Two numbers, tracked together
Otukan’s evaluation measures detection and false positives side by side: attempts caught by type, and genuine customers challenged or refused by app version, device class and network. Neither number is reported without the other.
How the evaluation runs
- Reproduce stuffing, spraying and session replay with authorised scripts in a lab, and confirm each produces the expected signal.
- Repeat the same sign-in journeys from legitimate devices on supported configurations, and confirm they pass quietly.
- Run install, update, password reset and your most sensitive post-login flow on the protected release.
- Record app versions, devices, expected results and the reviewer, then move each rule from observe to enforce.
Signals by platform
Android and iOS give an app different views of its environment, so Otukan builds and labels login evidence per platform. On Android, the backend can weigh Otukan’s evidence next to a Play Integrity verdict it verifies itself; on iOS, next to App Attest. Evaluation results are reported per platform as well, because a false-positive rate on one tells you nothing about the other.
The broader account journey after sign-in is covered on mobile account takeover prevention. Credentials taken on the phone while customers type them are covered on credential theft prevention.