AWS Auth

AWSOfficialPublished by AWS

Skill
Tool integration
Cloud and DevOps
Apache-2.0
No issues found

From the author

Adds user authentication to web and mobile apps with Amazon Cognito (user pools and identity pools) and the AWS Amplify client auth libraries. Covers sign-up/sign-in flows and the login page (Cognito-hosted UI / managed login), MFA, password policies, OAuth 2.0 / OIDC flows (auth-code + PKCE, client credentials), social/SAML federation, tokens (ID/access/refresh, rotation, revocation, storage), Cognito Lambda triggers, identity pools (temp AWS creds), and gating API Gateway (or ALB) routes to signed-in users via Cognito/JWT authorizers. Applies when adding a login or sign-up page, configuring a user pool or app client, choosing user pool vs identity pool, wiring social/SAML, refreshing tokens, requiring sign-in on an API Gateway or ALB, or debugging redirect_uri/token/MFA/CORS/federation errors. Does NOT cover Amplify Gen2 backend definitions (defineAuth, npx ampx → aws-amplify), IAM/STS/Identity Center (→ aws-iam), or API Gateway/Lambda resource config beyond the authorizer (→ aws-serverless).

— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides guidance on integrating Amazon Cognito user pools and identity pools into web and mobile applications. It covers the full lifecycle of authentication, including sign-up/sign-in flows, managed login, MFA, OAuth 2.0/OIDC standards, and token management. It also details how to secure API Gateway or ALB routes using Cognito authorizers and how to vend temporary AWS credentials to clients via identity pools. The skill emphasizes secure practices, such as using PKCE for public clients and avoiding common pitfalls like client secret exposure or improper identity pool role configuration.

What it does

Configures Amazon Cognito user pools for user directory and authentication management.
Implements OAuth 2.0 and OIDC flows, including authorization code grant with PKCE.
Secures API Gateway and ALB routes using Cognito/JWT authorizers.
Manages identity pools to provide temporary AWS credentials to authenticated clients.
Handles token lifecycle, including rotation, revocation, and secure storage.
Integrates social and SAML federation for external identity providers.

When to use it

When adding sign-up or login functionality to a web or mobile application.
When you need to gate API endpoints to ensure only authenticated users can access them.
When your client application requires direct access to AWS services like S3 or DynamoDB.
When configuring MFA, password policies, or custom authentication challenges.
When troubleshooting authentication errors like redirect mismatches, CORS issues, or token validation failures.

Advantages

Provides clear distinctions between user pools and identity pools to prevent common architectural errors.
Highlights critical security practices like avoiding client secrets in public clients.
Includes specific guidance on avoiding destructive 'full replace' API calls.
Offers a structured approach to troubleshooting common authentication and federation issues.
Aligns with industry-standard security patterns for token handling and API protection.

Usage examples

“How do I set up a user pool for a React app with hosted UI?”: The agent provides steps to create a user pool, configure a public app client, enable the hosted UI with authorization code grant and PKCE, and wire the Amplify client library.
“My API Gateway is returning 401 errors for valid tokens, what should I check?”: The agent guides you to verify the token type, check the issuer and audience configuration in the JWT authorizer, and ensure the correct token is being sent in the Authorization header.
“How do I allow my mobile app users to upload files directly to S3?”: The agent explains how to set up an identity pool that trusts your user pool, maps authenticated users to an IAM role with S3 permissions, and vends temporary credentials.
“How do I add Google login to my Cognito user pool?”: The agent outlines the process of registering Google as an IdP in the user pool, mapping attributes, and updating the app client to include the provider.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/aws/aws-auth/download
Unzip it into the cross-client skills folder of your project:
```
mkdir -p .agents/skills && unzip aws-auth.zip -d .agents/skills
```

Documentation by AWS

AWS Auth (Amazon Cognito)

Application-level user authentication and authorization with Amazon Cognito and the Amplify client auth libraries. Verify specific limits, quotas, and exact API shapes against official AWS documentation when precision matters; trust the docs over memory when they conflict.

Recommended: The AWS MCP server provides streamlined access to the AWS APIs used in this skill (Cognito user pool/app client/identity pool setup, API Gateway authorizers). If it is unavailable, the AWS CLI commands shown throughout work directly — the skill has no hard dependency on MCP.

