在有关Cognito的官方AWS documentation中，用例的概述中指出：
1。第一步，您的应用用户通过用户池登录，然后 成功通过身份验证后会收到用户池令牌。
2。接下来，您的应用将用户池令牌交换为AWS凭证 通过身份池。
3。最后，您的应用程序用户可以使用这些AWS凭证访问 其他AWS服务，例如Amazon S3或DynamoDB。
不是通过 STS 实现的令牌分配“ AWS凭证”的目标吗？
在Cognito和STS之间向非AWS用户授予对AWS服务（例如S3或EC2）的访问权限方面，究竟有什么区别？
同一文档来源还指出，Cognito也适用于AWS与第三方身份提供商（例如社交网站（例如Facebook）或AD公司）之间的身份联盟。
这还不是通过SAML联合实现的（即让AWS和IdP首先建立基于SAML的信任关系吗？）
答案 0 :(得分：2)
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凭证。 ），将标识池指向用户池，并告诉标识池该用户池成员应具有哪些权限。其余所有工作都在后台为您完成。