Otukan gives your backend a reliable way to tell requests from your genuine app apart from abuse. The protected app attaches evidence to each sensitive call: that it is your unmodified release, that it runs in an environment you accept, and that the request is fresh rather than replayed. Your API gateway or backend verifies that evidence and applies the policy you set per endpoint, so every decision stays on infrastructure you control. Otukan protects Android, iOS, Flutter and React Native apps, and scopes each signal per platform, because Android and iOS expose different evidence.
Trust chain
A trusted mobile request rests on three links. Otukan builds each one, and your backend checks them together.
- Application identity. Otukan proves the request comes from your app as you signed and released it, not from a script, an emulator farm or a repackaged copy. See app attestation.
- Device context. Runtime checks inside the app report rooted or jailbroken devices, hooking frameworks, debuggers and emulators, and that evidence travels with the request. See mobile RASP.
- Backend enforcement. Your server verifies the evidence on every sensitive call, rejects anything stale or reused, and applies a policy you own.
Android and iOS each provide platform attestation services: Play Integrity on Android and App Attest on iOS. They answer different questions, have their own quotas and are not equivalent. Otukan adds runtime evidence that platform verdicts do not report, such as hooking and debugging, and keeps each source clearly labelled. Your backend can weigh a platform verdict signed by Google or Apple next to Otukan’s evidence, platform by platform.
Attack coverage
“Bots” covers several different attacks. Each one breaks a different link in the chain, and Otukan answers each with a dedicated control.
| Attack | What it looks like | How Otukan handles it |
|---|---|---|
| Scripted clients | A script calls your API directly, imitating the app | Requests without valid app evidence fail verification on your server |
| Modified clients | Your app, changed or hooked, sends requests it should not | Integrity and runtime signals travel with the request, so sensitive endpoints can refuse it |
| Replay | A valid request or token is captured and sent again | Short-lived, single-use evidence bound to the request is rejected on reuse |
| Stolen tokens | A session token is lifted from one device and used elsewhere | Device binding ties the session to the device and app instance it was issued to |
| Credential stuffing | Leaked passwords are tried at scale through your login API | Attestation on login separates real app sessions from automation, alongside your rate limits |
The result is a backend that can treat requests from your genuine app with confidence and make automated abuse slower, costlier and visible. Otukan’s evidence is strongest combined with the rate limits, account risk scoring and fraud monitoring you already run. For account-level abuse, see mobile fraud prevention.
Sector requirements are covered on fintech app security, ecommerce mobile app security and telecom mobile app security.
Integration
Verification you own
Evidence is useful only when someone checks it, so Otukan puts that check in your hands. Verification runs where you choose: in your API gateway, in a dedicated service or in each backend that owns a sensitive endpoint. Otukan defines the verification contract, which states what the backend receives with each request, how it is validated and how long it stays valid. Your gateway team builds against that contract, and your security team owns the policy when it needs to change.
Protection fits your existing build and release pipeline. Your signing keys stay with you, and nothing in the request path depends on handing Otukan your API secrets.
Failure modes you choose
Checks can fail for legitimate reasons: a platform attestation service is briefly unavailable, a user runs an old app version, or a device is unusual. Otukan lets you choose per endpoint what happens then.
- Fail open. Allow the request, record the failure and watch the rate. Suits low-risk reads.
- Step up. Ask for another factor or limit the action. Suits logins and account changes.
- Fail closed. Reject the request. Suits payments and other irreversible actions.
Roll out in observe mode first. Your backend records every verification result without enforcing it, so you can measure how often legitimate traffic fails before you switch each endpoint to enforcement. That keeps genuine customers moving while scripted traffic loses its easy path to your API.