ios - 我应该将密码保存在共享的网络凭据和(本地)钥匙串(keychain)中吗

Question

我正在为将与域关联的新应用程序设计登录，即与 SPA 对应。
显然我想使用

iOS 11 密码自动填充和

共享 Web 凭据

我已阅读有关自动填充的文档并观看了有关它的 WWDC 视频。另外，我检查了 article在共享 Web 凭据上，我认为它比新的、重新设计的自动填充更旧。文章推荐:

Do not use the shared web credentials as your primary storage for secure user credentials. Instead, save the user’s credentials in the keychain, and only use the shared web credentials when you can’t find the login credentials in the keychain.

这让我觉得有点奇怪，因为它
- 意味着我必须涵盖更多可能的不一致，即以某种方式将钥匙串(keychain)与共享的 Web 凭据同步(如果我在钥匙串(keychain)中拥有凭据以及共享的 Web 凭据，但它们是不同的，该怎么办？)
- 如果我的用户卸载我的应用程序，可能会在钥匙串(keychain)中留下“垃圾”(当然我希望他们永远不会这样做，但让我们现实一点，有些人会)

尤其是最后一点过去一直困扰着我(在共享 Web 凭据和自动填充成为一件事之前，或者当我的应用程序没有关联的域时)。与 macOS 不同，iOS 帐户和密码功能(在“设置”应用程序中)不会列出所有密码，而仅列出 Safari 使用的密码(即共享的 Web 凭据)，对吗？ macOS 上的钥匙串(keychain)访问提供了一种查看和管理所有凭据的方法，即使是那些未通过 iCloud 同步的凭据。

我理解为什么在 iOS 上没有提供相同的功能，但这也意味着对于我的应用程序(本地)保存到“它的”钥匙串(keychain)“部分”的那些密码，只有当我在我的应用程序中为此提供 UI 时才能对其进行管理。如果用户在使用该应用程序之前卸载了该应用程序，该项目将保留在钥匙串(keychain)中，至少我几年前尝试时是这样。

我现在的主要问题是，忽略文章的建议而仅依赖共享的 Web 凭据来存储密码不是更容易吗？这是他们可以在“设置”中编辑的部分(如果需要的话)，它也会反射(reflect)在网站上所做的任何密码更改。我会像这样设计我的应用程序:

首次启动:应用程序在登录屏幕上启动并通过自动填充提供用户名/密码

用户登录:应用程序在共享用户默认值中保存一个简单的标志，表明用户已登录。

应用程序重新启动，例如设备重启后:应用程序会因标志而跳过登录屏幕，并从共享的 Web 凭据中获取密码和用户名(当然，假设用户之前授予了它的权限)

用户明确注销:应用程序删除标志，基本上将所有内容设置回首次启动

用户从共享的 Web 凭据中删除用户名和密码(例如在设置应用程序中或在 macOS 上使用钥匙串(keychain)访问):应用程序在检测到这一点后立即回退到登录屏幕(例如在尝试远程请求时或重新启动后)，无论标志如何。我认为这最符合用户的意图(如果您删除密码，您不希望某些应用程序在您注销之前保留它)

此设置将避免钥匙串(keychain)和共享网络存储中的不同项目出现任何问题，并且它还会立即将网页中完成的更新传播到应用程序(无论如何，这就是我对应用程序的意图)。有什么可以阻止这个应用程序运行的吗？

(注意:我在苹果开发者论坛上问了同样的问题，所以如果你也看到了，不要混淆。我会从那里更新任何可能的答案，反之亦然。)

编辑以解决@Aaron 的回答:

非常感谢您提供的信息。您的回答帮助我意识到我误解了共享 Web 凭据的一些内容:我假设对于具有关联域的应用程序，您可以在没有用户交互的情况下访问凭据(可能在初始授权之后)。就像您可以在应用程序请求凭据时在 macOS 上设置复选框一样。我现在意识到这是错误的，在 iOS 上，您总是需要与用户进行验证，谢谢。

为了完整起见，我仍然想指出您所说的其他一些事情:

你是对的，我们最终将使用基于 token 的身份验证，所以我会将它保存在钥匙串(keychain)中(可能除了密码，见下文)。一开始我只是尽量让问题保持简单。

我们的应用程序就像一个电子邮件客户端，您可以在其中更新新传入的“邮件”。类似用户默认设置中提到的“登录标志”因此只会指示应用程序是否应该像订阅收件箱一样运行。就像在邮件中一样，即使在重新启动后，您也不会期望必须登录。

出于这个原因，我可能最终会将用户的密码与 token 一起保存在(本地)钥匙串(keychain)中。如果 token 过期，我可以在没有用户交互的情况下请求一个新的，这在我们的一般站点和应用程序设计中很重要。只有当该请求失败时，我才会使用共享的 Web 凭据(在此过程中更新我的本地凭据副本)。

就其值(value)而言，您提到的最后一点可能值得商榷。例如，在 macOS 上(您可以在其中编辑整个钥匙串(keychain)，而不仅仅是 Safari 密码)实际上会使您退出应用程序。再次以邮件为例。如果收件箱的钥匙串(keychain)项目不见了，邮件会在下次启动时重新询问它并尝试访问内容(在某种程度上实际上是一种“某种”登录)。

再次，非常感谢您的回答，现在我可以关闭一个开放的待办事项。 :) 还要感谢@HamZa 提供赏金!

Answer 1

考虑到这个建议:

Do not use the shared web credentials as your primary storage for secure user credentials. Instead, save the user’s credentials in the keychain, and only use the shared web credentials when you can’t find the login credentials in the keychain.

这里的主要问题是共享 Web 凭据过程有点笨拙——它需要用户交互并且需要时间来解析凭据。因此，如果用户已经通过您的应用程序进行了身份验证，您希望完全避免向他们显示登录页面。您可以通过将凭据存储在应用程序的钥匙串(keychain)中来实现此目的，您可以在没有网络连接或用户许可的情况下立即访问它们。

这并不意味着您需要将用户的密码存储在钥匙串(keychain)中。通常，您会在钥匙串(keychain)中存储类似 OAuth 访问 token 的内容。此 token 的存在意味着用户已通过身份验证 - 如果 API 端点拒绝您的 token ，则您可以将它们带回登录页面。

这个建议:

User logs in: App saves a simple flag in the shared user defaults indicating the user is logged in.

可能不安全，具体取决于您隐藏在登录页面后面的内容，但通常属于用户的任何内容都应该需要有效的 token 才能访问，而不仅仅是用户默认值中的 bool。

I think this matches the user intention best (if you delete a password you don't want some apps to hold onto it until you log them out)

我不同意这一点；我不希望 iOS 应用程序退出，因为我从 Safari 钥匙串(keychain)中删除了密码。