在不久前的文章中，我們聊到了 IAM、OIDC 與 CI/CD Pipeline 的串接，確保自動化流程可以安全地跟 AWS 互動。
不過，我們的專案（多人協作的時間表平台）真正需要的，是一套「讓使用者可以註冊、登入、驗證身分」的機制。這時候，Cognito 就會正式登場！

Cognito 是集成身分驗證流程/機制的工具

想像一下，假如我們的專案需要：

• 不同的使用者帳號
• 安全的登入與登出機制（不能只是明文密碼存在資料庫裡）
• 讓使用者可以跟 AWS 互動（例如直接上傳檔案到 S3）

這些功能若要自己從零寫，會牽涉到：密碼加密、驗證 Token、第三方登入、憑證交換…
幾乎每個 App 都需要，但我們絕不希望每次都得重造輪子對吧
這就是 Cognito 存在的價值 透過強大的集成幫我們處理「身份管理」這件事

舉個簡單的例子，"Continue with Google"

大家應該都很熟悉這種場景
進入一個新網站後，馬上看到「用 Google / Facebook / Apple 登入」的介面
按一下之後，網頁跳出去又跳回來，然後就登入了

這個流程其實就是 Cognito + 第三方登入 (Federation) 可以幫你實現的事情

好處

• 使用者不用再記一組新帳號密碼（降低註冊門檻）
• 開發者不用自己寫「跟 Google 驗證帳號」的繁瑣流程
• Cognito 幫忙處理好整個「交換 Token → 確認身份 → 簽發 JWT」的過程

在 Cognito 中怎麼運作？

1. 使用者按下「用 Google 登入」
2. Google 驗證成功後，把授權資訊交給 Cognito
3. Cognito 頒發屬於這個使用者的 JWT (還不知道這是甚麼的稍後介紹)
4. 我們的 App 就能用這個 JWT 來確認「這個人就是用 Google 登入的那個誰」

在 Free Tier 中，整合 Google 登入完全免費（只要你月活躍使用者不超過 50,000 人）。
用戶不用自己建立帳號，點「Google 登入」就能使用

Cognito 的三大組件

1. User Pool

• 可以視為「會員資料庫 + 登入驗證系統」
• 功能：
  • 註冊 / 登入
  • 支援 Email / SMS 驗證
  • 支援第三方登入（Google、Facebook、Apple…）
• 適用場景：
  • 我們的平台主要用來管理使用者帳號
  • 產生 JWT Token 作為使用者身份識別

2. Identity Pool

• 幫助使用者「換取 AWS 臨時憑證」（透過 STS）
• 功能：
  • 使用者登入成功後，取得臨時 IAM Role
  • 讓使用者直接呼叫 AWS 服務（例如 S3 上傳檔案）
• 適用場景：
  • 適合「使用者需要直接與 AWS 資源互動」的情境
  • 若僅透過 API Gateway / Lambda，通常不需要 Identity Pool(我們的Case)

3. User Pool Client

• 前端應用程式與 Cognito User Pool 的「代理人」
• 功能：
  • 定義 App 如何與 User Pool 互動（回呼網址、登入流程等）
  • 決定簽發的 Token 類型（ID Token、Access Token、Refresh Token）

User Pool vs Identity Pool

小結：

• User Pool：解決「你是誰 (Who are you)?」
• Identity Pool：解決「你能做什麼 (What can you do)?」

但在我們的專案中，實際上負責寫入資料的都是Lambda而非使用者，所以比較用不到Identity Pool

AWS Amplify 包裝API串接前端服務

如果我們單純用 SDK 來整合 Cognito，會需要自己處理：

• 呼叫 Cognito API
• 保存 Token
• 自動 Refresh Token
• 串接第三方登入流程

聽起來很麻煩吧？
這時候 AWS Amplify 就幫我們省下許多功夫。

Amplify 提供：

• 快速把 Cognito 登入 / 註冊 UI 接上前端
• 自動處理 Token 存取與更新
• 與 API Gateway / S3 等服務的無縫整合

在接下來的實作裡，我們會用 Amplify 來當「前端跟 Cognito 的橋樑」。

JWT (JSON Web Token) 登入後的「通行證」

當使用者透過 Cognito 成功登入後，系統不會只告訴你「登入成功」，而是會發給你一張 JWT，就像是雲端身份證或通行證一樣。

JWT 的結構

JWT 是由三個部分組成的字串，格式如xxxxx.yyyyy.zzzzz

1. Header（標頭）

   • 說明這個 Token 使用的加密演算法 (如 HS256 或 RS256)
   • 例如：

     {
       "alg": "RS256",
       "typ": "JWT"
     }
     

2. Payload（有效載荷）

   • 包含使用者資訊與其他聲明 (Claims)
   • Cognito JWT 常見內容：
     • sub: 使用者唯一識別 ID
     • email: 使用者 Email
     • exp: Token 過期時間（Unix Timestamp）
     • iat: 簽發時間（Issued At）
   • 例如：

     {
       "sub": "a1b2c3d4e5",
       "email": "user@example.com",
       "iat": 1690000000,
       "exp": 1690003600
     }
     

3. Signature（簽名）

   • 由 Header + Payload + Cognito 的私鑰經加密演算法產生
   • 確保 Token 未被竄改
   • API 端只要使用對應公鑰驗證簽名即可確認 JWT 的合法性

JWT 的用途

• 識別使用者：API 可以讀取 Payload，知道這個請求來自哪個使用者
• 存取控制：判斷使用者是否有權限呼叫某個資源
• 無狀態認證：不需要伺服器端存 Session，Token 自帶使用者資訊與有效期限

換句話說，JWT 就是使用者的雲端身份證，API 看到它就知道「你是誰」以及「你可以做什麼」。

Cognito 在我們專案的定位

回顧一下，我們的多人協作時間表平台需要：

• 每位使用者可以登入自己的帳號
• 能看到自己的行事曆，並與其他人共享狀態
• 確保不同使用者之間的資料不會混淆

Cognito 將扮演：

• User Pool：管理使用者帳號（誰是誰）
• User Pool Client：處理登入流程（怎麼登入）
• Amplify：讓我們能在前端快速接上這些功能

結語

今天的內容中我們介紹了Cognito的使用情境以及概念上的內容，在今天了解了Cognito在我們專案中的定位後，明天我們就將在Console中認識Cognito的配置，並介紹對應的CDK程式碼，配合前端網站實作演示一個使用者登入的流程！敬請期待囉