三、OAuth

创造视觉化效果只是成功的一半; 另一半是获取高质量的数据来驱动可视化。 您可能希望利用许多潜在的数据源。 几乎每个国家都有一个负责收集和分析经济和社会统计数据的国家统计组织。 在过去几年中，许多政府已经开始采取开放数据计划。 许多企业还专注于提供可用的数据; 想想各种证券交易所提供的数据量。 您甚至可以访问用于驱动可视化的公司内部数据，或者您的可视化可能是为您提供数据的更大应用的一部分。

另一个来源，也是我们对这本书感兴趣的来源，是社交媒体。 社交媒体网站有大量可供用户使用的数据。 绝大多数社交媒体网站提供 api 以编程方式访问数据。 通常，这些数据是为您的用户帐户定制的。 例如，Twitter 会过滤你所关注的用户的 tweets, Facebook 也会显示你的朋友的更新。 有些数据是受限制的，只有特定群体的人可以看到。 你可能不想让全世界都看到你的 Facebook 更新，所以你设置了只允许好友看到的权限。 为了个性化数据，大多数社交网站都需要对其 api 进行身份验证和授权。

通常情况下，你想向用户显示的数据与他们自己的社交媒体账户相关。 在大多数情况下，您的可视化不会与要使用的数据托管在同一个系统上，如下图所示。 更重要的是，你的可视化的消费者，最终用户，很可能是在另一个系统上:

OAuth

这意味着需要有某种方式将社交媒体数据从社交媒体站点获取到你的可视化页面，然后传递给最终用户。 表面上看，似乎有以下两种选择:

  • 问用户他们的社交媒体密码，并使用它来验证和检查身份验证与社交媒体 API
  • 要求用户检索可视化所需的数据，并将其发送到可视化

这两种选择都不是特别可取。 用户可能会拒绝透露他们的密码，尤其是像他们的社交媒体网站这样重要的东西。 你可能也不想拥有他们的密码，因为这对你来说是一个额外的安全问题。 大多数用户都不够精通技术，无法从他们的社交媒体网站提取所需的数据并将其发送到你的应用中。 即使是那些有技术技能的人也不会对所需要的工作量印象深刻。 当然，可以建立和完善标准的输出机制，使其更易于用户使用，但在我们为此开发一个系统之前，也许还有第三种方法吗?

诀窍似乎在于找到一种方法，在不告知中间的可视化站点太多细节的情况下，将最终用户的凭证信息获取到社交媒体站点。 与许多计算机问题一样，在计算机世界之外也可以找到并行问题和解决方案。

许多车库的电子开门器和家庭安全系统都提供客人密码。 这些代码可能对它们有限制，比如它们只在一周的特定天数或特定次数运行。 这些账户的目的是为清洁人员或贸易人员提供进入你家的有限通道。 据说在高端汽车中也存在类似的概念:代客钥匙会导致汽车在受限模式下运行。 可以使用类似的机制来允许您可视化访问社交媒体网站的受限部分。

OAuth 协议提供了一种验证应用的机制，可以在不需要知道密码的情况下使用你的社交媒体数据和功能。

在这一章中，我们将从一个较高的层次来看 OAuth 是如何工作的，然后尝试使用我们现有的凭证在一些社交网络上进行身份验证。

认证与授权

通常，身份验证和授权的概念之间存在混淆。 认证是确保某人是他们所说的那个人的行为，授权是确保某人有权利执行某一行为的行为。 这些概念是相关的，并且经常是同一步骤的一部分。 OAuth 打破了两者之间的关系。 虽然通常有一个身份验证步骤需要登录到服务器，但是没有规定执行身份验证的方式。 如果用户已经登录到服务器站点，则授权步骤对用户可能是透明的。 服务器可以使用它希望的任何方法来执行身份验证。 这为打开了大门，允许多因素身份验证或甚至额外授权身份验证。 例如，您的可视化可以请求使用 OpenID 委托身份验证的 StackOverflow 的信息。 因此，当用户请求访问 Stack Overflow 数据时，用户实际上可能需要使用谷歌帐户登录，该帐户将身份验证细节传递给 Stack Overflow，而 Stack Overflow 又将授权凭证传递给可视化。

在为可视化获取数据时，一定要记住身份验证和授权之间的区别。

OAuth 协议

在 OAuth 引入和广泛更新之前，您需要与之交互的每个服务都提供了自己的授权协议。 这些方法有明显的分歧。 每次想要使用新的 API 时，都必须学习和实现新的授权方案。 这使得与大量服务的交互非常困难。

