A 311 mobile app embeds long-lived static API keys that call backend microservices. Which change best improves service-to-service authentication?
Select an answer to reveal the explanation.
Short Explanation
Hard-coded forever-keys in a phone app are like taping the building master key under the doormat. Use short-lived tokens or mTLS from a proper identity/secret flow—services proving who they are without eternal secrets in the binary.
Full Explanation
Service-to-service authentication for a 311 mobile app must assume client binaries can be reverse-engineered. Long-lived static API keys embedded in the app are high-value, hard-to-rotate secrets once distributed to citizen devices. Replacing them with short-lived tokens (OAuth/OIDC client credentials or similar) or mutual TLS certificates issued through a managed identity and secret workflow shrinks theft impact, enables revocation, and aligns microservice calls with modern workload identity practice.
Moving the same static keys into the mobile UI so citizens can rotate them exposes secrets in a user-visible surface and still relies on long-lived shared material that attackers can scrape. Disabling TLS on the API to simplify client libraries removes transport confidentiality and integrity for citizen and backend traffic—an indefensible trade for convenience. Sharing one eternal API key across all city mobile apps maximizes blast radius: compromise of any app impersonates every service that trusts that key.
Exam caveat: Domains 3 and 5 both punish embedded eternal secrets in distributed clients; prefer short-lived, automatically rotated credentials even when the caller is a mobile front end talking to municipal microservices. Operational check: inventory hardcoded keys in 311 and related apps, migrate callers to a token service or mTLS with automated issuance, monitor for reuse of retired keys, and ensure backend authorization still scopes each client to least-privilege APIs.