Engineering topic / Jeffrey Monica
A device verdict isn't a user session, and a user session isn't permission to touch every object. This collection is about keeping those boundaries separate.
Assume the caller can modify the client and network request. Name which checks are enforceable server-side.
Bind signed evidence to a fresh challenge, intended action, and expected application context.
Require independent step-up on dangerous paths and propagate revocation consistently.
iOS App Attest / Android Play Integrity / API authorization
A legitimate app instance can still send a request that the signed-in user must not be allowed to make. The server needs to verify the app evidence, bind it to the relevant operation, and independently enforce tenant and object permissions. That is the trust boundary I focus on when reviewing mobile auth.
Register an attested public key after verifying Apple's certificate chain and the expected app identity. For sensitive operations, verify an assertion over server-bound client data, including a fresh challenge and a monotonically increasing counter. Keep key associations and production/development environments distinct.
Apple's server validation guidance ↗Request an integrity verdict for a relevant action, decode it through the backend, and inspect request details, app recognition, signing identity and the selected integrity signals. For standard requests, compare requestHash against a stable digest of the operation. Use a risk policy rather than assuming the verdict automatically authorizes the user.
Establish the session principal and intended tenant. A device verdict is not a login.
Verify the iOS assertion or Android Play Integrity token on the server, including app identity and freshness.
Compare the attested challenge or request hash against the exact operation and immutable request fields.
Check whether this principal may perform this action on this tenant-owned resource, independent of device trust.
Apply idempotency or atomic-update controls. Capture safe decision metadata without logging token contents.
Illustrative server authorization order (pseudocode)
const principal = await requireSession(request);
const evidence = await validatePlatformEvidence(request);
assertBoundToAction(evidence, request.action, request.body);
await authorizeObject(principal, request.tenantId, request.objectId);
return commitOnce(request.idempotencyKey, request.action);Run these cases against a controlled test backend, not a production account. Each scenario needs a precise expected denial, an observable reason code and a regression test.
| Attack or failure | Expected backend behavior |
|---|---|
| Reused challenge or assertion | Reject stale proof and enforce server-side freshness or counter policy. |
| Integrity token for another request | Reject a requestHash or challenge that does not bind to the current action. |
| Valid device, wrong tenant | Deny object access; device integrity does not grant object permissions. |
| Expired or revoked user session | Deny even if platform integrity proof is valid. |
| Unexpected app identifier or signer | Reject evidence that does not match the configured application identity. |
| Concurrent duplicate mutation | Preserve authorization and idempotency under simultaneous requests. |
| Unavailable device-integrity service | Use an explicit risk policy and safe fallback; never silently grant privileges. |