从技术上讲，向应用程序添加社交登录是记录最多的任务之一。每个提供商都有自己的教程，一个下午您就可以让“登录”按钮正常工作。正是这种轻松造成了陷阱：团队快速实施，跳过重要的决策，并在几个月后发现问题，当时已经有真正的用户与错误的选择相关联。
实践中的社交登录并不是遵循提供商的教程。这是关于您在打开教程之前做出的决定。身份、访问恢复、帐户链接、数据处理，这些决定决定了社交登录是否会成为坚实的基础，还是您将连本带利支付的债务。
本文是实施者的路线图。不是代码部分，它有详细的文档记录，而是决策部分，几乎没有人编写，也是发生代价高昂的错误的地方。
决定一：你的身份来源是什么
在进行任何集成之前，请确定系统中用户的定义。这是最重要也是最容易被忽视的问题。
如果你将你的身份锚定到提供商，“这个用户是这样那样的谷歌帐户”，你就被困住了。当用户想要更改提供商，或者您想要通过电子邮件添加登录时，就会成为迁移问题。相反，如果您将身份锚定到您控制的内容（通常是与经过验证的电子邮件关联的内部标识符），那么提供商只能看到进入您的帐户的方法，而不是他们的帐户。
实际决策：将每种登录方法视为指向唯一内部身份的凭证。同一用户可以拥有链接到其帐户的一项通过 Google 的条目、一项通过电子邮件和密码的条目以及将来的其他条目。身份是中心；登录方法是卫星。任何扭转这一局面的人都将付出高昂的代价来纠正它。
决策二：当提供者失败时会发生什么
社交登录引入了对产品关键路径的外部依赖：网关。您需要预先决定当此依赖项失败时会发生什么，因为它在某个时候会失败。
提供商可能会下线、改变政策、增加成本甚至停止服务。如果您唯一的[身份验证0] 形式就是通过此方式，那么这些事件中的任何一个都会将您的用户锁定在外，您的双手就会被束缚。
成熟的决定是不依赖单一路径。提供多个进入选项，并始终保留一种您可以控制的方法，例如电子邮件和密码或通过电子邮件发送的神奇链接。因此，即使提供商离线，用户也有一个地方可以访问它，并且您有办法帮助他们。访问连续性就是业务连续性。
决策三：如何合并帐户
这是区分成熟实现和业余实现的细节。同一用户在不同时间可能会尝试使用指向同一电子邮件的不同方法登录。在实施之前，您需要决定如何处理这个问题。
如果没有有意识的决定，默认结果通常是最糟糕的：应用程序使用每种方法创建一个新帐户，将用户的生活分割成并行的身份。历史分裂，数据明显丢失，呼叫支持。
正确的练习需要有明确的规则。当某人使用系统中已存在电子邮件的新方法登录时，应用程序必须识别现有帐户并提供将新方法链接到该帐户，而不是重复它。这取决于一项重要的预防措施：仅在提供商确认电子邮件已通过验证的情况下才信任该电子邮件。基于未经验证的电子邮件链接帐户为某人接管他人的帐户打开了大门。这是一个安全决定，而不仅仅是方便。
决策四：您将请求并保留哪些数据
提供商提供对一系列用户数据的访问。在入职之前，您需要确定您要要求什么，答案应该是“最低限度”。
要进行身份验证，您通常只需要一个稳定的标识符和经过验证的电子邮件。除此之外的一切都是您开始保留、保护和证明其合理性的数据。 “以防万一”要求广泛的访问权限会造成没有回报的责任，并增加许可屏幕上的摩擦，一些用户在看到侵入性请求时会放弃。
这个决定变成了第二个决定：如何处理你收到的东西。保存最少必要的数据，定义保存多长时间，并清楚每个数据的用途。同时，该规则是良好的架构，也是遵守 [LGPD1] 的自然途径，这需要最终性和最小化。在实施时决定这一点是微不足道的；在数据已经积累的情况下减少以后的收集是很费力的。
决定五：隐私和退出权
实施社交登录意味着假设提供商、您的应用程序和用户之间存在个人数据流。 [LGPD2 认真对待这一流程，一些决策需要从一开始就纳入路线图。
您需要明确告知用户通过社交登录获取哪些数据以及用于什么目的。对待他们需要有法律依据。并且您需要保证用户能够独立于社交帐户删除应用程序帐户，删除应用程序帐户不能要求他们使用社交网络，并且取消链接不能留下分散的孤立数据。
最后一点是在急于实施的过程中最容易被遗忘的。输入流得到了所有的关注；流出量，几乎没有。但删除权是强制性的，就像登录是可选的一样。将输出与输入一起规划可以避免将来在业主请求或检查的压力下重写。
把它当作一个下午的任务的陷阱
贯穿整个脚本的风险是文化性的：将社交登录视为一项小任务，因为教程很短。代码很短；后果是长期的。
成熟的团队认识到[身份验证3]是基础。出错不会导致孤立的错误，它会导致身份、数据、安全性和合规性方面的连锁问题，所有这些问题都很难通过系统上的活跃用户来修复。在实施前一个小时的有意识的决策可以节省数周后的修补时间。这是值得做出的权衡。
抵制一次添加太多提供商的诱惑也是值得的。每个提供者都是一个需要维护的集成、一个需要监控的策略、一个需要测试的流程。从对您的受众有意义的内容开始，并在有真正需求时添加其他内容。
结束
实践中的社交登录在提供商的教程中并未得到解决。它解析为之前的决策：身份所在的位置、提供者失败时会发生什么、如何统一帐户、请求什么数据以及用户如何退出。这些选择一开始很容易做出，但以后重做的成本却很高。
支持产品的社交登录与成为事件来源的社交登录之间的区别不在于集成代码的质量，而在于其之前决策的质量。在打字之前花点时间做出决定。
如果您要在应用程序中实现身份验证，则值得在第一行代码之前浏览此决策路线图。博客上还有其他关于 [OAuth4´、身份和 LGPD 的文章，深入探讨了这些领域。
另请阅读
- [应用程序中的社交登录：通过示例来规划什么有效、什么出错5
- [应用程序中的社交登录：实施和最佳实践6
- [应用程序身份验证：完整的安全性和用户体验指南7
- [应用程序中的身份验证 - 使用清单的最佳实践8
- [应用程序中的身份验证 - 最佳实践与示例9
- [OAuth 什么 E10