Residents should sign into the parks mobile app with the city’s existing social/OIDC identity provider without the app storing passwords. Which approach fits?
Select an answer to reveal the explanation.
Short Explanation
Don’t invent a password vault for the parks app. Federate through Cognito to the city’s existing IdP so residents sign in there—and your app never sees a password.
Full Explanation
Residents signing into the parks mobile app with the city’s existing social or OIDC identity provider should not force the app to store passwords. Amazon Cognito user pool federation (or equivalent IdP integration) lets residents authenticate at the external IdP; Cognito issues tokens to the app after federation, and the mobile client never persists those passwords. That keeps citizen credential custody with the IdP the city already trusts.
Building a custom password table in DynamoDB and hashing in the app recreates identity machinery Cognito and the IdP already provide and expands the breach surface. Embedding a shared IAM access key in the mobile binary grants AWS API power to every reverse engineer. Disabling authentication and relying on URL obscurity is not security for a resident-facing parks app.
Exam caveat: distinguish user pools (app users/federation) from identity pools (AWS credential vending); this question is about sign-in without storing passwords, which is the user-pool/federation path. Operational check: complete a federated login against the city’s OIDC IdP in a test user pool, confirm the app receives tokens without a local password form, and verify no password verifier material is written to DynamoDB by the mobile client.