AWS Cognito设计：内部多应用场景下员工User Pool部署方案选型

结论优先 #

针对你司全体内部员工访问多款自研应用的场景，最优方案是仅创建1个统一的internal-users用户池，在该用户池下为每个内部应用分别配置独立的Cognito App Client即可，完全不需要创建多个用户池同步全量用户。

单用户池+多App Client的核心优势 #

• 用户数据统一维护，不需要做跨池用户数据同步，避免多池数据不一致、同步失败、重复存储的问题，员工账号的密码修改、权限变更、离职销户等操作只需要处理1次，运维成本极低
• 支持统一的身份验证规则配置：密码复杂度、MFA强制策略、会话有效期、IP白名单限制、自定义身份验证流等全局规则只需要配置1次，所有内部应用自动生效，也可以单独给某个App Client配置独立的登录态有效期等特殊规则，灵活度足够
• 可以轻松实现单点登录(SSO)：员工只要在一个内部应用登录成功，访问同用户池下的其他内部应用不需要重复登录，使用体验更好
• 权限隔离天然支持：每个App Client都有独立的client ID/secret，回调地址、登出地址、允许的OAuth授权流、自定义作用域都可以单独配置，不同应用的身份信息不会互相泄漏，完全满足多应用的隔离需求
• 支持针对不同应用配置独立的自定义属性映射、ID token/access token自定义声明，不需要调整用户池全局属性，适配不同应用的身份信息获取需求

仅以下场景需要考虑创建多个用户池 #

如果你的不同应用存在以下完全隔离的需求，才要拆分多用户池，否则都不需要：

• 不同应用的用户群体完全独立，没有重叠（比如同时有内部员工应用、外部供应商应用、外部C端用户应用，用户群体无交集）
• 不同应用需要完全独立的身份验证规则，比如A应用必须强制硬件MFA，B应用完全不需要MFA，且无法通过App Client层级配置实现的规则差异
• 不同应用所属的业务部门要求完全独立的用户数据管控权限、独立的审计日志、独立的合规管控要求

内容的提问来源于stack exchange，提问作者Bruno Koga