CloudArcade

Guided architecture tour · 6–8 min

Design a sign-in door — Cognito

Plan sign-up and sign-in for a small web app.

This tour teaches architecture decisions. Its services are not provisioned in the emulator.

Your goal

Plan sign-up and sign-in for a small web app.

Why this matters

The app should recognize visitors without giving them your AWS account. You will choose a user directory, check a sign-in token, and protect each person’s own data.

Words you will use

A user pool holds app users and supports sign-in. Authentication asks who you are. Authorization asks what you may access.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

Play this architecture tour

1. Choose app-user sign-in

People need their own accounts for your app. They do not need administrator access to AWS. Choose the Cognito starting point for signing in app users.

What fits this purpose?

A Cognito user pool.

A user pool supports app-user registration and sign-in. An identity pool has a different job: supplying temporary AWS credentials for allowed resources when needed.

App users have a sign-in system separate from AWS administrators.

App visitor → user pool sign-in → signed tokens

2. Check the sign-in proof

The browser sends a token with a request. Anyone can send text that looks like a token. Choose what the API must do before trusting it.

How should the API handle the token?

Check its signature, expected issuer, intended app, and expiry.

A token is proof only after the right checks succeed. Validate the expected token type and claims with a suitable library or authorizer. Do not trust a decoded label alone.

The API accepts only a valid token intended for this use.

Token → verify signature and claims → authenticated identity

3. Keep each profile private

A signed-in user changes a URL from /profiles/alex to /profiles/sam. Signing in proves identity, but not permission to read every profile. Choose the server’s rule.

What must the API check?

Whether this user may access the requested profile.

The server must check ownership or another access rule on every protected request. Hiding a link in the browser does not stop someone from making the request directly.

A signed-in visitor can access only the data the server allows.

Authenticated user + requested record → ownership check

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.

Continue with another AWS learning guide