OAuth 的创建是为了解决不同站点的授权缺乏标准化的问题。 版本 1.0 的创建花了大约两年时间，许多主要的行业参与者以及较小的感兴趣的团体都为此做出了贡献。

OAuth 版本

目前，OAuth 的野生版本主要有两个:1.0a 和 2.0。 版本 1.0a 是对 1.0 规范的安全更新，修正了会话固定攻击。 2.0 规范明显偏离了 1.0a，不幸的是，仍然存在使用不同协议的混合服务。 关于 2.0 规范的安全性存在一些政治上的争论，这导致许多公司仍然使用 1.0a 版本。 最大的区别是 OAuth 1.0 被设计成可以在未加密的连接上使用。 当 OAuth 1.0 创建时，SSL 证书对于许多小型提供商来说非常昂贵。 因此，指定了一系列复杂的签名请求，即使不安全的连接也可以像安全的连接一样工作。

现在，SSL 证书的成本越来越低，而且硬件的速度也足够快，因此即使是最小的启动也能很好地获得 SSL 证书。 因此，OAuth 2.0 版依赖于 SSL 来提供大部分的安全性。 在未加密链接上使用 OAuth 2.0 是不安全的。 出于我们的目的，我们可以在很大程度上忽略 OAuth 版本之间的其他差异。 但是，您应该意识到，您为一个社交媒体网站编写的授权和身份验证工具可能在其他网站上不起作用。 甚至可能由于实现的差异，您的授权方法无法在两个完全支持 OAuth 2.0 的不同站点之间工作。

OAuth 为我们在本章前面看到的球员定义了一些不同的名字，所以让我们使用这些术语。 先前图的更新视图如下所示:

OAuth versions

资源所有者是“拥有”数据的人。 例如，你“拥有”自己在 Facebook 上的更新。 Client是请求访问数据的站点，Server是同时拥有资源所有者的数据和凭据信息的站点。 被拥有的数据通常被称为受保护资源，因为它是 OAuth 层正在保护的。 为了清晰起见，我保留了之前的图标，但客户端不必是可视化的，服务器也不必是社交媒体站点。

您可能已经使用了 OAuth 协议，即使您不知道它。 如果您曾经授予应用使用您的 Twitter 帐户的权限，那么您已经使用了 OAuth。 、、、等官方推特应用使用 OAuth 进行授权。 每个应用都请求从 Twitter 访问特定功能。 如果你是 Twitter 用户，你可以在设置面板上看到你授权使用 Twitter 账户的应用。 这些应用都被授予了与 Twitter 互动的权限，就像它是你一样，如下面的截图所示:

OAuth versions

在前面的截图中，您会注意到每个应用旁边都有一个按钮，允许撤销该应用的访问。 这是 oauth 的一个伟大特性——应用永远不知道您的密码，所以您可以删除它们作为您的能力，而无需更改您的密码。 如果您确实希望更改您的 Twitter 密码，您只需要对 Twitter 进行更改，而不需要对您已授权代表您行事的所有服务进行更改。

如果 Twitter 意识到www.wordpress.com已经被泄露，他们可以立即撤销所有用户对该应用的访问。 保存凭证是一个困难的问题，而不是许多开发人员希望承担的问题。 如果可信的公司(如 Twitter)能够保留凭证，那么就消除了一个常见的故障点。

让我们更深入地了解一下 OAuth 是如何工作的。 为了理解发生了什么，浏览一个示例是很有用的。 在这个例子中，我们的可视化将使用 Facebook 的 Graph API 请求一些信息。 GraphAPI 是 Facebook 为开发商提供的访问社交图谱(游戏邦注:实际上是用户属性的集合)的界面。 Facebook 是一个 OAuth 2.0 网站，所以这个例子将使用 OAuth 2.0 中描述的工作流。

我们想从 Facebook 获取信息。 当我们第一次加载可视化时，我们会看到一个屏幕，允许用户点击按钮来访问 Facebook 信息，如下面的截图所示:

OAuth versions

当我们第一次设置我们的可视化站点时，我们将向 Facebook 请求一个认证令牌。 这个令牌是由 Facebook 授予我们的网站单独。 作为向 Facebook 注册应用的一部分，我们将进入一个可以使用令牌的域。 这在防止其他人使用我们的令牌方面提供了一些安全性。 服务器可能会进行广泛的检查，以限定应用访问其受保护的数据。

我们的网站将生成一个请求到 Facebook OAuth 端点，其中将包括生成的令牌。 典型的 URL 如下所示:

