社交登录似乎是一个显而易见的决定。您无需让用户输入另一个密码，而是提供“使用 Google 登录”按钮或类似按钮，然后用户只需轻按两次即可输入。减少摩擦，增加注册。为什么有人会采取不同的做法？
答案是社交登录解决了一个真正的问题，并创造了后来才出现的其他问题。您今天赢得了转化，但随后却承担了依赖性、复杂性和隐私责任，这些都会给您带来损失。良好的规划意味着在将按钮放在屏幕上之前（而不是之后）了解这种权衡，因为已经有数千名用户做出了一个没有人深思熟虑的决定。
这篇文章实用且充满示例。这个想法是通过具体情况来展示精心策划的社交登录与令人头疼的登录的区别。
为什么社交登录会带来转化（以及何时不会）
收获是真实的。注册中的每一个附加字段都会减少转换，而密码是最糟糕的字段：人们需要发明它，记住它并在手机键盘上输入它。社交登录消除了所有这些。对于第一次会话起决定性作用的应用程序来说，这可能是用户登录或退出之间的区别。
但这种收获并不是普遍的。相反的例子是值得的。针对企业受众、在公司内部使用的应用程序，其用户可能没有社交提供商的个人帐户，或者没有阻止此类登录的策略。只提供社交登录会让人们望而却步。另一种情况：健康或金融应用程序，用户可能不想将他们的医疗或财务身份链接到他们的社交媒体帐户。隐私观念很重要，将其转换为休闲应用程序的按钮可能会在这里产生不信任。
本文的主题是：**社交登录是一种转换工具，而不是强制性标准。**正确的决定取决于您的用户是谁以及他们对链接帐户的信任程度。
示例：仅提供社交登录的错误
一种看似聪明但过时的模式：专门提供社交登录，没有电子邮件和密码替代方案。动机是简化，并且在短期内它是有效的。
该问题以多种形式出现。想象一下，您选择的提供商改变了规则，增加了成本，或者只是离线了几个小时。您的所有用户都被锁定在应用程序之外，您无法帮助他们，因为大门的钥匙掌握在另一家公司手中。另请想象一下，用户失去了对他们用来注册的社交帐户的访问权限，他们也失去了对您的应用程序的访问权限，并且没有取决于您的恢复路径。
实践教训：提供社交登录作为快捷方式，但始终有一条由您控制的[身份验证0]路径。完全依赖第三方作为您产品的入口，就是将您的业务连续性移交给其他人。
示例：同一用户拥有两个账户的问题
这是一个无声且常见的错误。用户今天通过“使用 Google 登录”进行注册。几周后，他回来了，不记得自己是如何进入的，并点击了“使用 Facebook 登录”，这使用了相同的电子邮件地址。如果您的应用程序无法处理此问题，则您只是为同一个人创建了两个单独的帐户。
损坏是具体的。该人的历史记录、购买、设置被分为两个身份，他们意识到“应用程序丢失了我的数据”。支持人员收到投诉后合并账户是一项微妙且危险的操作。
正确的计划预见到了这一点。用户的身份必须固定在稳定的东西上，通常是他们经过验证的电子邮件，而不是他们用来登录的提供商。当有人通过不同的提供商使用已注册的相同电子邮件地址进入时，应用程序必须识别出这是同一个人，并提供链接帐户，而不是创建新帐户。这是一开始就决定的；稍后修复它是昂贵的。
示例：请求太多权限并吓唬用户
社交登录提供商提供的访问权限远不止用户的基本身份、联系人列表、帖子、扩展个人资料数据。人们很容易要求一切“因为它可能有用”。这是产品和隐私错误。
看看效果。当用户点击“登录”并且权限屏幕要求访问他们的朋友列表和完整个人资料时，许多人会退缩。原本应该快速登录的行为变成了侵入性请求，而社交登录所承诺的转化在关闭时间就消失了。更糟糕的是：您开始存储不使用的数据，从而产生负债而没有收益。
好的做法是要求最低限度。要进行身份验证，您几乎总是只需要一个 ID 和经过验证的电子邮件。就问这个吧。如果稍后有一项功能需要额外的访问权限，请当时提出要求，并解释原因。每减少一个权限就意味着更多的信任和更少的需要保护的数据。
社交登录所拖累的隐私层
值得明确前面示例中贯穿的观点。社交登录不仅仅是身份验证；它是您、提供商和用户之间的个人数据流。 [LGPD1 适用于该流程。
您从提供商处收到的数据是个人数据，自您收到之日起就由您负责。这带来了具体的义务：拥有处理这些信息的法律依据，告知用户您收集的内容和目的，并尊重任何想要删除其帐户的人的请求，包括取消其与提供商的链接。许多人忘记了一个细节：用户需要能够独立于其社交帐户删除您应用程序上的帐户。
还有透明度。用户有权了解，在使用社交登录时，某些数据会在服务之间传递。将其隐藏在细则中是有效的，直到有一天它不再有效。清楚地对待这个问题又是在同一个决定中的转变和整合。
混淆便利性和安全性的陷阱
最后一次到期警告。社交登录很方便，但方便有时会与安全性混淆。它们不是同一件事。
将[身份验证2]委托给大型提供商确实比密码管理不善更安全，毕竟这些提供商在帐户保护方面投入了大量资金。但这转移了风险，而不是消除了风险。如果用户的社交帐户被盗，攻击者就会用它进入您的应用程序。您开始依赖您无法控制的第三方的安全。对于应用程序内的敏感功能，值得考虑独立于初始登录的额外验证层。
成熟的决定是将社交登录视为一种优缺点明确的产品选择，而不是一种不需要考虑安全和隐私的解决方案。
结束
社交登录是应用程序可用的最佳转换工具之一，也是自动实现时最昂贵的转换工具之一。这些例子显示了这种模式：收益是立竿见影的，成本是推迟的和无声的，规划决定了两者中哪一个最终更重要。
提供社交登录作为捷径，而不是唯一的门。将身份锚定在用户身上，而不是提供商身上。请求最小权限。按照 [LGPD3] 的要求和用户应得的方式对待数据。凡是采取这些预防措施的人都可以赢得转变，而不会继承麻烦。
如果您正在决定应用程序如何进行身份验证，那么在屏幕上放置任何按钮之前值得考虑这些权衡。博客上还有其他关于 [OAuth4´、安全和隐私的文章，对这些要点进行了更深入的探讨。
另请阅读
- [应用程序中的社交登录：实施和最佳实践5
- [社交登录实践：在应用程序中实施之前的决策路线图6
- [应用程序中的身份验证 - 最佳实践与示例7
- [应用程序身份验证：完整的安全性和用户体验指南8
- [应用程序中的身份验证 - 使用清单的最佳实践9
- [应用参与：策略与示例10