Build a Mobile Imou App Without Putting AppSecret in the Client

#camera #automation

Put appId/appSecret signing and administrator accessToken on a trusted backend. Use Mobile OpenSDK on the phone for jobs the current mobile documentation assigns to the client: network configuration, device initialization, audio/video playback, and picture decryption. The app should receive only short-lived, purpose-limited material your backend mints after authenticating your own user. Shipping appSecret in an APK or IPA is not a shortcut; it is a credential leak.

Why it matters

Client binaries are extractable. If the secret lives in the app, anyone can impersonate the developer application, request tokens, and reach whatever that application can reach. Mobile OpenSDK still needs a clear job: local media and onboarding, not becoming the OpenAPI control plane.

This is a secret-placement article. It does not restate a full OpenSDK versus HTTP catalog, and it does not invent mobile method names.

Approach / architecture

Job	Where	Credential
Sign OpenAPI, obtain administrator token	Backend	`appSecret`, admin `accessToken`
Create/limit sub-account tokens if used	Backend	Admin token + `openid`
Authenticate your product user	Your identity stack	Your session
Provision, preview, talk, decrypt pictures	Mobile OpenSDK	Only tokens the live SDK flow requires
Bind, callbacks, storage activation, fleet policy	Backend HTTP	Admin or sub-account per method page

Mobile user session
  -> your BFF (product authz)
  -> mint only documented client material
  -> OpenSDK local/media operations

BFF
  -> signed OpenAPI
  -> device bind, events, storage, permissions

If a sample project places appSecret in gradle.properties or an iOS plist, treat that as a demo anti-pattern for production.

Six implementation steps

Split the Xcode/Android app from the BFF. The mobile repo should not contain production appSecret.
Authenticate the human in your app first. Imou tokens are not a replacement for your user login.
Mint the minimum client secret from the backend. Follow the current OpenSDK and token pages for what the player or SDK actually consumes. Do not send administrator accessToken to the phone unless a live page explicitly requires that unsafe pattern—and prefer a design that does not.
Keep onboarding and playback in the SDK. Those are documented client responsibilities. Pair them with backend bind and inventory.
Authorize every backend mint. Map the user to tenant, device, and channel before issuing anything the SDK can use to see a camera.
Rotate and revoke in the backend. When a user is offboarded, remove product access and Imou policies from the control plane. Do not rely on “uninstall the app.”

APIs / SDKs

Mobile development summary — client/HTTP split
Development specification — signing stays on the backend
Account docking — token types

Download official OpenSDK packages from the platform resource pages; do not paste unofficial binaries.

Limits & pitfalls

Hard-coded secrets in clients will be extracted.
Logging SDK debug output can leak tokens.
Two-way talk and download remain device-dependent; do not promise codecs.
Recheck the mobile summary before publication.

CI, samples, and release gates

Add a CI check that fails the mobile pipeline if appSecret, accessToken, or typical secret filenames appear in the app module. Review third-party crash reporters and verbose OpenSDK logs; they often capture headers. Provide developers with a sandbox appId that is not production, and still keep its secret on the sandbox backend.

Document which token the UI is allowed to hold, for how long, and where it is stored (memory versus encrypted disk). If the official SDK requires a kit-style token for a player surface, mint it on the BFF after product authorization and treat it as non-admin. If you cannot find a live page that requires a given token on the phone, do not put it there.

QA should include: a rooted/jailbroken mental model (assume extraction), proxy interception of your BFF, and an attempt to replay a captured client token against OpenAPI. The expected result is that OpenAPI still needs backend signatures and that the stolen client token cannot create sub-accounts, set callbacks, or bind arbitrary devices.

When you update OpenSDK versions, re-read the mobile summary for the client/HTTP split. New sample code in a zip file is not permission to move appSecret back into the client. Two-way talk, download, and playback remain capability-dependent; keep those promises in the device matrix you actually tested, not in the security architecture of this article.

Use the mobile development summary as the client/server split, keep secrets on a backend registered at Imou Open Platform, and ship an app that cannot sign OpenAPI by itself.

DEV Community