Amazon Cognito and federated access: DVA-C03 study notes and practice questions

What to know for the exam

These questions describe an app, its users and the AWS resources it touches, then ask how users should prove who they are and what they may reach.

User pools and identity pools

A user pool is a user directory. It handles sign-up, sign-in and MFA, and it returns three tokens: the ID token (who the user is), the access token (carries OAuth scopes and authorizes calls to your API or to the user pool’s own operations) and the refresh token (gets new tokens). Your API can check a user pool token, for example with an Amazon API Gateway Cognito authorizer: send the ID token when the method has no OAuth scopes, and the access token when it requires a scope. A user pool token does not give access to AWS services. A user pool can also federate social, SAML and OIDC providers and still issue its own tokens, so the backend sees one token format.

An identity pool exchanges an identity from a user pool, a social provider, or a SAML or OIDC provider for temporary AWS credentials. It does this by assuming an IAM role: an authenticated role for signed-in users and, if you turn it on, an unauthenticated role for guests.

Use the pair this way:

• A user pool alone when users sign in to reach your own API.
• A user pool plus an identity pool when a browser or mobile app must call S3, DynamoDB or another AWS service directly with temporary credentials.
• An identity pool with the unauthenticated role for guests who may read public content and nothing else.

Groups and role mapping

Each user pool group can be linked to an IAM role with a precedence value. The ID token’s cognito:preferred_role claim names the role of the group with the lowest precedence value, and an identity pool set to choose role from token uses that claim. Roles are not merged.

Per-user data in S3

You do not need one role per user. Write one role’s policy against the resource with an identity variable, such as ${cognito-identity.amazonaws.com:sub}, so each user can reach only a folder named after their own identity ID. This is the usual answer when the wording says “each user, only their own folder.”

Client secrets and public apps

A browser or mobile app cannot keep a secret. Create the app client without a client secret and use the authorization code grant with PKCE. A secret cannot be removed from or added to an existing app client, so create a new one. Give a client secret only to a server-side app, such as a machine-to-machine client using the client credentials grant, which returns only an access token.

MFA and triggers

A user pool can set MFA to off, optional or required, with TOTP, SMS or email codes. Federated users are authenticated by their own identity provider, so the pool’s MFA setting does not apply to them.

Lambda triggers run code at set points: pre sign-up can reject a new user, post confirmation runs after a self-signed-up user confirms (a good place to create a profile), pre token generation adds or changes claims at sign-in and refresh, and migrate user moves users from an old directory on their first sign-in. Custom attributes cannot be renamed, deleted or changed in type after they are created.

How to choose

Common traps

• A client secret in a browser or mobile app.
• Expecting a user pool token to grant AWS service permissions.
• Using an identity pool to check who calls your own API, instead of a user pool token.
• Giving each user an IAM user with long-term access keys.
• Assuming group permissions combine. Only one group’s role applies.

Side by side: Cognito user pools vs identity pools

Try the 3 practice questions ↓