Citizens need email or social sign-in for a recreation registration app, while city staff will continue using corporate SSO for AWS consoles. Which service should authenticate the citizen end users of the application?

Citizens who need email or social sign-in for a recreation registration app should authenticate with Amazon Cognito user pools, while city staff continue using corporate SSO (often IAM Identity Center) for AWS consoles. Cognito is designed for application end-user directories and federation to social/OIDC IdPs; it is the appropriate citizen identity plane, separate from workforce AWS access—matching how recreation centers issue resident accounts without making residents IAM users in the city’s AWS org.

Creating IAM users for every household that registers for a swim class fails because IAM is for AWS management-plane principals, not consumer app identities at civic scale. Sharing account root users among neighborhood volunteers fails conceptually: root is an emergency account identity and must never be a shared citizen or volunteer login. Assigning IAM Identity Center permission sets directly to anonymous internet browsers fails because Identity Center permission sets grant AWS account access to workforce users, not anonymous browser sessions for a recreation app.

Exam caveat: Cognito secures application authentication; API and data authorization (API Gateway authorizers, app logic, and least-privilege roles) must still enforce what a signed-in citizen can do. Operational check: configure a user pool (and social IdPs if required), place a Cognito authorizer on the registration API, keep staff AWS access on Identity Center, and verify a citizen token cannot call administrative AWS APIs.