API Gateway protects municipal APIs with JWTs issued after Cognito login. What must backends do on each call?
Select an answer to reveal the explanation.
Short Explanation
A JWT is a signed hall pass with an expiration time. Check the signature and claims every call; don’t treat a forever API key or an unsigned blob as “good enough” for resident auth.
Full Explanation
API Gateway–protected municipal APIs that accept Cognito-issued JWTs must validate bearer tokens on each request: cryptographic signature against the issuer’s JWKS, issuer, audience (or client ID), and expiry. That verification—commonly performed by a JWT or Cognito authorizer—ensures only currently valid user sessions reach backends. Static API keys may identify calling applications, but they are not a substitute for per-user session authentication after Cognito login.
Accepting any non-empty Authorization header invites trivial forgery and skips all identity checks. Trusting unsigned JWT payloads because the sub claim “looks familiar” abandons cryptographic authentication. Caching the first token forever and skipping expiry checks allows stolen or revoked sessions to live indefinitely against city APIs.
Exam caveat: distinguish API keys (application identity) from JWTs (user/session identity); DVA-C02 often tests that backends must validate tokens rather than trusting client-supplied claims blindly. Operational check: call the API with a missing token, an expired token, a token with the wrong audience, and a valid token; confirm only the valid case reaches business logic and authorizer metrics/logs show the rejects.