A county mobile permitting app obtains short-lived access tokens from an identity service instead of embedding long-lived passwords in the client binary. Which authentication pattern is the team applying?
Select an answer to reveal the explanation.
Short Explanation
Imagine handing the app a temporary visitor badge instead of engraving the master key into the phone. Short-lived tokens get checked and expire, so a stolen binary is far less useful than a password baked into the build. That is the whole idea behind token-based auth for mobile clients.
Full Explanation
Token-based authentication issues short-lived credentials from an identity service so clients do not embed long-lived passwords in binaries. A county mobile permitting app that obtains short-lived access tokens follows that pattern, limiting blast radius if a device or app build is extracted and avoiding static secrets baked into citizen-facing installs.
Hard-coding shared database credentials into every citizen-facing mobile build is the anti-pattern tokens replace. Disabling token expiry so sessions never need renewal across device upgrades recreates long-lived credential risk. Granting each phone a permanent cloud owner role for unrestricted API calls vastly over-privileges endpoints.
Exam caveat: tokens still need TLS, secure storage on device, refresh handling, and audience/scope restrictions. OAuth/OIDC commonly implement token patterns for apps.
Operational check: confirm the app requests tokens from the IdP/token endpoint, verify access tokens expire quickly, ensure no static DB passwords exist in the mobile build, and revoke/refresh flows work when a device is lost. Document token lifetimes in the county API security standard.
Instrument API gateways to reject missing/expired tokens on permitting endpoints and alert on sudden spikes in token errors that may indicate a broken mobile release or an abuse attempt against county services.