A read-only open-data client token must not be able to call write endpoints on the same municipal API. How should access be enforced?
Select an answer to reveal the explanation.
Short Explanation
A library card should not unlock the vault. Enforce scopes or claims at the authorizer so a read-only open-data token cannot POST or DELETE. One JWT-to-rule-them-all is how open data turns into open season.
Full Explanation
A read-only open-data client token must not authorize write endpoints on the same municipal API. Enforce OAuth scopes or equivalent claims inside the API Gateway authorizer (and optionally again in application code) so tokens minted for read-only clients succeed on catalog GET routes but fail authorization on POST, PUT, and DELETE. Scope separation keeps partner and public read clients from mutating authoritative city data even if they present a cryptographically valid JWT.
Ignoring scopes and authorizing every valid JWT for all methods collapses least privilege at the API layer. Using the same client credentials for citizens and batch admins without distinct claims prevents differentiating read versus administrative power. Publishing write API keys in the open-data portal README advertises privileged credentials to anyone browsing the docs.
Exam caveat: authentication proves the token is genuine; authorization decides whether that subject may perform the requested operation—DVA-C02 expects both layers on protected municipal APIs. Operational check: obtain a read-only token, call a GET successfully, call a write route and expect 403, then repeat with a write-scoped admin token and confirm only the privileged client can mutate resources while authorizer logs show the scope-based denials.