您需要了解的有关 OAuth2 和使用 Facebook 登录的信息
已发表: 2022-03-10如果您想知道 OAuth2 是什么，它是允许任何人使用其 Facebook 帐户登录的协议。 它为应用程序和各地网站上的“使用 Facebook 登录”按钮提供支持。
本文将向您展示“使用 Facebook 登录”的工作原理，并解释其背后的协议。 您将了解为什么要使用 Facebook、Google、Microsoft 或支持 OAuth2 的众多其他公司之一登录。
本文将向您展示“使用 Facebook 登录”的工作原理，并解释其背后的协议。 您将了解为什么要使用 Facebook、Google、Microsoft 或支持 OAuth2 的众多其他公司之一登录。
我们将看两个例子：为什么 Spotify 使用 Facebook 让您登录 Spotify 移动应用程序，以及为什么 Quora 使用 Google 和 Facebook 让您登录其网站。
关于 SmashingMag 的进一步阅读：
- 构建移动应用程序的四种方法
- 如何构建诚实的用户界面并帮助用户做出更好的决策
- 让您的 Android 应用在发布后保持流行
- Spotify 播放列表为您的编码和设计课程加油
在 OAuth2 之前
几年前，OAuth2 赢得了一场标准大战。 它是主要供应商支持的唯一身份验证协议。 Google 为其所有 API 推荐 OAuth2，而 Facebook 的 Graph API 仅支持 OAuth2。
了解 OAuth2 的最佳方式是查看它之前的内容以及为什么我们需要不同的东西。 这一切都始于基本身份验证。
基本认证
身份验证方案关注两个关键问题：你是谁？ 你能证明吗？
问这两个问题的最常见方法是使用用户名和密码。 用户名说明你是谁，密码证明了这一点。
Basic Auth 是第一个 Web 身份验证方案。 这听起来很有趣，但“基本身份验证”是它在 1999 年首次发布的规范中的实际名称。
基本身份验证允许 Web 服务器以浏览器理解的方式请求这些凭据。 服务器返回一个 HTTP 响应代码401 （这意味着需要身份验证），并在响应中添加一个名为WWW-Authenticate的特殊标头，其特殊值为Basic 。
当浏览器看到此响应代码和此标头时，它会显示一个弹出登录对话框：
Basic Auth 的优点在于它的简单性。 您不必编写登录屏幕。 浏览器处理所有这些，只需将用户名和密码发送到服务器。 它还使浏览器有机会专门处理密码，无论是通过为用户记住密码、从第三方插件获取密码还是从操作系统获取用户凭据。
缺点是您无法控制登录屏幕的外观。 这意味着您无法设置样式或添加新功能，例如“忘记密码？” 链接或创建新帐户的选项。 如果您想要更多自定义，则必须编写自定义登录表单。
自定义登录表格
自定义登录表单为您提供所需的所有控制。 您编写一个 HTML 表单并提示输入凭据。 然后，您提交表单并以您想要的任何方式处理登录。 您可以完全控制：您可以设置样式、询问更多详细信息或添加更多链接。
一些网站，例如 WordPress，使用简单的登录屏幕形式：
LinkedIn 允许用户在同一页面上登录或创建帐户，而无需转到网站的其他部分：
基于表单的登录非常流行，但它有一个主要的根本问题：用户必须告诉网站他们的密码。
保守秘密
在安全圈中，我们称密码为机密。 这是一条只有你拥有并证明你是你的信息。 秘密也可以不仅仅是密码； 我们稍后再谈。
一个网站可以采取世界上所有的安全措施，但如果用户共享他们的密码，那么这种安全性就消失了。 黑客在 2010 年入侵了 Gawker 网站，暴露了许多用户的密码。 虽然这对 Gawker 来说是个问题，但问题并不止于此。 大多数人重复使用密码，因此黑客从 Gawker 获取泄露的数据并试图登录更重要的网站，例如 Gmail、Facebook 和 eBay。 任何将 Gawker 密码用于更重要事情的人所失去的远比关于 Hulk Hogan 性爱录像带的最新八卦要多得多。
确保您的用户不会为多个帐户重复使用密码是问题的前半部分——而且这是不可能的。 只要人们必须在互联网上创建不同的帐户，他们就会重复使用他们的密码。
问题的后半部分是安全地存储密码。
当有人登录你的应用程序时，你需要验证他们的密码，这意味着你需要一个副本来验证它。 您可以将所有用户名和密码存储在某个数据库中，但现在您可能会丢失这些密码或被黑客入侵。 最佳实践是使用散列函数，例如 SHA-2 函数之一。 此函数以您永远无法取回的方式加密数据，但您可以复制加密：“我的密码”每次都会散列为bb14292d91c6d0920a5536bb41f3a50f66351b7b9d94c804dfce8a96ca1051f2之类的内容。
现在我们已经离开了高草：我告诉你如何实现加密协议。 接下来，我将不得不解释如何在您的数据中添加盐，以及要阅读哪些关于中间人攻击的教科书。 你想做的只是写一个应用程序，现在你必须成为一名安全专家。 我们需要退后一步。
OAuth2
您可能不是安全专家。 即使你是，我仍然不会相信你的密码。 OAuth2 为您提供了更好的方法。
例如，我在 iPad 上使用 Spotify。 我每月付给公司 10 美元听音乐。 Spotify 只允许我在三台设备上访问，所以我需要一个密码来确保没有其他人使用我的帐户。 我的 Spotify 帐户不是一个大的安全问题。 被黑不会是世界末日，但公司确实有我的信用卡，所以我想确保我是安全的。
我几乎没有登录过 Spotify，所以我不想创建另一个帐户并且必须记住另一个密码。 Spotify 给了我一个更好的选择：
我可以使用我的 Facebook 帐户登录。当我点击该按钮时，Spotify 会将我发送到 facebook.com，然后我在那里登录。 这似乎是一个小细节，但却是整个过程中最重要的一步。
Spotify 的程序员本可以自己编写登录表单，然后使用后端 API 将我的用户名和密码发送到 Facebook，但我不希望他们这样做有两个重要原因：
- 我不信任 Spotify 的 Facebook 密码。 我使用 Facebook 与朋友联系，我不想被黑客入侵。 我不相信 Spotify 会正确处理密码。 我也不相信它会避免用它做一些有趣的事情的诱惑。 也许它会尝试存储它以便以后可以使用它。 也许它有一个错误，会在将其发送到 Facebook 之前将其写入某个文件，因此黑客可以抓住它。 对不起，Spotify； 我只是不是那种信任的人。
- 我不想让 Spotify 做所有事情。 我想让 Spotify 播放音乐。 当我听辣妹的时候，我不想把它贴到我朋友的墙上。 我也不想让它下载我的朋友列表并让他们加入 Spotify。 如果我给 Spotify 我的 Facebook 密码，那么它可以在 Facebook 上以我的身份登录； 它可以做我能做的任何事情。
Spotify不想这样做还有两个重要原因：
- Facebook 有多种登录方式可供我选择。 我可以使用我的用户名和密码登录，也可以使用 Facebook 应用程序登录。 我还可以从 Facebook 找回密码或获得 Spotify 无法提供的帮助。 如果我只是给 Spotify 我的密码，我不会得到任何这些选项。
- 我的秘密可能不是密码。 . 密码对于我每月 10 美元的 Spotify 帐户来说足够安全，但对于我的银行或更重要的东西来说可能还不够。 我可以提供许多其他秘密：我可能有一张智能卡，或者我可能生活在碟中谍电影中并使用视网膜扫描仪。
我不在《碟中谍》电影中，但在现实世界中，许多公司使用双因素身份验证，例如密码和其他东西。 最常见的方法是使用手机。 当您想登录时，公司会向您发送一条带有特殊代码的文本，该代码持续几分钟； 然后您输入代码或使用应用程序输入代码。
现在，该公司确信没有人可以在没有您手机的情况下登录您的帐户。 如果有人窃取了您的密码，他们仍然无法登录。只要您不丢失手机，一切都是安全的。
Facebook 不是唯一的 OAuth2 提供商。 当我使用我的 Google 帐户登录 Quora 时，Google 会告诉我 Quora 想要做什么并询问是否可以：
我可能允许 Quora 查看我的电子邮件地址和我的基本个人资料数据，但我不希望它管理我的联系人。 OAuth2 向我展示了 Quora 想要的所有访问权限，允许我选择我授予访问权限的内容。
所以，这些就是 OAuth2 的优点。 让我们看看它是如何工作的。
OAuth2 的工作原理
Facebook、Google 和大多数其他 OAuth2 提供商对待本地客户端和 Web 客户端的方式不同。 原生客户端被认为更安全，它们获得的令牌和刷新令牌可以持续数月。 Web 客户端获得的令牌要短得多，通常在用户关闭浏览器或有一段时间没有点击网站时超时。
在这两种情况下，登录过程是相同的。 不同之处在于用户需要通过它的频率。
OAuth2 登录遵循以下一般步骤：
- 用户尝试做一些需要身份验证的事情。 这可以像打开应用程序或单击“登录”按钮一样简单。
- 应用程序或网站确定用户尚未登录并开始登录过程。 它通过打开一个网页并将其发送到 Facebook、Google 或任何其他提供 OAuth2 的网站上的特殊 URL 来实现这一点。
为 OAuth2 提供者打开一个新的浏览器窗口是关键的一步。 这就是允许提供商显示他们自己的登录表单并询问每个用户他们需要的任何登录信息的原因。 大多数应用程序使用嵌入式 Web 视图来执行此操作。
除了提供商的登录 URL，您还需要发送一些 URL 参数来告诉提供商您是谁以及您想做什么：
-
client_id这告诉 OAuth2 提供者您的应用程序是什么。 您需要提前注册您的应用以获取客户端 ID。 -
redirect_uri这告诉提供者你完成后想去哪里。 对于一个网站，这可以返回到主页； 本机应用程序可以转到关闭 Web 视图的页面。 -
response_type这告诉提供者你想要什么。 通常，此值要么是token，表示您需要访问令牌，要么是code，表示您需要访问代码。 提供者还可以扩展此值以提供其他类型的数据。 -
scope这告诉提供者你的应用想要访问什么。 这就是 Google 知道 Quora 要求访问以管理您的联系人的方式。 每个提供者都有一组不同的范围。
还有一些额外的字段可以增加更多的安全性或帮助缓存。 某些提供商还可以添加更多字段，但这四个是重要的。
一旦您的应用程序打开 Web 视图，提供商就会接管。 他们可能只要求一个简单的用户名和密码，或者他们可能会显示多个屏幕，要求从您最喜欢的老师的名字到您母亲的娘家姓等任何内容。 这完全取决于他们。 重要的部分是，当提供者完成后，他们会重定向回你并给你一个令牌。
一切都与代币有关
该过程完成后，提供者将为您提供一个令牌和一个令牌类型。 有两种类型的令牌：访问令牌和刷新令牌。 您拥有的客户类型将决定您可以请求哪些类型的令牌。
当我登录我的 Spotify 应用程序时，我可以保持登录数月，因为假设我的手机仅供我使用。 Facebook 信任 Spotify 应用程序来管理令牌，我相信 Spotify 应用程序不会丢失令牌。
当访问令牌超时（通常在一到两个小时内）时，Spotify 可以使用刷新令牌来获取新令牌。
刷新令牌持续数月。 那样的话，我一年只需要在手机上登录几次。 不利的一面是，如果我丢失了该刷新令牌，其他人可能会使用我的帐户数月之久。 刷新令牌非常重要，以至于 iOS 为令牌提供了一个钥匙串，它可以确保加密并安全地存储它们。
在 Web 应用程序中使用 OAuth2 的工作方式相同。 您可以在框架、iframe 或单独的窗口中打开 OAuth2 登录请求，而不是使用 Web 视图。 您也可以在当前页面上打开它，但这会导致您在有人需要登录时丢失所有 JavaScript 应用程序状态。
当我使用网络浏览器登录 Quora 时，我没有获得刷新令牌。 他们希望令牌超时并在我退出浏览器甚至只是出去吃午饭时提示我再次登录。 不受信任的客户端无法刷新令牌，因为无法信任他们持有重要的刷新令牌。 它更安全但不太方便，因为它们会更频繁地提示您再次登录。
在您的应用程序中使用 OAuth2
现在您知道了 OAuth2 的工作原理，但您可能不想实现自己的 OAuth2 客户端。 如果您无法入睡，您可以阅读整个 75 页的 OAuth 2.0 规范，但您不需要阅读。 一些很棒的库可供您使用。
iOS 内置了对 OAuth2 的支持。 Corrina Krych 有一个关于在 Swift 中使用 OAuth 2.0 的非常有用的教程。 它将引导您了解如何获取令牌、如何将视图集成到您的应用程序中以及存储令牌的位置。
Android 还内置了对 OAuth2 的支持。 我必须承认我并不熟悉它，因为我专注于 iOS，但文档中有一些很好的部分可以向您展示示例和一些开源库，以使其更容易。
JavaScript 没有对 OAuth2 的内置支持，但是所有主要的 JavaScript 库都有客户端。 React 完全支持 OAuth2。 AngularJS 为许多项目提供了对 OAuth2.0 的第三方支持。 我什至写了其中之一。
拥有 OAuth2 客户端后，您需要选择提供者。
你相信谁？
这里最大的假设是我更信任 Facebook 而不是 Spotify。 我没有充分的理由。 Facebook 没有公开其内部安全，我也没有好办法对其进行审核。 Spotify 也没有。 没有针对 OAuth2 安全性的消费者报告。 我基本上信任 Facebook，因为它更大。 我信任 Facebook，因为其他人也信任。
每次单击“使用 Facebook 登录”按钮时，我都会更加信任 Facebook。 如果 Facebook 丢失了我的密码，那么黑客不仅可以访问我的 Facebook 帐户，还可以访问我的 Spotify 帐户以及我使用我的 Facebook 帐户登录的任何其他服务。 好处是只有一个地方我必须重设密码才能解决问题。
我不必信任 Facebook，但我必须信任某人。 必须有人对我进行身份验证。 我需要选择我信任的提供者。
选择 OAuth2 提供者
Wikipedia 维护了一个 OAuth 提供者列表，但您不会关心其中的大多数。 最大的是 Facebook 和谷歌。 您可能还想看看亚马逊或微软。
它们都很大并且易于集成。 Facebook 提供了注册应用程序的说明。 谷歌也有类似的步骤。 基本思想是您创建一个开发者帐户，然后创建一个应用 ID。 然后，提供商会为您提供一个客户端 ID，您可以使用它来发出请求。
您还可以选择多个提供商。 Quora 允许您使用 Facebook 或 Google 登录； 因为它们都使用 OAuth2，所以您可以对两者使用相同的代码。
OAuth2 缺少什么
OAuth2 在解决复杂问题方面做得非常好，但它缺少一些东西：
- 标准并不完全标准。 我从来没有编写过一个 OAuth2 客户端，它可以在没有一些
if语句的情况下同时登录 Facebook 和 Google。 每个人对规范的解释都不同，每个人的细节几乎没有什么不同。 他们也总是对提供什么范围有不同的想法。 使用库与 OAuth2 集成对解决这个问题有很大帮助，但它在您的应用程序代码中永远不会 100% 透明。 - 注销很棘手。 . 每个使用 OAuth2 的应用程序或网站都有一个注销按钮，但大多数人只会忘记令牌而不会使它们失效。 该应用程序将忘记您当前的所有令牌并允许其他人登录，但您的令牌仍然有效。 如果黑客窃取了您的令牌，他们仍然可以使用它并以您的身份登录。
有一个单独的规范用于使 OAuth2 令牌失效，但许多主要提供商都没有采用它。 如果黑客获取了您的刷新令牌，OAuth2 不提供恢复方法； 即使您可以删除令牌的本地副本，黑客仍然会拥有它。 许多提供商为您提供了暂停帐户的方法，但没有标准的方法可以做到这一点。
为了保护 OAuth2，这是一个难题，因为许多提供商使用公钥密码术来创建无状态令牌。 这意味着服务器不记得它创建的令牌，因此以后不会忘记它们。
OAuth2 的另一个主要问题是您依赖于您的提供商。 当 Facebook 出现故障时，您的应用程序中的“使用 Facebook 登录”按钮也会出现故障。 如果 Google 决定开始向您收取支持 OAuth2 的费用或要求您与其分享利润，那么您无能为力。 这是信任提供商的双刃剑：他们为您做了很多事情，但他们可以控制您的用户。
OAuth2 运行世界
即使缺少一些功能和很大的依赖性，OAuth2 仍然是一个很好的选择。 它使用户可以轻松登录您的应用程序，无需记住每个网站的密码，并信任您的安全性。 OAuth2 是一个非常受欢迎的选择。 它在行业中占主导地位。 没有其他安全协议能与 OAuth2 的采用相提并论。
现在您知道 OAuth2 来自何处以及它是如何工作的。 明智地选择信任谁，停止阅读有关安全存储加密密码的文章，并花更多时间编写令人惊叹的应用程序。