Amazon Cognito

Amazon Cognito คือบริการจัดการ identity สำหรับ web/mobile app ช่วยให้ผู้ใช้ภายนอก (external users) ลงทะเบียนและล็อกอินได้แบบ serverless โดยไม่ต้องดูแล server เอง แตกต่างจาก IAM ที่ออกแบบสำหรับ user ภายในองค์กร (จำนวนหลักร้อย) ส่วน Cognito รองรับ user นับล้านได้

Cognito แบ่งเป็น 2 บริการหลักที่มักสับสนกันในข้อสอบ และมัก ใช้ร่วมกัน เป็น chain

• Cognito User Pools (CUP) = serverless user directory ทำหน้าที่ authentication (sign-up/sign-in) และออก JWT tokens
• Cognito Identity Pools (CIP / Federated Identities) = แลก identity/token เป็น temporary AWS credentials ผ่าน STS เพื่อเข้าถึง AWS resources โดยตรง
• Cognito Sync = sync ข้อมูล user preferences ข้ามอุปกรณ์ — ปัจจุบัน deprecated (ใช้ AWS AppSync แทน)

Cognito User Pools (CUP) เป็น serverless user directory ที่จัดการ database ของผู้ใช้สำหรับ web/mobile app รองรับ sign-up/sign-in ทั้งแบบ username/password และผ่าน external IdP เมื่อ login สำเร็จ CUP จะออก JWT tokens กลับมา

ฟีเจอร์หลักของ User Pools

• รองรับ simple login (username/email + password)
• Password policy กำหนดความยาวขั้นต่ำและประเภทตัวอักษร (uppercase/lowercase/number/special)
• MFA (Multi-Factor Authentication) รองรับ SMS และ TOTP (software token)
• Email & phone number verification
• รองรับ federation กับ Social (Google/Facebook/Amazon/Apple), OIDC และ SAML
• Hosted UI หน้า login/sign-up สำเร็จรูป
• Lambda triggers รันโค้ด custom ในจังหวะต่างๆ ของ auth flow
• Account takeover protection / Adaptive authentication (Advanced Security)

เมื่อ authenticate กับ CUP สำเร็จ จะได้ JWT (JSON Web Tokens) 3 ประเภท ซึ่งข้อสอบชอบถามความแตกต่างของหน้าที่และอายุ

Hosted UI เป็นหน้าเว็บ sign-in/sign-up สำเร็จรูปที่ AWS host ให้ ปรับแต่ง logo และ CSS ได้ ใช้ custom domain ได้ (ต้องมี ACM certificate ใน us-east-1) และรองรับ social/SAML/OIDC federation ในตัว ช่วยลดงานสร้าง frontend authentication

App Client คือ entity ที่ represent แต่ละแอปที่เชื่อมกับ User Pool กำหนด config เช่น token validity, allowed OAuth flows & scopes, callback/logout URLs และ client secret (สำหรับ server-side app — ไม่ควรใช้ใน public/SPA/mobile)

Lambda Triggers ที่พบบ่อย

• Pre Sign-up / Pre Authentication — validate ก่อนสมัคร/ก่อน login
• Post Confirmation / Post Authentication — ทำงานหลังยืนยัน/login สำเร็จ
• Custom Message — customize ข้อความ verification/MFA
• Pre Token Generation — เพิ่ม/แก้ claims ใน token
• Migrate User — ย้าย user จาก directory เดิมแบบ on-the-fly

CUP ทำหน้าที่เป็น identity broker ให้ผู้ใช้ login ด้วย external IdP โดยที่ CUP ยังคงเป็นตัวออก JWT token กลางให้แอปใช้งาน — แอปจึงไม่ต้องเขียนโค้ดต่อ IdP แต่ละราย

• Social federation — Google, Facebook, Amazon, Apple (เหมาะกับ consumer app)
• OIDC federation — IdP ที่รองรับ OpenID Connect
• SAML 2.0 federation — corporate directory เช่น ADFS, Okta (เหมาะกับพนักงานองค์กร SSO)

Cognito Identity Pools (Federated Identities) ทำหน้าที่แลก identity (token จาก CUP, social IdP, SAML, OIDC หรือแม้แต่ developer-authenticated) เป็น temporary, limited-privilege AWS credentials ผ่าน STS (AssumeRoleWithWebIdentity) เพื่อให้ client เข้าถึง AWS resources โดยตรง เช่น S3, DynamoDB