When NOT to use: Amplify Gen2 backend code (defineAuth, amplify/auth.ts, npx ampx); IAM policy/role/trust-policy authoring, STS, or IAM Identity Center console SSO; API Gateway route/integration setup or Lambda function implementation (this skill covers only the Cognito/JWT authorizer configuration and the purpose of Cognito Lambda triggers).

User Pool vs Identity Pool — pick first

These are different services that are frequently confused. Most apps need a user pool; add an identity pool only if the client must call AWS services directly.

You need...	Use	Why
Sign-up / sign-in, user directory, issue JWTs	User pool	It authenticates users and is an OIDC IdP
The signed-in client to call S3/DynamoDB/etc. directly with AWS credentials	Identity pool	It exchanges a token for temporary AWS credentials via STS
Both (sign in, then hit AWS resources from the browser/app)	User pool → identity pool	Identity pool trusts the user pool as its IdP

If your app only calls your own backend/API, you do not need an identity pool — send the user pool token to your API. See identity-pools.md.

Critical Warnings

update-user-pool-client and set-identity-pool-roles are FULL REPLACE, not partial updates: Any field you omit is reset to its default — calling update-user-pool-client with only the fields you want to change silently wipes ExplicitAuthFlows, token validity, EnableTokenRevocation, refresh-token rotation, and read/write attributes; set-identity-pool-roles likewise replaces the whole roles + RoleMappings structure. Always read-modify-write: describe-user-pool-client (or get-identity-pool-roles) first, then re-send every existing field plus your change. In an agent context the wipe is invisible — the call succeeds and only breaks later when a user hits the missing flow. See managed-login-oauth.md and identity-pools.md.

Don't use the implicit grant for new apps: The implicit grant (response_type=token) is legacy and returns tokens in the URL fragment. Use the authorization code grant with PKCE (response_type=code + code_challenge) for SPAs and mobile — public clients, no client secret. See managed-login-oauth.md.

Don't store refresh tokens in localStorage for high-value apps: localStorage is readable by any injected script (XSS). The Amplify client library defaults to localStorage; switch to cookieStorage, keep refresh-token lifetime short, and enable refresh token rotation + token revocation on the app client. See tokens-and-sessions.md.

Access-token claim customization needs a paid feature plan: The pre token generation trigger customizes the ID token on the entry-level plan (V1), but customizing the access token (V2/V3) requires a paid feature plan — check the Cognito feature plans documentation for which plan currently includes this, as plan names and inclusions can change. Don't assume access-token claims work on the entry-level plan. See lambda-triggers.md.

App client secret + SPA = broken auth: A public client (browser/mobile) must have no client secret. If a secret is set, token calls fail unless a SECRET_HASH is sent, which a browser cannot protect. Generate a secret only for confidential (server-side) clients.

Don't bulk admin-confirm-sign-up UNCONFIRMED users: When users are stuck UNCONFIRMED, prefer resend-confirmation-code so each user re-verifies via confirm-sign-up and proves email ownership (the code likely expired or went to spam). admin-confirm-sign-up flips the status instantly but confirms the account without verifying the email — the attribute stays unverified, which is dangerous when email drives password reset or account linking. Reserve it for trusted/migrated accounts. See troubleshooting.md.

You want to...	Go to
Create a user pool, sign-up/sign-in, MFA, password policy, app clients	user-pools.md
Add hosted UI / managed login, OAuth flows, social or SAML login, callback URLs, custom domain (ACM in us-east-1)	managed-login-oauth.md
Handle ID/access/refresh tokens, rotation, revocation, session termination (global sign-out vs revoke vs disable)	tokens-and-sessions.md
Give the client temporary AWS credentials, guest access, role mapping	identity-pools.md
Protect an API Gateway API with Cognito tokens (and enforce custom claims in the backend)	api-authorization.md
Add Cognito login in front of an Application Load Balancer (ALB `authenticate-cognito`)	api-authorization.md
Machine-to-machine (client credentials) auth, resource servers, custom scopes	managed-login-oauth.md
Create user pool groups and add users to them (`cognito:groups`, `Precedence`)	user-pools.md
Customize claims, custom auth challenge flows, migrate users, validate sign-up	lambda-triggers.md
Add passkey / WebAuthn sign-in (`USER_AUTH` flow, `AllowedFirstAuthFactors`, WebAuthn enrollment)	passkeys.md
Configure threat protection — compromised-credentials block, adaptive auth (risk-based MFA), log delivery to CloudWatch	threat-protection.md
Something is broken (redirect, token, MFA, CORS, social login)	troubleshooting.md

