使用 Amazon Cognito 驗證終端使用者

在 AWS 上部署應用程式

Dunieski Otano

Amazon Web Services Solutions Architect

要自建登入嗎？

  • 新應用需要完整註冊與登入
  • 團隊打算從零自建驗證
  • Cognito 已可安全滿足這些需求

選擇使用受管的 Amazon Cognito 驗證，而非自建登入

在 AWS 上部署應用程式

User pool 與 identity pool 的差異

Cognito 使用者池作為使用者目錄在左側簽發權杖，身分池在中間以已驗證的權杖換取暫時性 AWS 認證，右側為 AWS 服務

  • User pool：受管的終端使用者目錄
  • 處理註冊、登入並簽發權杖
  • Identity pool：用登入換取AWS 認證
  • 搭配使用：先驗證，再授權 AWS 存取
在 AWS 上部署應用程式

Cognito 的三種權杖

  • ID token：描述使用者是誰（身分宣告）
  • Access token：描述可呼叫的資源
  • Refresh token：免重登即可換新權杖
  • 三者皆為可解碼驗證的JWT

三種 Cognito JWT 權杖並列：ID token 含身分宣告、access token 含 API 權限範圍、refresh token 為長效用於靜默更新

在 AWS 上部署應用程式

聯邦身分

  • Federation：用外部身分提供者登入
  • 社群：Google、Facebook、Apple
  • 企業：SAML 與 OIDC 提供者
  • Cognito 代理信任並簽發自家權杖

Cognito 聯邦身分：使用者選擇社群（Google、Facebook）或企業 SAML/OIDC 提供者，Cognito 驗證外部登入並簽發自家標準權杖

在 AWS 上部署應用程式

將 Cognito 作為 API Gateway 授權器

API Gateway Cognito 授權器：用戶端以 Authorization 標頭送出 access token，閘道先對使用者池驗證，無效權杖以 401 拒絕，才會執行 Lambda

  • API Gateway 可使用Cognito 授權器
  • 用戶端將權杖放在Authorization 標頭
  • API Gateway 在後端執行前先驗證權杖
  • 無效或過期權杖會在邊界被拒絕
在 AWS 上部署應用程式

典型的登入到 API 呼叫流程

  • 使用者登入user pool
  • 取得 ID、access、refresh 權杖
  • 用戶端以access token 呼叫 API Gateway
  • Cognito 授權器驗證後，後端才執行

登入到 API 呼叫流程：使用者登入 user pool 並取得權杖；用戶端送 access token 到 API Gateway；Cognito 授權器驗證；後端 Lambda 執行

在 AWS 上部署應用程式

常見的 Cognito 誤用

  • 該用 access token 時卻送了ID token
  • 混淆 user pool 與 identity pool
  • 僅用 user pool 嘗試授權AWS 存取
  • 在用戶端不安全地儲存權杖

常見 Cognito 錯誤：對 API 傳 ID token 而非 access token、混淆 user pool 與 identity pool、以及在用戶端不安全地儲存權杖

在 AWS 上部署應用程式

一起來練習吧！

在 AWS 上部署應用程式

Preparing Video For Download...