
AWS Auth
OfficialFreeStreamline user authentication with Amazon Cognito.
Free · Opens the source repo
What AWS Auth does
AWS Auth skill provides developers with a robust framework for integrating user authentication and authorization into web and mobile applications using Amazon Cognito. This skill focuses on the essential components of Cognito, including user pools and identity pools, and leverages the AWS Amplify client auth libraries to manage user sign-up and sign-in flows efficiently. It simplifies the implementation of multi-factor authentication (MFA), password policies, and various OAuth 2.0 flows, including authorization code grants with PKCE, ensuring secure access to your applications.
The skill is particularly useful for those looking to implement a login or sign-up page, configure user pools or app clients, and manage social or SAML federations. It also covers token management, including ID, access, and refresh tokens, along with their rotation and revocation. By using AWS Auth, developers can gate API Gateway routes to ensure that only authenticated users can access specific resources, enhancing the security of their applications.
While the skill is comprehensive, it is important to note its limitations. It does not cover Amplify Gen2 backend definitions or IAM/STS configurations, focusing solely on Cognito and JWT authorizer setups. This makes it ideal for developers who need to implement user authentication without delving into broader AWS service configurations. The skill also emphasizes best practices, such as avoiding the use of implicit grants for new applications and the importance of secure token storage, which are critical for maintaining application security.
Overall, AWS Auth is a valuable tool for developers and designers aiming to implement secure user authentication in their applications. Its clear guidance on using Cognito effectively, along with its focus on best practices, ensures that users can navigate the complexities of AWS authentication with confidence.
When to use it
Use this skill when you need to implement user authentication in web or mobile applications using Amazon Cognito.
When not to use it
Avoid this skill if you require detailed IAM policy configurations or need to set up API Gateway integrations beyond Cognito authorizers.
What you can build with it
Implementing User Sign-Up
Use this skill to set up a user sign-up page with Amazon Cognito, allowing users to create accounts securely.
Managing User Authentication Flows
Integrate sign-in flows and MFA using Cognito, ensuring that user access is managed effectively and securely.
Securing API Access
Gate access to API Gateway routes based on user authentication status, using Cognito tokens to enforce security.
How to install AWS Auth
View source1. Install with the skills CLI
npx skills add aws/agent-toolkit-for-aws/aws-auth --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by awsAWS 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.
Quick Navigation
| 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
cookieStorageoverlocalStorage. - 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 asaws-jwt-verifyrather 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), andX-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).
Frequently asked questions about AWS Auth
Similar skills
WinMD API Search
Easily find and explore Windows desktop APIs.
WebMCPify
Transform any web app into an agent-ready platform.
Phoenix Tracing
Instrument LLM applications with OpenInference tracing.
Foundry Hosted Agent CopilotKit
Guidance for developing agentic web apps on Azure.
Power Automate Foundation
Connect AI agents to Power Automate seamlessly.
Power Automate Flow Builder
Efficiently build and deploy Power Automate flows programmatically.