Common Workflows

"Add sign-up and login to my React app" → Create a user pool + a public app client (no secret), enable the hosted UI / managed login with the authorization code grant with PKCE, wire the Amplify client library. See user-pools.md and managed-login-oauth.md.

"Add Google / social login" → Register the social IdP on the user pool, map attributes, add the provider to the app client and hosted UI. See managed-login-oauth.md.

"Only authenticated users should call my API" → HTTP API → JWT authorizer; REST API → Cognito user pools authorizer. See api-authorization.md.

"Let the browser upload to S3 after login" → User pool for sign-in, then an identity pool to vend scoped temporary credentials. See identity-pools.md.

Troubleshooting

Error/Symptom	Likely Cause	Quick Fix
`redirect_mismatch` / redirect to wrong URL after login	Callback URL not registered, or scheme/trailing-slash/case differs	Add the exact callback URL (incl. scheme and path) to the app client's Allowed callback URLs
Token calls fail with "unable to verify secret hash"	Client secret set on a public (SPA/mobile) client	Recreate the app client with no secret, or send `SECRET_HASH` from a confidential client
Users get 401 from API Gateway with a valid token	Wrong token type or audience/issuer mismatch	HTTP JWT authorizer: issuer `https://cognito-idp.{region}.amazonaws.com/{userPoolId}`, audience = app client id; send the token the authorizer expects
CORS errors calling the hosted UI / token endpoint	Browser calling `/oauth2/token` cross-origin, or missing CORS on your API	Do the code exchange with PKCE; don't proxy the token endpoint from the browser
Social login user "already exists" / attribute conflict	Same email across providers creates separate users	Enable attribute mapping + account linking; treat email as non-unique across IdPs

Full tables in troubleshooting.md.

Security Considerations

Public clients (SPA/mobile): no client secret, authorization code grant with PKCE, request least-privilege scopes.
Enable MFA (TOTP or SMS), a strong password policy, and advanced security / threat protection where available.
Short access-token lifetime; enable refresh token rotation and token revocation; prefer cookieStorage over localStorage.
Identity pools: scope the authenticated IAM role tightly; disable unauthenticated (guest) access unless required.
Validate JWTs against the user pool JWKS (iss, aud/client_id, token_use, exp) on every protected request. Use a maintained library such as aws-jwt-verify rather than hand-rolling verification.
Set security headers on the app's web pages: Content-Security-Policy (restrict script sources to mitigate token-stealing XSS), Strict-Transport-Security (HSTS), X-Frame-Options/frame-ancestors (clickjacking on login pages), and X-Content-Type-Options: nosniff.
Enable logging and monitoring: CloudTrail for Cognito API events (sign-up/sign-in/admin), user pool threat protection (adaptive auth + event logging), CloudWatch alarms on failed/throttled auth, and API Gateway access logging for authorizer decisions.
All Cognito and API endpoints are HTTPS/TLS only; enable encryption at rest with a customer-managed KMS key (and restricted key access) on CloudWatch Log groups, SNS topics used for MFA/notifications, and any identity-pool-fronted upload buckets.
If using SNS for MFA/notification delivery, enable server-side encryption (KMS) on the topic, and keep SMS/email message content limited to what the recipient needs — don't include more PII than the message requires.
References: Amazon Cognito security features (user pools), Amazon Cognito security (top-level, incl. identity pools), and IAM/STS best practices.

Where to Look When This Skill Is Silent

When you need depth beyond this skill — exact parameter shapes, current limits, edge behaviors — fall back to the authoritative AWS sources rather than guessing. Pointers age much slower than content, so this map stays useful without the skill having to grow.

API reference (exact params, defaults, errors): Cognito User Pools API and Cognito Identity API
Developer Guide (concepts, workflows): Amazon Cognito Developer Guide
Quotas, rate limits, session-cookie lifetime: Cognito quotas
Feature plans / tier gating: Cognito feature plans
Pricing: Amazon Cognito pricing
CLI reference: aws cognito-idp and aws cognito-identity

Not Covered By This Skill

Amplify Gen2 backend (defineAuth, amplify/auth.ts, npx ampx sandbox).
IAM policy/role/trust-policy authoring, STS, IAM Identity Center console SSO.
API Gateway route/integration setup and Lambda function implementation (this skill covers only the Cognito/JWT authorizer configuration and the purpose of Cognito Lambda triggers).

Files

