为啥我应该通过 Chrome 的凭据管理 API 使用一键登录

Posted 2023-02-23

【中文标题】为啥我应该通过 Chrome 的凭据管理 API 使用一键登录

【英文标题】：Why should I use One tap sign in over Chrome's Credential Management API为什么我应该通过 Chrome 的凭据管理 API 使用一键登录

【发布时间】：2018-05-16 11:30:52

【问题描述】：

我对谷歌今年早些时候宣布的一键登录有点困惑。我们的应用程序已经在 Chrome 中使用 Credential Management API，它本质上为用户提供了基于用户在上次访问时为我们的站点保存的凭据（保存在 chrome 中的密码）的登录选项。当我阅读 One tap sign in 的文档时，它承诺做同样的事情，但使用 Google 的客户端 api id。我们的应用程序有自己的 ID 提供者和我们自己的用户名和密码数据库，从文档看来，一键登录不支持自定义 ID 提供者。谁能更清楚地说明这一点，我为什么要用一个来对抗另一个？

谢谢 卡提克

【问题讨论】：

Google Smart Lock vs Credential Management API的可能重复

【参考方案1】：

我发现两个主要区别：

一键式无密码 - 它使用基于令牌的登录，从不暴露用户密码。 Chrome 凭据管理 API 在 Chrome 的密码存储中存储和检索实际密码。

One Tap 纯粹是基于网络的 - Chrome 凭据管理 API 依赖于 Chrome 的特定实现。 One Tap 是一个纯粹基于 Web 的工作流程，因此可以跨浏览器运行。

在我看来，One Tap 是一种更好的长期登录解决方案。凭据管理 API 是实验性的，目前仅在 Chrome 中受支持。

https://developer.mozilla.org/en-US/docs/Web/API/Credential_Management_API#Browser_compatibility

【参考方案2】：

我在 Google 领导 one-tap/auto sign-in library 的产品开发，我们将其设计为 该库包含凭据管理 API 并扩展为在帐户创建、安全无密码和跨浏览器支持方面提供帮助.

特别是，如果您使用如下代码请求现有凭据：

googleyolo.retrieve(
  supportedAuthMethods: [
    "https://accounts.google.com",
    "googleyolo://id-and-password"
  ],
  supportedIdTokenProviders: [
     uri: "https://accounts.google.com", clientId: "CLIENT_ID" 
  ]
);

然后将返回凭据管理 API 中保存的所有用户名/密码（在支持该 API 的浏览器中）以及 Google 帐户的令牌数据。一键式/自动登录 javascript 库封装了用于凭据检索的凭据管理 API。

此外，该库提供了一个googleyolo.hint 方法来显示一个电子邮件选择器，用于一键选择已验证的电子邮件地址以帮助创建新帐户，或链接到现有帐户，然后自动登录下次在所有浏览器中使用令牌而不是密码，只要同一个 Google 帐户处于活动状态。

我建议使用一键式/自动登录库并使用令牌和密码，以便获得辅助注册、让现有用户自动登录并提供功能，即使浏览器确实如此不支持凭据管理 API。

关于使用您自己的用户名/密码数据库的问题，希望这个库是您可以实现创建帐户和自动登录这些帐户和现有帐户的功能，OpenID Connect ID tokens 代表用户的身份.通过一键式/自动登录 UX，这些不仅更实用，而且比密码更安全，并减少了弱密码/重复使用密码的创建。请考虑这个或更好的托管身份验证解决方案，如 Firebase Auth 或 Auth0，并在前端 UI 中包含一键式 UX。

【讨论】：

感谢您的回复，在我的情况下，我希望 googleyolo 检索为特定域（我们拥有的域）存储的用户名/密码，我认为这可能吗？