Authenticated vs Guest

• Authenticated identities — user ที่ login แล้ว ได้ IAM role ที่กำหนดสิทธิ์มากกว่า
• Unauthenticated (guest) identities — user ที่ยังไม่ login ได้ guest IAM role ที่จำกัดสิทธิ์ (เช่น เข้าถึงข้อมูลสาธารณะ)

Identity Pool จะกำหนด default IAM roles แยกสำหรับ authenticated และ unauthenticated และรองรับ Role Mapping เพื่อเลือก role ตาม claim ของ user

จุดแข็งของ Identity Pool คือทำ fine-grained access control ให้ user แต่ละคนเข้าถึงเฉพาะ resource ของตัวเองได้ โดยใช้ IAM policy variables ร่วมกับ identity id โดยไม่ต้องสร้าง role ต่อ user

ตัวอย่าง: จำกัดให้ user เข้าถึงเฉพาะ S3 prefix ที่ตรงกับ identity ของตน ด้วยตัวแปร ${cognito-identity.amazonaws.com:sub}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": [
        "arn:aws:s3:::my-bucket/${cognito-identity.amazonaws.com:sub}/*"
      ]
    }
  ]
}

สำหรับ DynamoDB ใช้ condition dynamodb:LeadingKeys เพื่อจำกัด row-level access ตาม identity id

{
  "Effect": "Allow",
  "Action": ["dynamodb:GetItem", "dynamodb:Query", "dynamodb:PutItem"],
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable",
  "Condition": {
    "ForAllValues:StringEquals": {
      "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
    }
  }
}

CUP integrate กับ service หน้าบ้านได้เพื่อ offload การ authenticate ก่อนถึง backend

API Gateway

ใช้ Cognito User Pools authorizer ที่ติดมากับ API Gateway เพื่อ validate JWT token อัตโนมัติ โดยไม่ต้องเขียน Lambda authorizer เอง — ง่ายและไม่ต้องดูแลโค้ด ถ้าต้องการ logic ซับซ้อนกว่านั้นค่อยใช้ Lambda authorizer

Application Load Balancer (ALB)

ALB รองรับ listener rule action authenticate-cognito ที่เชื่อมกับ CUP (หรือ OIDC IdP ผ่าน authenticate-oidc) เพื่อบังคับ user login ก่อนเข้าถึง target — เป็นการ authenticate ที่ระดับ load balancer

ความสับสนระหว่าง User Pools กับ Identity Pools คือหัวข้อที่ออกสอบบ่อยที่สุด ต้องแยกหน้าที่ให้ชัด และเข้าใจว่ามัก ใช้ร่วมกันเป็น chain

flow เมื่อใช้ร่วมกัน

• 1. User login ที่ CUP (หรือผ่าน social/SAML) → ได้ JWT token
• 2. แอปส่ง JWT นั้นเป็น login ให้ Identity Pool
• 3. CIP เรียก STS AssumeRoleWithWebIdentity → ได้ temporary AWS credentials
• 4. แอปใช้ credentials เข้าถึง AWS resources (เช่น S3, DynamoDB) ตาม IAM role

Cognito Sync เคยใช้ sync ข้อมูล user preferences/state ข้ามอุปกรณ์ ปัจจุบัน deprecated AWS แนะนำให้ใช้ AWS AppSync แทนสำหรับ data synchronization ในข้อสอบถ้าเห็น Cognito Sync เป็นตัวเลือกของ scenario สมัยใหม่ มักเป็นตัวลวง

สรุปกับดักข้อสอบที่พบบ่อย

• สับสนหน้าที่ CUP (JWT) vs CIP (AWS credentials) — จำให้แม่น
• คิดว่า JWT token เรียก AWS API ได้โดยตรง — ไม่ได้ ต้องแลกผ่าน CIP/STS
• เลือก Lambda authorizer ทั้งที่ Cognito User Pools authorizer ก็พอ
• ฝัง long-term IAM key ใน mobile app แทนที่จะใช้ temporary credentials
• เลือก Cognito Sync ในโจทย์ data sync สมัยใหม่ (ควรเป็น AppSync)