A mobile 311 app must call city APIs on a resident's behalf without embedding the resident's password in the app. Which technology best fits?
Select an answer to reveal the explanation.
Short Explanation
OAuth is like giving the 311 app a temporary valet ticket to specific APIs—not the resident's house keys. The app acts with a token instead of hauling around the real password.
Full Explanation
A mobile 311 app that calls city APIs on a resident's behalf should not embed or repeatedly transmit the resident's password. OAuth provides delegated authorization: the user authenticates to an authorization server, and the app receives scoped access tokens (and often refresh tokens under controlled conditions) to call APIs without ever handling the long-term password inside the mobile binary. That separation protects municipal residents if the app is reverse-engineered, logs are leaked, or a device is partially compromised, and it allows token revocation and scope limitation independent of the password.
Hard-coding a shared citywide password in the mobile binary is extractable by anyone who unpacks the app and grants shared secret access to city APIs. Sending the user's Active Directory password with every API request in cleartext exposes directory credentials to interception and to every intermediary that sees the request. Granting the mobile app Domain Admin rights is catastrophic over-privilege unrelated to resident 311 workflows.
Exam caveat: OAuth must be implemented with appropriate flows for public native clients (for example PKCE), short-lived access tokens, and least-privilege scopes—simply 'using OAuth' with oversized scopes or embedded secrets still fails. Distinguish authentication (who the user is) from authorization (what the token may do).
Operational check: confirm the 311 app uses authorization-code/PKCE without embedded client secrets or AD passwords, scopes are limited to needed 311 APIs, tokens expire reasonably, and revocation works when a resident reports account abuse.