Android Play Integrity request binding and backend verdict policy

A Play Integrity token can be valid yet unhelpful if it was collected for a different action. The request binding and the backend's actual decision policy matter at least as much as obtaining the token.

Google's Play Integrity standard-request documentation describes preparing a token provider, requesting a verdict for a protected action, and passing the token to a backend for verification. This is not a client-side security gate: the backend owns the decision.

For standard requests, Google recommends supplying a requestHash computed from the request's important fields. Compute a digest over a stable, canonical representation of the relevant operation. Both client and backend need to produce the same digest for the same action.

A model might include the operation name, request body version, authenticated principal identifier if appropriate, resource identifier, and a server-provided action identifier. Beware subtle differences in serialization order, number formats and Unicode normalization; blindly hashing arbitrary JSON strings on each side often produces mismatches.

Do not include secrets or personal payloads as plain text in requestHash. Google returns the value inside the signed integrity response, so it must be treated as visible request metadata.

For standard Play Integrity requests, the backend sends the token to Google Play for decryption and verification. From the returned verdict it must validate, at minimum, the properties relevant to its policy:

1. The request package name matches the expected application identity.
2. The returned requestHash matches the backend-computed digest of the exact protected action.
3. The token timestamp satisfies the service's freshness requirements.
4. Relevant app and device verdicts meet the risk policy for the operation.
5. The caller's independently authenticated session remains valid.
6. That caller is authorized to operate on the requested resource.

The official verdict documentation emphasizes checking request details before applying verdict-based policy.

This policy sketch intentionally assumes the Play response has already been authenticated by Google's API. It is not a token decoder and should never receive untrusted booleans straight from the Android client.

type VerifiedRequest = {
  packageMatches: boolean
  hashMatches: boolean
  timestampFresh: boolean
  meetsIntegrityPolicy: boolean
  userCanPerformAction: boolean
}

function protectAction(checks: VerifiedRequest): boolean {
  return checks.packageMatches
    && checks.hashMatches
    && checks.timestampFresh
    && checks.meetsIntegrityPolicy
    && checks.userCanPerformAction
}

Notice that the fifth check is still required when the first four succeed. Compromised credentials on an otherwise legitimate app are still compromised credentials.

Google notes that standard requests have built-in replay protections. Do not mechanically copy classic-request nonce handling or Apple's assertion-counter rules into the standard API model. The implementation and the expected semantics are platform-specific.

For a visual introduction to how multiple independent checks interact, open the device trust lab. That simulator is deliberately generic: it models policy gates, not Google's actual attestation protocol.

The authoritative references are Google's standard request flow, verdict interpretation, and the separate OWASP API authorization guidance. Follow the current vendor contract when integrating the SDK; verdict fields and their recommended use may evolve.

Editorial note: Technical reference prepared with AI assistance, not a claim of shipping or testing a production Play Integrity implementation.