Application user sign-in: SAA-C03 study notes and practice questions
What to know about Application user sign-in for the SAA-C03 exam, from the Design Secure Architectures domain (30% of the exam guide), then 1 free question to test it. Part of the SAA-C03 study guide.
When a scenario is about the customers of an application signing in, rather than employees accessing AWS, the answer is almost always Amazon Cognito. The trick is knowing which part of Cognito.
User pools vs identity pools
User pool
Identity pool
Purpose
Authentication: who is this user?
Authorization to AWS: give this user temporary AWS credentials
Gives you
JSON Web Tokens (ID, access and refresh tokens)
Temporary credentials for an IAM role
Features
Sign-up, sign-in, MFA, password reset, hosted sign-in pages, social and SAML/OIDC federation
Authenticated and guest (unauthenticated) roles, role mapping by claim
Typical use
Sign in to your app; protect an API Gateway API or ALB
Let a mobile app upload directly to S3 or write to DynamoDB
Key facts
API Gateway can validate user pool tokens with a Cognito authorizer, with no code. An Application Load Balancer can also authenticate users through Cognito or any OIDC provider before requests reach your targets.
Per-user access to AWS resources: with an identity pool, a policy variable such as ${cognito-identity.amazonaws.com:sub} in the role’s policy limits each user to their own S3 prefix or DynamoDB items.
Federation: user pools can sign users in with Google, Facebook, Apple, Amazon, or any SAML or OIDC identity provider, so the app sees one kind of token.
Workforce vs customers: employees signing in to AWS accounts use IAM Identity Center; customers signing in to your application use Cognito.
How to choose
“Add sign-up and sign-in with social logins to a web or mobile app”: user pool.
“Mobile users must upload photos directly to S3, each to their own folder”: user pool plus identity pool, with a policy variable.
“Only signed-in users may call the API, with least effort”: Cognito authorizer on API Gateway.
“Employees use the corporate directory to access the AWS console”: IAM Identity Center, not Cognito.
Common traps
Embedding access keys in a mobile app. Never; use an identity pool for temporary credentials.
Building your own user database and token service when Cognito does it as a managed service.
Picking an identity pool alone for “sign-in”. Identity pools don’t hold users; they trust an identity provider such as a user pool.
Users must be able to sign up with an email address and password, or sign in with their Google account. After sign-in, the app uploads photos straight to Amazon S3, and each user may write only under their own prefix in the bucket. The company does not want to run its own sign-in servers or put long-term keys in the app.
Which solution meets these requirements with the LEAST custom code?
Choose one answer.
AA. Use a Cognito user pool with Google federation, and a Cognito identity pool whose role limits S3 writes to each user's identity ID prefix.
BB. Use IAM Identity Center with Google as the external identity provider, and give each user a permission set that allows S3 uploads.
CC. Use a Cognito user pool with Google federation, and have the app send the user pool's ID token straight to S3 with each upload.
DD. Have the app call AWS STS AssumeRoleWithWebIdentity with the Google ID token, using a role that limits S3 writes to a per-user prefix.
Show the answer and explanation
Answer: A
A. Right: Correct. The user pool handles email sign-up and Google sign-in. The identity pool swaps the user pool token for temporary AWS credentials, and the role's policy uses the ${cognito-identity.amazonaws.com:sub} variable so each user can write only under their own prefix. Learn more: Accessing AWS services using an identity pool after sign-in (opens in a new tab)
B. Wrong: IAM Identity Center is for a company's workforce signing in to AWS accounts and business applications, not for customers of a mobile app. It also has no self-service email sign-up for the public. Amazon Cognito is the customer identity service. Learn more: Choosing an AWS identity service (opens in a new tab)
C. Wrong: The user pool covers sign-up and sign-in, but S3 does not accept user pool tokens. Requests to S3 must be signed with AWS credentials. An identity pool is needed to exchange the token for temporary credentials. Learn more: What is Amazon Cognito? (opens in a new tab)
D. Wrong: This gives Google users temporary credentials, but it offers nothing for people who sign up with an email address and password. AWS recommends Amazon Cognito for mobile apps rather than calling this API directly. Learn more: AssumeRoleWithWebIdentity (opens in a new tab)
Explanation
Amazon Cognito user pools provide sign-up and sign-in for app users, including federation with Google. Cognito identity pools then give signed-in users temporary AWS credentials through an IAM role, and a policy variable on the identity ID keeps each user to their own S3 prefix. IAM Identity Center is for the workforce, and S3 cannot read user pool tokens directly.
The user pool handles Google sign-in, and the identity pool's role keeps each user to their own identity ID prefix.
Want more on Application user sign-in? The 5 full-length practice sets have 10 more Application user sign-in questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →