Tenant A's JWT must not authorize Tenant B's API paths even when object IDs are guessable. Beyond verifying the JWT signature, what must the API enforce?
Select an answer to reveal the explanation.
Short Explanation
A valid badge for Building A does not open Building B's records room. Check the tenant claim on the token and re-check tenant ownership on every query — guessable IDs are not a security boundary.
Full Explanation
Beyond verifying a JWT signature, a multi-tenant municipal API must combine trusted token claims such as tenantId with server-side tenant checks on every data access. Tenant A's valid token must not authorize Tenant B's API paths even when object IDs are guessable. Signature validation proves authenticity of claims; authorization binds those claims to resource ownership so civic SaaS isolation holds under IDOR-style probing.
Accepting any signed Cognito JWT and authorizing solely by whether the object ID looks random fails because randomness is not an access-control boundary. Skipping claim checks when the caller uses HTTPS fails conceptually—TLS protects the channel, not tenant isolation. Mapping all tenants to one IAM role with dynamodb:* so authorization stays in the network layer fails because network TLS and coarse IAM cannot express per-tenant row ownership.
Exam caveat: checks must use server-trusted claims from signature verification, not client-supplied tenant headers that a caller can forge. Operational check: call Tenant B object paths with a Tenant A token, confirm 403/empty results, and review handlers to ensure every query filters on the authenticated tenantId claim.