上一篇聚焦 Microsoft 的顧客身分平台，整理 Azure AD B2C 與 Entra External ID 的目前定位：B2C 已停止向新客戶銷售，但既有客戶仍可繼續使用；External ID 是後續主要發展方向，卻不是 B2C 的改名或直接升級。若企業決定遷移，還需要另外建立 External tenant，並分階段處理應用程式、顧客帳號、登入設定與密碼。
理解 Microsoft 的做法後，接下來可以把同一個問題放到 AWS：員工要如何集中存取多個 AWS 帳戶與應用程式？網站或 App 的顧客帳號又該由哪項服務管理？本篇將分別介紹 AWS IAM Identity Center 與 Amazon Cognito，釐清兩者在員工身分、顧客身分及 AWS 資源存取上的分工，再進一步說明 Cognito 的 User Pools、Identity Pools、應用程式登入與第三方身分提供者整合。
今天內容涵蓋：
公司使用 AWS 時，通常不只一個 AWS 帳戶。例如開發環境、測試環境與正式環境可能各自使用不同帳戶，員工也可能需要進入不同的 AWS 應用程式。如果每個帳戶都分別建立使用者與權限，管理會變得很複雜。
AWS IAM Identity Center 就是用來集中處理這件事的員工存取入口。員工只要登入一次，就能在 AWS access portal 看到自己可以使用的 AWS 帳戶與應用程式，再依照被指派的權限進入對應資源。
它主要負責三件事：
例如，開發團隊的 Gloria 可以被指派「開發帳戶的開發權限」與「正式帳戶的唯讀權限」。Gloria 只需要使用同一個公司帳號登入，就能看到這兩個帳戶，而且進入後會套用各自對應的權限。
💡IAM Identity Center 的前身是 AWS Single Sign-On（AWS SSO）。它主要管理員工如何存取 AWS；網站或 App 的顧客帳號則由後面介紹的 Amazon Cognito 處理。
Azure AD B2C 與 Entra External ID 的 External tenant 都屬於 CIAM，主要用來管理網站或 App 的顧客註冊、登入、密碼重設、第三方帳號登入及 Token 簽發。
在 AWS 中，負責相近工作的主要是 Amazon Cognito，其中 Cognito User Pools 提供顧客帳號目錄與登入功能。
| 顧客身分功能 | Microsoft | AWS 中的相近功能 |
|---|---|---|
| 建立獨立的顧客帳號目錄 | Azure AD B2C tenant／External tenant | Cognito User Pools |
| 顧客註冊、登入與密碼重設 | User Flow | Managed Login 與 User Pool 登入設定 |
| 串接 Google、Facebook 或其他 IdP | 外部身分提供者 | User Pool Federation |
| 加入自訂驗證與商業邏輯 | B2C Custom Policy／External ID 擴充功能 | Lambda Triggers 與 Custom Authentication Flow |
| 向 App 簽發 ID Token 與 Access Token | B2C／External ID 的 OAuth 2.0、OIDC 端點 | User Pool 的 OAuth 2.0、OIDC 端點 |
Microsoft 使用 Azure AD B2C 或 Entra External ID 管理顧客身分；AWS 則主要透過 Amazon Cognito User Pools 處理相近需求。前一節先區分 AWS 的員工身分與顧客身分服務，接下來會集中介紹與 B2C／External ID 功能較接近的 Amazon Cognito。
💡這裡比較的是兩邊解決的功能需求，不代表產品可以直接互換。Azure AD B2C 轉向 External ID 的產品狀態與遷移議題，在 AWS 中也沒有完全相同的產品更替關係。
Amazon Cognito 是 AWS 提供給網站與行動 App 使用的顧客身分服務，可以管理顧客帳號、註冊與登入；是否需要存取 AWS 資源，則是另一件事。
Cognito 主要分成兩個可以獨立使用的部分：User Pools 與 Identity Pools。多數企業應用程式會先使用 User Pools；只有需要讓前端或行動 App 直接存取 AWS 服務時，才可能再使用 Identity Pools。
User Pool 是顧客帳號目錄，也是 App 的身分提供者。它主要負責：
顧客登入後，App 可以使用 ID Token 確認顧客身分，並把 Access Token 傳給企業的後端 API。後端驗證 Token 後，再根據 App 自己的權限規則決定顧客可以查看或修改哪些資料。這種情況通常只需要 User Pool，不需要 Identity Pool。
Identity Pool 不負責保存密碼，也不直接處理註冊與登入。它的用途是把 User Pool 或其他身分提供者的登入結果，換成一組短效的 AWS 臨時憑證。
例如，行動 App 需要讓顧客直接把照片上傳到指定的 S3 路徑，就可以透過 Identity Pool 取得權限受限的臨時憑證，再依照 IAM Role 的設定存取 S3。Identity Pool 也可以設定匿名訪客的有限存取權。
如果是後端 API 需要讀寫 S3、DynamoDB 等 AWS 服務，通常會由 Lambda、EC2 或 ECS 使用自己的 IAM Role，不需要把 AWS 憑證交給前端，也不一定需要 Identity Pool。
💡 User Pools 處理「顧客如何登入企業應用程式」；Identity Pools 處理「前端或行動 App 是否需要直接取得 AWS 臨時憑證」。使用 Cognito 不代表一定要讓顧客直接存取 AWS 資源。
使用 Cognito User Pool 時，應用程式會先把顧客導向 Cognito 的託管登入頁面（Managed Login），再透過 Authorization Code Flow 取得 Token。差別在於顧客的身分由 Cognito 直接驗證，還是交給外部身分提供者驗證。
如果顧客使用 User Pool 內的帳號，流程如下：
在這個流程中，Cognito 對應用程式扮演 OIDC 身分提供者與 OAuth 2.0 授權伺服器。
如果應用程式提供「使用 Microsoft 帳號登入」或「使用 Okta 登入」，顧客的帳號密碼不會交給 Cognito 驗證，而是由對應的外部身分提供者（Identity Provider，IdP）負責。
Cognito User Pool 可以串接社群身分提供者（Social IdP）、OIDC IdP 與 SAML 2.0 IdP，再統一向應用程式簽發 Token。
以使用 Microsoft Entra ID，並透過 OIDC 登入為例，流程如下：
簡單來說，外部 IdP 負責「確認這個人是誰」，Cognito 則將不同 IdP 的登入結果整合成應用程式統一使用的身分與 Token。
💡以 OIDC IdP 為例，這裡有兩段獨立的 Authorization Code Flow：
App → CognitoCognito → Microsoft Entra IDEntra ID 簽發給 Cognito 的 Token 不會直接交給 App；App 最後使用的仍是 Cognito 簽發的 Token。
本篇主要整理 AWS 兩類身分服務的用途：
Cognito 支援直接使用 User Pool 帳號登入，也能串接 Microsoft Entra ID、Okta 等外部身分提供者。兩種方式下，應用程式最後都向 Cognito 取得 Authorization Code 與 Token；差別在於顧客身分由 Cognito 驗證，還是由外部身分提供者驗證。
下一篇將接著討論帳號如何自動建立與管理：先介紹 JIT Provisioning 如何在首次登入時依規則建立帳號或加入組織，再說明 SCIM 如何跨系統同步使用者與群組，處理入職、異動與離職時的帳號變更。
iThome鐵人賽
看影片追技術