在有关 Cognito 的官方 AWS文档中，在一个用例的大纲中指出：
1.在第一步中，您的应用用户通过用户池登录并在成功验证后接收用户池令牌。
2.接下来，您的应用程序通过身份池将用户池令牌交换为 AWS 凭证。
3.最后，您的应用程序用户可以使用这些 AWS 凭证访问其他 AWS 服务，例如 Amazon S3 或 DynamoDB。
通过令牌分配“AWS 凭证”的目标不是通过STS实现吗？
Cognito 和 STS 在授予非 AWS 用户访问 AWS 服务（例如 S3 或 EC2）的范围方面究竟有什么区别？
相同的文档来源还指出，Cognito 也适用于 AWS 和第三方身份提供商（例如社交 - 例如 Facebook - 或 AD 公司）之间的身份联合。
这不也是通过 SAML 联合实现的（即让 AWS 和 IdP 首先建立基于 SAML 的信任关系吗？）
Cognito 用户池和身份池是比 SAML 和 STS 更高级别的抽象。让我们从定义什么是 SAML 和 STS 开始：
SAML通过提供一种对用户进行一次身份验证，然后将该身份验证传递给多个应用程序的方式，使单点登录 (SSO) 技术成为可能。
STS是一项 Web 服务，可让您为 AWS Identity and Access Management (IAM) 用户或您进行身份验证的用户请求临时的有限权限凭证
基本上，SAML 是一种将一个应用程序生成的身份验证令牌传输到另一个应用程序的方法，而 STS 是一种从 AWS 获取授权令牌（即 AWS 凭证）的方法。
另一方面，现在我们有 Cognito 用户和身份池：
用户池提供身份验证，如 SAML，但它们也提供用户数据库。SAML 不这样做，因此如果您想保留用户数据、添加、更改等，您需要自己做。SAML 允许您做的所有事情就是将这些用户的身份验证卸载到另一方。但是，您必须编写所有代码才能进行身份验证。
用户池可以自己使用 SAML 身份验证提供程序，或执行自己的内置身份验证。但无论哪种情况，您最终都会得到一个用户实体，该用户实体位于 Cognito 中并具有与之关联的数据。
身份池提供授权，即决定允许（通常经过身份验证，但不总是）用户做什么。他们确实在后台使用 STS 来获取启用特定操作的令牌，但身份池会根据用户特征选择是否授予以及授予什么凭据。身份池依赖于身份验证提供者来确定用户是谁；此提供者也可以是用户池或 SAML 提供者。身份池将根据提供者自动检查给定的身份验证令牌是否有效，并且它们允许用户获取某些授权令牌。
总之，Cognito 用户池和 Cognito 身份池封装了您通常需要自己编写以从 SAML 提供程序到用户数据库的功能，再到用户到权限的映射，再到能够检索这些权限的 AWS 凭证。它们允许您配置用户池以使用给定的提供程序（或 Cognito 自己的身份验证），而不是对 SAML 提供程序进行身份验证调用（或实施您自己的身份验证）、实施用户数据库，然后为用户的权限制作 AWS 凭证)，将一个身份池指向用户池，并告诉身份池用户池的成员应该拥有哪些权限。其余的一切都在后台为您完成。