https://www.facebook.com/dialog/oauth?client_id= 591498037422486&redirect_uri=http://visualization.com/&response_type=token

提示

一个更详细的针对 Facebook 的认证例子可以在第 7 章，Facebook中找到。

可视化现在直接重定向到 Facebook 登录页面，它会询问你的登录信息，如下面的截图所示:

OAuth versions

一旦您输入了该信息并正确地通过 Facebook 认证，您将被重定向回您在redirect_uri参数中指定的页面。 这通常是你的原始页面。 附加到 URI 的将是一个非常长的令牌，由 Facebook 生成，并在随后与其 API 的通信中使用:

http://localhost:8080/Visualization1.html#access_d8Ava9mMBALMG0FQp22SEn5La7mtC27evICrZB5ToVHdJRZC2FYdFmnIsveVKhcikSeVZAEAZAHBliKEeGvrKHnb5FnU5VoCooy49FIoJuzca3oHeYuNUZAatdgjUEr2tDzZBB8CJGmPkHdmNe3RyS1l9XAcTKwGGVAy6FB0gZDZD&expires_in=6667

根据您的可视化请求的权限，Facebook 可能会提示您显式地将这些权限授予可视化。 向应用授予权限是 OAuth 的关键功能。 Facebook 有大约 50 种不同的权限，你的应用可以请求。 这包括以下内容:

  • email
  • user_likes
  • user_location

授权应用访问你的 Facebook 信息的提示如下图所示:

OAuth versions

在本例中，示例可视化请求访问我的位置，该位置受user_location权限保护。 在 Facebook 的例子中，被授予的权限被编码在要使用的令牌中，但这并没有在 OAuth 协议中明确列出。

一旦权限被分配，Facebook 会将用户重定向回你的redirect_uri,，允许你利用令牌来查询 Facebook API，如下图所示:

OAuth versions

对于一些 OAuth 站点，建议在此阶段执行额外的调用，以确保返回的令牌与当前应用匹配。 通过发送应用的 ID 和身份验证步骤返回的令牌，我们可以获得一些验证细节，可用于确认登录没有被劫持。 不是每个网站都需要这个步骤; 这只是 Facebook 建议的一种附加安全措施。 通过凭据，我们可以调用 Graph API。 在本例中，可视化发出一个非常简单的请求来检索经过身份验证的用户的姓和名。 你可以在第 7 章，Facebook中看到请求是如何表述的。

就是这样! 因此，OAuth 将授权和身份验证步骤委托给第三方，而不需要复杂的工具。 OAuth 只使用普通的 HTTP 和 SSL。 OAuth 的工作流程几乎完全如下图所示:

OAuth versions

OAuth 方言和需求的多样性可能很难理解。 找到正确的令牌组合来接受不同站点的正确身份验证几乎与 OAuth 之前使用的技术大杂烩一样困难。 OAuth 以难以理解和前后矛盾而闻名。 这可以归因于 OAuth 标准不像 HTTP 是标准那样是标准。 使用 HTTP 时，如果您符合该标准，您可以确信您的服务将能够与所有其他服务交互。 OAuth 没有提供相同级别的交互性保证。

如果您将使用许多不同的数据源，也许如果您正在创建一个 mashup，那么使用第三方服务与 OAuth 服务器通信可能是明智的。 即使您只使用一个数据源，您可能也不希望使用 OAuth 来使您的开发过程复杂化。 DailyCred 和 OAuth 等公司。 io 提供了一个服务，抽象了处理 OAuth 的困难。 它们允许通过一致的 API 使用众多不同的 OAuth 提供者进行身份验证。 适应各种 OAuth api 的艰苦工作由它们处理，让您可以自由地集中精力构建可视化。

通过 OAuth 验证 Facebook。 IO 就像运行下面几行代码一样简单:

OAuth.initialize('<Your Public key>');
OAuth.redirect('facebook', "callback/url");

本章中使用的可视化示例接近 70 行代码。

当然，这些服务有的金钱成本，也提供了额外的故障点。 与所有事情一样，必须小心确保为 OAuth 选择一个好的解决方案。

小结

虽然不是每个社交媒体网站都使用 OAuth，但了解 OAuth 如何工作以及如何使用它来促进 API 的使用，将最有可能改善您在开发可视化时的体验。 现在你应该能够解释 OAuth 是如何工作的。 在下一章中，我们将看一看可视化库。

版权属于：月萌API www.moonapi.com，转载请注明出处

本文链接：https://www.moonapi.com/news/1568.html