ATTRIBUTION.mdAdded by AutoGineer881 B
LICENSELicence file added by AutoGineer9.9 KiB
NOTICELicence file added by AutoGineer67 B
SKILL.md13.5 KiB
references/api-authorization.md5.0 KiB
references/identity-pools.md5.8 KiB
references/lambda-triggers.md9.9 KiB
references/managed-login-oauth.md15.4 KiB
references/passkeys.md4.9 KiB
references/threat-protection.md5.9 KiB
references/tokens-and-sessions.md11.2 KiB
references/troubleshooting.md4.6 KiB
references/user-pools.md8.5 KiB

references/user-pools.md

Cognito User Pools

Overview

A user pool is a managed user directory and OpenID Connect (OIDC) identity provider. It handles sign-up, sign-in, MFA, password policies, and issues JWTs (ID, access, refresh). Use this reference to create and configure a user pool and its app clients.

# Create the pool first. Do NOT pass --mfa-configuration ON|OPTIONAL to create-user-pool:
# at create time that requires --sms-configuration (an SmsConfiguration with an SnsCallerArn)
# or the call fails with InvalidParameterException. Enable MFA after creation (below).
aws cognito-idp create-user-pool \
  --pool-name my-app-users \
  --auto-verified-attributes email \
  --username-attributes email \
  --policies '{"PasswordPolicy":{"MinimumLength":12,"RequireUppercase":true,"RequireLowercase":true,"RequireNumbers":true,"RequireSymbols":true}}'

# Require MFA and enable the TOTP (software token) factor — no SMS/SNS needed for TOTP.
aws cognito-idp set-user-pool-mfa-config \
  --user-pool-id <pool-id> \
  --mfa-configuration ON \
  --software-token-mfa-configuration Enabled=true

The example uses a strong default (12+ chars, all character classes, mandatory TOTP MFA). A shorter/relaxed password policy or a non-mandatory MFA posture is possible but should be treated as a non-production exception — for example, in a local/dev-only pool:

# Development-only variant, for local testing — do not use in production.
# Same rule: don't pass --mfa-configuration to create-user-pool; relax MFA (OPTIONAL/OFF) via
# set-user-pool-mfa-config afterward if you need it.
aws cognito-idp create-user-pool \
  --pool-name my-app-users-dev \
  --auto-verified-attributes email \
  --username-attributes email \
  --policies '{"PasswordPolicy":{"MinimumLength":12,"RequireUppercase":true,"RequireLowercase":true,"RequireNumbers":true,"RequireSymbols":true}}'

--username-attributes email lets users sign in with their email as the username. Choose this or --alias-attributes; it is fixed at creation and cannot be changed later.
--auto-verified-attributes email sends a verification code on sign-up.
The feature plan (tier) governs advanced features (threat protection, access-token customization, email OTP). The tiers are Lite (entry-level), Essentials, and Plus; set the tier via --user-pool-tier where supported. Which tier includes a given feature can change, so verify feature-to-tier inclusion against the Cognito feature plans docs.

App clients

An app client represents one application that talks to the pool. Create one per app/frontend.

# Public client (SPA / mobile): NO secret; token revocation + refresh rotation enabled.
# NOTE: with rotation enabled, do NOT include ALLOW_REFRESH_TOKEN_AUTH — that flow is
# incompatible with refresh-token rotation. Refresh via GetTokensFromRefreshToken instead.
aws cognito-idp create-user-pool-client \
  --user-pool-id <pool-id> \
  --client-name web-spa \
  --no-generate-secret \
  --explicit-auth-flows ALLOW_USER_SRP_AUTH \
  --enable-token-revocation \
  --refresh-token-rotation Feature=ENABLED,RetryGracePeriodSeconds=30

# Confidential client (server-side): WITH secret; token revocation + refresh rotation enabled.
# Set --explicit-auth-flows explicitly so the default set (which includes ALLOW_REFRESH_TOKEN_AUTH)
# is not picked up — again, that flow conflicts with rotation.
aws cognito-idp create-user-pool-client \
  --user-pool-id <pool-id> \
  --client-name backend \
  --generate-secret \
  --explicit-auth-flows ALLOW_USER_SRP_AUTH \
  --enable-token-revocation \
  --refresh-token-rotation Feature=ENABLED,RetryGracePeriodSeconds=30

Rule: public clients (browser/mobile) MUST use --no-generate-secret. A secret on a public client breaks token calls because the browser cannot protect the SECRET_HASH. Generate a secret only for confidential clients running on a server you control.

