Cache Imou accessToken on the Backend and Issue Only What Each Client Needs

Cache Imou tokens only on a trusted backend, keyed by application and token kind, never by “one global string for the whole product.” Obtain the administrator accessToken with application credentials when the live accessToken page requires it. Obtain a sub-account token with an administrator token plus openid when that flow is documented. Reuse a cached value only within the lifetime stated on the current page. Clients should receive only the narrower material needed for a documented client job—not a standing administrator credential.

Why it matters

Calling accessToken on every user click wastes quota and hides failures. Caching one administrator token in Redis and handing it to every mobile session is worse: it turns every client into an admin. The useful design is a token service that knows which operation needs which authority, refreshes before documented expiry, and never logs the raw value.

Approach / architecture

Cache entry	Key	Used for
Administrator accessToken	appId + region	Control-plane methods that require it
Sub-account token	appId + openid + region	Device operations the method page accepts
Client-only material	User session + purpose	OpenSDK/player if documented

incoming product request
  -> authorize tenant/user/resource
  -> select token class from reviewed method registry
  -> cache lookup / refresh
  -> signed OpenAPI call

Refresh should happen in the backend. If two workers refresh the administrator token, use a lock so you do not stampede the token API. That locking behavior is your architecture, not an Imou guarantee.

Six implementation steps

1. Read the live accessToken and subAccountToken pages. Record required inputs and any documented validity period. Do not copy a “three days” figure from memory unless the current page still says it.

2. Store tokens in a backend secret store or encrypted cache. Encrypt at rest if your platform requires it. Set TTL shorter than or equal to documented validity.

3. Never cache tokens in the mobile app as the source of truth. A short-lived client copy, if required, must be treated as disposable.

4. Do not share sub-account tokens across users. A cache key without openid (or your internal user id mapped to it) is a vulnerability.

5. On 401/documented auth failures, refresh once with a new signed envelope. Do not retry with the same nonce and id.

6. Revoke in product terms by deleting policies and sessions. Do not assume an old cached sub-account token is harmless after offboarding; clear your cache when you clear Imou policy.

APIs / SDKs

• accessToken
• subAccountToken
• Account docking summary
• Per-method pages for whether admin or sub-account tokens are accepted

Limits & pitfalls

• Parameter name token does not tell you which kind you cached.
• Administrator fallback after a sub-account denial elevates privilege.
• Logging tokens defeats the cache design.
• Recheck token lifetime on publication day; do not invent SLA.

Cache operations that do not leak

Treat the token cache as production credentials. Restrict IAM so only the API workers that sign OpenAPI can read it. Encrypt values if your secret manager does not already. Disable debug endpoints that dump cache keys in non-production copies of production data.

Expiry handling should be pessimistic. If the live page states a validity window, refresh with margin and on documented auth failures. If the page does not state a window, do not invent one; prefer fetch-on-demand plus short negative caching of errors so a broken secret does not create a request storm.

Multi-region deployments must not share a token cache across Imou data centers. An administrator token issued against Singapore configuration is not a generic “Imou login.” Key the cache with appId and region enum.

For sub-account tokens, bind TTL to both documented validity and your session TTL, whichever is shorter. When a user logs out or is removed, delete the cache entry in the same transaction as your session revoke as far as your architecture allows. Query Imou policy state asynchronously if you need extra assurance; do not block logout on a slow OpenAPI call unless you have a defined degradation path.

Never return the administrator token to GraphQL, REST, or gRPC clients used by mobile apps. If a partner integration needs device access, give them a product-scoped API you control, not a cached Imou credential.

Build the token cache beside the account docking documentation and keep every reusable Imou credential on a backend at Imou Open Platform.