Amazon Cognito for User Authentication and Authorization

Amazon Cognito is a fully managed service from AWS that handles user sign-up, sign-in, and access control for web and mobile applications. It means you do not have to build your own database of usernames and passwords, create your own login screens, or manage security tokens yourself. AWS does all that heavy lifting for you.

Cognito has two main components: a user pool and an identity pool. These two parts work together but do completely different jobs. A user pool is a directory of users. Think of it as your app's own private phonebook of everyone who has created an account. When a person signs up, Cognito stores their username, email, password (hashed and salted for security), and any other attributes you want, such as their phone number or date of birth. When they sign in later, Cognito verifies their password and, if correct, issues them a JSON Web Token (JWT). A JWT is just a small piece of data that acts like a digital ID card — it contains the user's username, the time they logged in, and when the token expires. The app can read this token to know who the user is without asking the database again.

An identity pool, on the other hand, does not store user information. Its job is to give temporary AWS credentials (like an access key and secret key) to authenticated users so they can access AWS services directly, such as reading a file from S3 or calling a DynamoDB table. The identity pool takes the JWT from the user pool (or another identity provider such as Google or Facebook) and exchanges it for temporary AWS credentials that have a limited set of permissions defined by an IAM role. IAM stands for Identity and Access Management, and it is the AWS system that controls who can do what. The identity pool assigns a role to the authenticated user based on their identity — for instance, all regular users get a role that can read files from a public folder, while admin users get a role that can delete files.

Why does this matter? Before Cognito existed, developers had to build their own authentication systems, which is notoriously difficult to get right. You had to hash passwords correctly, handle password resets, prevent brute-force attacks, manage token expiration, and ensure that tokens could not be forged. Cognito handles all of this for you. It also supports multi-factor authentication (MFA), which means requiring a code from an authenticator app or SMS message in addition to the password. MFA dramatically increases security because an attacker would need both your password and your phone to break in.

Cognito also integrates seamlessly with other AWS services. For the DVA-C02 exam, the most important integration is with API Gateway. API Gateway is a service that lets you create RESTful APIs that front-end apps call. You can configure API Gateway to validate the JWT from your Cognito user pool before a request reaches your backend code. This is called a custom authorizer or a Cognito user pool authorizer. If the token is missing, expired, or invalid, API Gateway rejects the request with a 401 Unauthorized response before any of your Lambda functions run. This protects your backend from unauthenticated traffic.

Another key concept is federated identities. This is the ability for users to sign in using existing accounts from Google, Facebook, Amazon, or Microsoft Entra ID (previously known as Azure Active Directory). Cognito can act as a bridge between these external identity providers and your app. When a user signs in with Google, Cognito receives a token from Google, verifies it, and then issues its own JWT for your app. The identity pool can then use that Cognito JWT to issue AWS credentials. This means users do not need a separate username and password for your app — they can use an account they already have.

Cognito also supports custom workflows through AWS Lambda triggers. For example, you can run a Lambda function after a user signs up to add their email to a marketing list, or before they sign in to check if their account has been suspended. These triggers are called "hooks" and they allow you to extend Cognito's behaviour without modifying its core code.

Finally, Cognito provides a hosted UI (user interface). This is a pre-built, branded sign-up and sign-in page that you can customise with your logo and colours. You do not have to write HTML or CSS for login screens — Cognito serves the page for you. The entire authentication flow happens on AWS infrastructure, which means you do not have to build, secure, or maintain any login pages yourself.

An IT professional building a mobile application for a healthcare startup would use Amazon Cognito in a very specific way. The app allows patients to view their lab results, book appointments, and message their doctor. The startup has three types of users: patients, doctors, and administrators. Each type needs different levels of access.

First, the developer creates a Cognito user pool called "HealthApp-Users". They configure it to require an email address and a password for sign-up. They enable MFA for all users because healthcare data is sensitive. They also set up custom attributes such as "role" (patient, doctor, admin) and "speciality" (for doctors only). When a patient signs up, Cognito sends a verification code to their email. Once verified, the user is stored in the user pool with a confirmed status.

Next, the developer creates an identity pool called "HealthApp-IdentityPool". They configure it to trust the user pool as an authentication provider. They also add Google as an additional provider so that users can sign in with their Google account if they prefer. The identity pool is given two IAM roles: one for unauthenticated users (which has almost no permissions) and one for authenticated users (which grants specific access to AWS resources).

Then the developer creates two API Gateway endpoints: one for retrieving lab results and one for posting appointment bookings. They attach a Cognito user pool authoriser to both endpoints. The authoriser is configured to validate the JWT from the HealthApp-Users user pool. If a request comes without a valid token, API Gateway returns a 401 response before any Lambda function runs.

The backend is a set of AWS Lambda functions that process the requests. When a Lambda function receives a request, it reads the user's role from the JWT claims. The claims are pieces of information embedded in the token, like the user's name and role. If the role is "patient", the function only returns lab results belonging to that patient. If the role is "doctor", the function returns lab results for all patients assigned to that doctor. If the role is "admin", the function can view and delete any record. This authorisation logic is implemented inside the Lambda function because the IAM roles from the identity pool only control access to AWS services, not to specific rows of data.

Finally, the developer uses the Cognito hosted UI for the login page. They customise the page with the healthcare startup's logo and colours. When a user opens the mobile app, it redirects them to the hosted UI. After successful login, Cognito redirects back to the app with tokens. The app stores the JWT locally and includes it in every API call to API Gateway. The entire experience feels seamless to the user, but behind the scenes, Cognito is managing all the security.

In this scenario, the IT professional did not write a single line of code for password storage, token generation, or MFA. They simply configured Cognito through the AWS Management Console or infrastructure-as-code tools like Terraform or AWS CloudFormation. The exam expects you to know exactly how to configure these settings to achieve the right security posture.