Refresh-token rotation makes the ALLOW_REFRESH_TOKEN_AUTH (REFRESH_TOKEN_AUTH) flow unavailable at runtime: an app client with rotation enabled cannot use InitiateAuth/AdminInitiateAuth with AuthFlow=REFRESH_TOKEN_AUTH — that call is rejected. So omit ALLOW_REFRESH_TOKEN_AUTH from --explicit-auth-flows when rotation is on (and set the flows explicitly on the confidential client so it isn't inherited from the default set), and refresh tokens with the GetTokensFromRefreshToken API instead.

Prefer SRP (ALLOW_USER_SRP_AUTH) over ALLOW_USER_PASSWORD_AUTH so raw passwords never leave the client. Enable ALLOW_USER_PASSWORD_AUTH only for migration or server-side flows.

MFA

--mfa-configuration = OFF | OPTIONAL | ON. Default to ON (mandatory) for production pools. OPTIONAL (opt-in) or OFF are non-production exceptions — mark them clearly as such when used. Set MFA with set-user-pool-mfa-config, not create-user-pool: create-user-pool --mfa-configuration ON|OPTIONAL only succeeds if you also pass --sms-configuration (an SmsConfiguration with an SnsCallerArn), otherwise it fails with InvalidParameterException. For TOTP or email MFA (no SMS), leave MFA unset at creation and configure it afterward with set-user-pool-mfa-config.
Software TOTP (authenticator apps) is the recommended second factor; SMS incurs cost and is weaker. Enable TOTP with set-user-pool-mfa-config --software-token-mfa-configuration Enabled=true — note this call alone only makes TOTP available; --mfa-configuration (above) is what actually requires it.
Email OTP as a factor requires a supported feature plan.

Action	API
Register a user	`sign-up` (public) or `admin-create-user` (admin)
Confirm sign-up	`confirm-sign-up` with the emailed code, or `admin-confirm-sign-up`
Sign in	`initiate-auth` (SRP or `USER_PASSWORD_AUTH`) → returns tokens or a challenge
Respond to MFA/other challenge	`respond-to-auth-challenge`
Forgot password	`forgot-password` → `confirm-forgot-password`

Most web/mobile apps should use the hosted UI / managed login or the Amplify client library instead of calling these APIs directly. See managed-login-oauth.md and tokens-and-sessions.md.

Custom attributes

Add custom attributes at creation with a custom: prefix (e.g. custom:tenant_id). You can also add them after the pool exists with aws cognito-idp add-custom-attributes (up to 50 custom attributes total). Once defined, a custom attribute cannot be renamed or deleted, and its mutability is fixed — mark mutable attributes explicitly at definition time.

User pool groups

Groups let you label users and (optionally) attach an IAM role for identity-pool role mapping.

aws cognito-idp create-group \
  --user-pool-id <pool-id> --group-name admins \
  --role-arn <admins-role-arn> --precedence 1

aws cognito-idp admin-add-user-to-group \
  --user-pool-id <pool-id> --username <user> --group-name admins

A user's groups appear in the cognito:groups claim; the chosen group role surfaces as cognito:preferred_role.
--precedence breaks ties when a user belongs to multiple groups: the group with the lowest precedence value wins for cognito:preferred_role / identity-pool "role from token". Lower number = higher priority.
This is what the identity-pool "role from token" selection in identity-pools.md depends on.

Common Errors

Error	Cause	Fix
`InvalidParameterException: Cannot modify the username attributes`	`username-attributes` fixed at creation	Recreate the pool with the desired setting
`NotAuthorizedException: Unable to verify secret hash`	Secret set on a client used without `SECRET_HASH`	Use a no-secret public client, or compute `SECRET_HASH` server-side
`UsernameExistsException`	User already registered	Use sign-in or `admin-get-user`; for social users see federation notes

managed-login-oauth.md for the login UI and OAuth flows.
tokens-and-sessions.md for what to do with the tokens.
lambda-triggers.md to validate sign-up or customize the flow.

Authoritative sources

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

AWS

Publisher

AWS (Official)

Source

aws/agent-toolkit-for-aws · skills/core-skills/aws-auth · commit 0a218f8

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
NOTICE (added by AutoGineer from NOTICE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

Also distributed in

aws/agent-toolkit-for-aws

AutoGineer is not affiliated with or endorsed by AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aws-auth.zip