热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

我应该在共享Web凭据和(本地)钥匙串中保存密码

如何解决《我应该在共享Web凭据和(本地)钥匙串中保存密码》经验,为你挑选了1个好方法。

我正在设计一个与域名相关联的新应用程序的登录,即与SPA的对应物.显然我想用

iOS 11密码自动填充,和

共享Web凭据

我已阅读有关自动填充的文档以及观看WWDC视频.另外,我查看了有关共享Web凭据的文章,我认为该文章比新的,重新设计的自动填充更早.文章建议:

不要将共享Web凭据用作安全用户凭据的主存储.而是将用户的凭据保存在钥匙串中,并且只有在您无法在钥匙串中找到登录凭据时才使用共享的Web凭据.

这让我有点奇怪,因为它 - 意味着我必须涵盖更多可能的不一致,即以某种方式与共享的Web凭据同步密钥链(如果我在密钥链中有凭据以及共享的Web凭据,但它们是不同的?) - 如果我的用户用户卸载我的应用程序,可能会在钥匙串中留下"垃圾"(我自然希望他们不会这样做,但让我们现实,有些人会这样做)

特别是最后一点在过去一直困扰着我(在共享Web凭据和自动填充之前,或者当我的应用程序没有关联的域时).与macOS不同,iOS帐户和密码功能(在"设置"应用程序中)不会列出所有密码,只会列出Safari使用的密码(即共享的Web凭据),对吗?MacOS上的Keychain Access提供了一种查看和管理所有凭证的方法,甚至是那些未通过iCloud同步的凭证.

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

我现在的主要问题是,忽视文章的建议并仅依靠共享的Web凭据进行密码存储会不会更容易?这是他们可以在"设置"中编辑的部分(如果需要的话),它也将反映在网站上完成的任何密码更改.我会像这样设计我的应用程序:

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

用户登录:应用程序在共享用户默认值中保存一个简单标志,指示用户已登录.

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

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

用户从共享的Web凭据中删除用户名和密码(例如,在"设置"应用程序中或使用macOS上的"Keychain Access"):应用程序一检测到这一点就会回退到登录屏幕(例如,尝试远程请求时或重新启动后) ),不管国旗.我认为这最符合用户意图(如果你删除了一个密码,你不希望某些应用程序在你注销之前保留它)

这种设置可以避免在钥匙串和共享网络存储中使用不同项目的任何问题,并且它会立即将在网页中完成的更新传播到应用程序(这也是我对我的应用程序的意图).有没有什么可以阻止这个应用程序流动?

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


编辑以解决@Aaron的回答:

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

为了完整起见,我还想指出你说的其他一些事情:

你是对的,我们最终会使用基于令牌的身份验证,所以我会把它保存在钥匙串中(可能除了密码之外,见下文).我刚开始试着让这个问题变得简单.

我们的应用就像一个电子邮件客户端,您可以在其中更新新传入的"邮件 因此,在用户默认值之类的提及的"登录标志"将仅指示应用程序是否应该表现得好像订阅了收件箱.就像在Mail中一样,即使重新启动后你也不会想要登录.

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

对于它的价值,你提到的最后一点可能是值得商榷的.例如,在macOS上(您可以编辑整个钥匙串,而不仅仅是Safari密码)事实上会将您从应用程序中注销.再次邮件,作为一个例子.如果收件箱的钥匙串项目消失,Mail会重新询问下次启动并尝试访问内容(实际上是某种方式的"某种"登录方式).

再次,非常感谢你的回答,现在我可以关闭一个开放的待办事项.:)还要感谢@HamZa给予奖励!



1> Aaron Brager..:

考虑以下建议:

不要将共享的Web凭据用作安全用户凭据的主要存储。而是将用户的凭据保存在钥匙串中,并且仅当在钥匙串中找不到登录凭据时才使用共享的Web凭据。

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

这并不意味着您需要在钥匙串中存储用户的密码。通常,您会在钥匙串中存储OAuth访问令牌之类的东西。此令牌的存在意味着用户已通过身份验证-如果API端点拒绝了您的令牌,则可以将其带回登录页面。

这个建议:

用户登录:App在共享的用户默认设置中保存一个简单标志,指示该用户已登录。

可能会不安全,具体取决于您在登录页面后隐藏的内容,但是通常,属于用户的任何内容都需要有效的令牌才能访问,而不仅仅是用户默认的布尔值。


我认为这最符合用户的意图(如果您删除密码,则您不希望某些应用程序在您注销之前保留该密码)

我不同意这一点。我不希望iOS应用程序注销,因为我从Safari钥匙串中删除了密码。


推荐阅读
author-avatar
寂寞-无解
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有