在之前的文章中，我們已經介紹完畢了 Cognito 登入與前端的串接。 並且在實作demo中，使用者能在瀏覽器中順利登入，甚至看到自己擁有的 Token。

那麼問題來了：
「登入成功之後，後端要怎麼知道這個人是誰？」
「如果我要呼叫雲端 API，怎麼確保只有登入的人能用？」

今天，就讓我們透過 API Gateway + Lambda，帶你體驗「後端也能認得你」的流程。

今天的內容將使用 GitHub Repo - Cognito + API Gateway Demo

架構概念：從登入到後端驗證

流程其實很直覺：

1. 使用者登入 → Cognito 發 Token (JWT)
2. 前端呼叫 API Gateway，並在 HTTP Header 裡帶上 Token
3. API Gateway 驗證 Token，如果Token不對就不給過
4. Lambda 拿到驗證過的使用者資訊，再決定回應什麼

API Gateway 的角色：後端的第一道大門

API Gateway 是 AWS 中 承接 API 請求的入口，功能包括：

• 身分驗證 (Authentication)
  • 透過 Cognito User Pool Authorizer 驗證使用者的 JWT Token
    (也就是我們要做的)
• 流量管理
  • 支援 Rate Limiting、Throttling
• 安全保護
  • 可以掛上 WAF (防火牆)
• 後端代理
  • 將請求轉給 Lambda、其他 HTTP 服務，甚至直接操作 DynamoDB

在今天的案例中，API Gateway + Cognito 的搭配重點是：

1. 使用 User Pool Authorizer，要求呼叫 API 時帶上 JWT Token
2. 驗證通過後，將 Token Payload (claims) 一併傳給 Lambda

Lambda：雲端的程式執行器

在 API Gateway 背後，最常見的搭檔就是 AWS Lambda。
它可以讓我們不用維護伺服器，直接在雲端執行程式碼。

特點是：

• 事件驅動：API Gateway 的請求進來 → 觸發 Lambda 執行
• 免維運：不需要自己開 EC2 或 Container
• 多語言支援：支援 Python、Node.js、Java、Go… 等等
• 彈性計費：只算執行時間，不用時候完全不收錢

在今天的案例中，Lambda 的任務很單純：

• 接收 API Gateway 傳來的請求
• 讀取驗證過的使用者資訊 (claims)
• 回傳一段訊息，證明「後端真的知道你是誰」

Lambda 範例：讀取使用者資訊

Lambda 可以直接從 event 拿到「使用者的身分資訊 (claims)」。

import json

def lambda_handler(event, context):
    // 從API Gateway拿使用者的資料
    claims = (   
        event.get('claims', {})
    )
    // 將資料解包取得email 以及 username (如沒有則為預設值)
    email = claims.get('email') or claims.get('cognito:username') or '訪客' 
    // 根據使用者的email回傳訊息
    message = f"歡迎{email}加入30天AWS系列！" 
    return {
        'statusCode': 200,
        // CORS 標頭 (不知道這是什麼的之後介紹)
        'headers': {   
            'Content-Type': 'application/json',
            'Access-Control-Allow-Origin': '*',
            'Access-Control-Allow-Headers': 'Content-Type,Authorization',
            'Access-Control-Allow-Methods': 'GET,OPTIONS'
        },
        // 前端會收到的內容
        'body': json.dumps({ 
            'message': message,
            'email': email
        })
    }

前端怎麼呼叫 API

對於後端而言，前端的角色很單純：帶著 Token 過來。

// 透過環境變數讀入URL
const res = await fetch(`${apiUrl.replace(/\/$/, '')}/echo`, { 
        method: 'GET',
        headers: {
        // 將使用者的session id token帶入header
          'Authorization': `Bearer ${idToken}`, 
          'Accept': 'application/json'
        }
      });

如果請求 header 中沒有帶有指定 cognito 認證過的 id token 的話，則會直接被api gateway給攔下來

Demo Repo

這個 Demo 我已經整理成一個小專案，你可以直接 clone 跟著README下來跑：
GitHub Repo - Cognito + API Gateway Demo

建議你試試看：

1. 登入不同帳號，看看 Lambda 回傳是否不同
2. 刻意不帶 Token，觀察 API Gateway 的拒絕訊息

結語

今天我們回答了「後端怎麼知道使用者是誰？」這個問題。
靠著 API Gateway + Cognito，我們建立了第一個「前後端都有認知」的完整流程：

• Cognito 發 Token，代表身份
• API Gateway 驗證 Token，決定要不要放行
• Lambda 接收驗證好的使用者資訊，回應資料

這樣的架構再搭配資料庫，是在雲端應用中非常常見的基礎設施規劃。
優點就是完全 Serverless

那麼今天走過了 Cognito token 驗證的流程，應該有比較有感覺了，在明天我們會看看 API Gateway 與 Lambda 部署，尤其是在與 Cognito 串接時的各種眉角以及CDK的寫法。在雲上的前後端分離系統其實蠻容易因權限、瀏覽器安全政策而卡關 (我自己也花了一些時間...)，那麼明天就帶大家看看會踩甚麼雷吧