首先,了解 Cognito 包含两个相关的服务,用户池和身份池。
简而言之,用户池是一个包含所有功能的用户数据库:身份验证、MFA、组、密码重置等。它允许用户提供用户名和密码,如果它们有效,它会给他们一个令牌来证明他们是真正的用户。它提供身份验证。
一个 ID 池从用户映射到 AWS 凭证。为了映射到 AWS 凭证,它需要一些用户的概念,这必须由某人提供。这可以是用户池,也可以是第 3 方。无论如何,只有拥有某种用户令牌后,您才能使用 id 池,然后您可以使用它来询问 id 池:“给我该用户可能使用的凭据(如果有)”。id 池提供您对 AWS 服务进行授权所需的凭证。
在为移动应用程序验证移动用户身份方面,STS 和 Cognito 有什么区别和用例?
考虑路径user login -A-> user auth token -B-> aws credentials
。
STS仅提供临时凭证。STS 没有用户的概念,它只知道调用者是否有权限访问凭证,以及是哪些凭证。“对于您进行身份验证的用户”意味着只有您处理所有身份验证,然后调用 STS 获取凭据以提供给这些用户。它既不满足 arrowA
也不满足 arrow B
。
Cognito 用户池满足A
上面的箭头。
Cognito id 池满足B
上面的箭头。
如果您想自己做箭头A
和箭头B
,您可以使用 STS 作为解决方案的一部分。
如果您只想自己做箭头A
,您可以使用 id 池来处理箭头B
(id 池实际上在后端使用 STS)。您将告诉 id pools 将处理箭头的身份提供者A
(例如 Facebook),然后您将处理让 Facebook 为您验证用户身份的逻辑。您将获取用户获取的 Facebook 身份验证令牌,并将其传递给 id 池以取回凭据。
如果你想做最少的工作,你可以使用用户池来处理箭头A
,使用 id 池来处理箭头B
。您仍然可以在用户池下使用第三方身份验证提供程序(例如 Facebook),但您会将 id 池指向用户池,将用户池指向第三方。然后,用户池A
为您处理部分的所有逻辑(您编写零 Facebook auth API 代码)。