AWS Cognito User Pool vs. Identity Pool 使用筆記

2020-07-12 AWS

這篇主要是針對 AWS Cognito 做的筆記,也介紹給對 Cognito 想深入了解的人

關於 AWS Cognito 基本介紹

AWS Cognito 這個服務的訴求是「簡單、安全的使用者註冊、登入和存取控制」基本上就是讓開發者不用自己去刻一個登入認證系統,或者是少掉使用者的管理,透過 AWS Managed Service 的優勢讓產品可以快速上線。

AWS Cognito 主要功能

Cognito 主要分為兩個功能,一是「User Pool」一是「Identity Pool」這兩個如果不先弄清楚很容易搞混 …

  • Cognito User Pool:提供「使用者登入驗證」的服務,意旨當 Applicaton 必須要建構 Account login 如會員中心這種功能,就可以利用 Cognito User Pool 進行登入驗證
    • 簡單架構:Web Application <-> AWS Cognito <-> Social login provider (ex. Facebook, this’s Option)
  • Cognito Identity Pool:提供「第三方登入驗證後存取 AWS 服務」,要存取 AWS 服務也能夠透過非 AWS 的 login provider 登入,例如 Facebook, Twitter 等,基本上 Cognito 會幫你換到 IAM Role 的 STS token
    • 簡單架構:Social login -> AWS Cognito (with IAM STS) -> AWS Service

另外還有 Cognito Sync,不過已經被 AppSync 取代了。

Cognito User Pool 功能

主要提供身份驗證,所以基本的 User、Group 管理都有,文件也有簡單入手的 Getting Started with User Pools

  • 登入帳號的屬性:在 Attributes 可以選擇 Login Key 是 username, phone number 或是 email 再搭配 Password,然後也支援最多 25 個自定義的 Attributes
  • 密碼複雜度規則:基本的數字、英文大小寫、特殊符號、字元長度等規範都有可選
  • MFA 多重身份驗證:啟用 MFA 前也必須啟用 phone number 驗證,
  • 忘記密碼:支援 email、phone number 驗證身份拿回密碼
  • 驗證 email、phone number 的所有權:Cognito 很多功能都會用到 email、phone number,所以 Cognito 也支援驗證所有權,避免使用者輸入錯誤的 email / phone number。

對 Third Party 的支援

  • Social Idp
    • 對社交平台像是 Google, Twitter, Amazon, Facebook 只需要提供簡單的 secret Key 就可以整合登入
  • SAML Idp
    • 基於 SAML 2.0 的整合方法,像是 Microso AD FS / Okta / Auth0 / PingFederate 這類型的 Idp
  • OIDC Idp
    • 也額外支援 OpenID Connect 的 Idp,支援 OIDC 讓可以串接 Cognito 的 Idp 更多了,但最少要有 OAuth 2.0 以上的協議,詳細可以參考 OIDC User Pool IdP Authentication Flow

對 Custom UI 或是 Hosted UI 的方法

Cognito 內建有提供 Hosted UI 直接使用,也能直接調整一些簡單的畫面需求,預設的 Hosted UI 像這樣:

Custom UI 可以透過既有或客製化的 UI 搭配 Amplify 串接 Cognito 驗證。

對 Custom Auth Authentication 的支援

如果有自訂義的驗證方法,也可以利用 Lambda trigger 做到,參考「Custom Authentication Challenge Lambda Triggers」會用到幾個 trigger flow:

像是 Passwordless Auth 就可以利用 Custom Auth Authentication 做到,參考以下 Github 範例連結,再找時間開一篇解說

更多 Lambda triggers 的支援

參考 Customizing User Pool Workflows with Lambda Triggers 可以找到更多自訂義的需求方案

User Migration 的方法

如果既有 Idp 或是 On-Premises 要遷移到 Cognito 可以透過兩種方法

  • One-at-time 也稱為 Just-in-time (JIT)
    • Sign-in fail:當登入錯誤時與既有的 Idp 取得 User Profile 後 response Cognito 建立 User
    • Forgot password:當使用者不存在時,觸發 ForgotPassword 流程與 Idp 確認 User Profile 是否存在,然後重新在 Cognito 換發新密碼給使用者。
  • Batch import from CSV
    • 批次以 CSV 檔案匯入,但不包含密碼,第一次登入的用戶會以 ForgotPassword 的方式重新煥發新密碼。
    • 預設必須開啟 CloudWatch Logs,Batch import 會將匯入的資訊寫到 CloudWatch Logs

Cognito Identity Pool (Federated Identities) 功能

Identity Pool 從 Console 上看也稱為 Federated Identities,透過 Identity Pool 可以拿到臨時的 IAM Role STS token 藉此存取 AWS 服務

  • Auth flow:預設是 Enhanced Authflow (預設) 另外也支援 Basic Authflow
  • 支援 Identity Pool 的 SDK
    • AWS Mobile SDK for Android
    • AWS Mobile SDK for iOS
    • AWS Mobile SDK for Unity
    • AWS Mobile SDK for .NET and Xamarin
    • AWS SDK for JavaScript
  • 支援多種 Identity Providers
    • Cognito User Pool
    • Google+ / Facebook / Twitter / Apple …
    • OIDC (OpenID Connect)
    • SAML

Use Case

參考官方範例「Common Amazon Cognito Scenarios」可以明顯區分 User Pool 和 Identity Pool 的差別

  • User Pool 的 Idp 由 Social sign-in 提供
  • User Pool 作為 API Gateway 的驗證
  • 透過 Identity Pool 存取 AWS 服務,而 Identity Pool 的 Idp 由 Cognito User Pool 提供。
  • 透過 Identity Pool 存取 AWS 服務,而 Identity Pool 的 Idp 由 Social sign-in 提供。
  • Cognito 與 AppSync (GraphQL request) 的整合

Cognito 對於資料的保護

由於可能牽涉到個資議題,所以在 Data Protection in Amazon Cognito 這篇特別提到關於資料保護的說明,權責也依照 shared responsibility model 分類:

  • 使用 Cognito 建議採用以下:
    • 開啟 MFA 和 TLS 使用 AWS Service
    • 開啟 CloudTrail Logging API
    • 如果有用到 S3 儲存則建議使用 Macie
  • AWS Cognito 保證的 Data Protection
    • Encryption at Rest
    • Encryption in Transit (最低支援 TLS 1.0,建議 TLS 1.2 以上)

更多可以參考 Security in Amazon Cognito 文件

與 Cognito 深度整合的 AWS Service

  • Lambda trigger 在 Custom define 佔有很大的成分
  • Amplify 提供 iOS, Android, JavaScript 簡單串接 Cognito,更是 Serverless 強大的方案

其他

References

給 Mr. 沙先生一點建議

彙整

分類

展開全部 | 收合全部

License

訂閱 Mr. 沙先生 的文章

輸入你的 email 用於訂閱