WP REST API：设置和使用OAuth 1.0a身份验证

在本系列的前一部分中，我们通过安装WP REST API团队在GitHub上可用的插件，在服务器上设置了基本的HTTP身份验证。基本的身份验证方法允许我们通过在请求标头中发送登录凭据来发送经过身份验证的请求。虽然方便快捷，但这些凭据也有可能落入错误的人手中。因此，此方法仅应在安全网络上用于开发和测试目的。

为了在生产服务器上使用身份验证，需要一种更安全的方式发送经过身份验证的请求，而又不会暴露登录凭据的风险。由于采用了OAuth身份验证方法，因此可以发送这些请求，而不会以不安全的方式公开用户名和密码。

在本系列的当前部分中，我们将学习设置并使用OAuth身份验证方法与WP REST API插件一起使用。具体来说，我们将：

概述OAuth身份验证方法及其工作原理
安装OAuth服务器插件
生成要在我们的应用中使用的OAuth访问令牌

让我们从介绍OAuth身份验证方法开始。

引入OAuth身份验证

当您需要登录WordPress管理员时该怎么办？您只需进入登录页面并输入您的登录凭据，对吗？很简单！但是，如果您使用的第三方服务需要访问您的WordPress资源（帖子，页面，媒体或其他任何内容），该怎么办？您是否只是将登录凭据移交给该服务，而知道一旦该服务的完整性受到损害，登录凭据可能会被人误用？答案可能是“否”。

在传统的身份验证模型中，有两个角色：

客户端：可以是用户，应用程序或服务
资源提供者：受保护资源所在的服务器

如果客户端要访问受保护的资源，则可以通过向服务器提供适当的凭据来对他（她）进行身份验证，并被授予访问权限。

当第三方服务需要访问服务器上这些受保护的资源时，就会出现问题。该服务不能（也不应该被）给予用户凭据访问资源。向第三方提供凭据意味着放弃对位于服务器上资源的完全控制。

这就是拯救OAuth身份验证方法的地方。它在身份验证过程中引入了新角色，它是资源所有者 。现在，身份验证过程中具有三个角色：

客户端：不是用户本身，而是代表用户操作并访问受保护资源的第三方应用程序或服务
服务器：受保护资源所在的服务器
资源所有者：用户本身

以上三个角色共同构成了所谓的三足式OAuth身份验证。支路的数量定义了身份验证过程中涉及的角色。当资源所有者也是客户端时，该流程称为两足身份验证。

根据Webopedia ：

OAuth是一种开放式授权标准，用于提供对服务器资源的安全客户端应用程序访问。 OAuth授权框架使第三方应用程序可以代表资源所有者或通过允许第三方应用程序代表自己获得对HTTP服务的有限访问权限。

OAuth使服务器所有者无需共享凭据即可授权对服务器资源的访问。这意味着用户可以授予从一台服务器到另一台服务器资源的私有资源访问权限，而无需共享其身份。

因此，在OAuth身份验证流程中，用户不需要公开凭据，而是可以授权客户端代表客户端执行操作，从而决定客户端可以访问哪些资源。换句话说，在不提供登录凭据的情况下，用户还可以决定授予客户端的访问范围。

这不仅使网站，而且使桌面和移动应用程序都能获得对服务器资源的有限访问权限。

就WordPress而言，OAuth通知资源提供者（WordPress安装）资源所有者（WordPress用户）已授予访问第三方应用程序以访问其资源的权限。这些资源可以是帖子，页面，分类法和媒体等任何资源。此权限可以用于有限访问或完全访问，我们将在本教程的后面看到。

OAuth身份验证流程如何工作

用于WordPress的OAuth身份验证API建立在OAuth 1.0a规范的基础上，因此，我们将研究OAuth 1.0a的工作方式。

OAuth通过使用由资源提供者（服务器）发出的令牌凭据来进行工作，该令牌凭据是在资源所有者使用其凭据进行身份验证之后，根据资源所有者的请求而进行的。然后，客户端（第三方应用程序或服务）使用这些与资源所有者关联的令牌来获得对受保护资源的访问权限。

这些令牌凭证的生存期有限，服务器可以应资源所有者的请求将其吊销。

OAuth流程如下：

客户端将签名的请求发送到服务器，以获取请求令牌 ，也称为临时证书 。该请求发送到“ 临时凭证”端点URI，其中包含以下内容：
- oauth_consumer_key ：由服务器提供
- oauth_timestamp
- oauth_nonce
- oauth_signature
- oauth_signature_method
- oath_callback
- oauth_version （可选）
服务器验证请求，如果请求有效，则授予包含以下内容的请求令牌：
- oauth_token
- oauth_token_secret
- oauth_callback_confirmed
然后，客户端将资源所有者（用户）发送到服务器以授权请求。这是通过在资源所有者授权端点URI上添加上一步中获得的oauth_token来构造请求URI来完成的。
资源所有者（用户）通过提供凭据在服务器上进行授权。
如果在oauth_callback中提供了oauth_callback URI，则服务器会将客户端重定向到该URI，并附加以下内容作为查询字符串：
- oauth_token ：在第二步中获得
- oauth_verifier ：用于确保授予访问权限的资源所有者与返回给客户端的资源所有者相同
如果oauth_callback未提供oauth_callback URI，则服务器将显示oauth_verifier的值，以便资源所有者可以手动通知客户端。
收到oauth_verfier ，客户端通过向Token Request端点URI发送请求，向服务器请求令牌凭证。该请求包含以下内容：
- oauth_token ：在第二步中获得
- oauth_verfier ：在上一步中获得
- oauth_consumer_key ：由资源提供者（服务器）提供，然后启动oauth握手
- oauth_signature
- oauth_signature_method
- oauth_nonce
- oauth_version
服务器验证请求并授予以下证书令牌凭证：
- oauth_token
- oauth_token_secret
然后，客户端使用令牌凭证来访问服务器上受保护的资源。

可以通过附加到请求URI的查询字符串来传输上述信息，也可以通过将其包含在Authorization标头中来进行传输，尽管由于更好的安全性而建议使用后者。

这是一个漫长的过程，因此在开发我们自己的客户端以与API进行交互时应予以考虑。客户端的目的是管理所有这些术语，并帮助用户进行身份验证过程。由于我们将使用WP REST API团队提供的软件包，因此上面的细节将被抽象化，并且我们将能够以最少的步骤获得令牌凭证。

在上面的讨论中，我们遇到了三个端点URI，即：

临时凭证请求端点
资源所有者授权端点
令牌凭证请求端点

服务器以各种方式提供这些URI。这些方法之一是在检查API时在服务器响应中公开它们。 WordPress REST API的OAuth身份验证API使用相同的方法，我们将在下一部分中看到。

研究了OAuth的工作原理后，我们的下一步是为WordPress安装并启用OAuth身份验证API。

为WordPress安装OAuth身份验证API

用于WordPress的OAuth身份验证API使服务器可以使用OAuth实施接受经过身份验证的请求。它建立在OAuth 1.0a规范的基础上，并通过附加参数wp_scope进行扩展，该参数将被发送到Temporary Credential Request端点。 wp_scope参数定义了授予客户端的访问范围。您可以在GitHub的官方文档中找到有关它的更多信息。

WP REST API团队可在Github上使用该插件，并且仅支持WordPress的4.4版或更高版本。

让我们通过导航到/wp-content/plugins/目录来克隆插件：

$ git clone https://github.com/WP-API/OAuth1.git

下载完成后，使用WP CLI激活插件：

$ wp plugin activate OAuth1

另外，如果您不想使用WP CLI，也可以通过将浏览器导航到WordPress管理插件部分来激活它。

这是使服务器能够接受OAuth作为授权方法所需的全部。我们需要做的下一件事是向服务器发送一个请求，以检查OAuth API是否准备就绪。

评估OAuth API的可用性

在启动OAuth握手之前，我们应该首先检查服务器上是否启用了API。这是通过将简单的GET请求发送到 /wp-json/端点，然后分析服务器发送的响应。

启动您的HTTP客户端，并向/wp-json/端点发送请求，如下所示：

GET http://your-dev-server/wp-json/

这将返回JSON响应，如下所示：

我们这里的重点是authentication属性值中的oauth1值。该对象定义了以下属性：

request ：临时凭证请求端点
authorize ：资源所有者授权端点
access ：令牌请求端点
version ：使用的OAuth版本

前三个是我们在上一节中学习OAuth机制时遇到的绝对URL。

authentication属性值中定义的oauth1对象表明，我们的WordPress网站已成功启用OAuth API，我们可以开始使用它了。

如果未为站点启用OAuth API，则服务器响应将包含一个空的authorization属性值，如下所示：

现在我们已经安装了OAuth1.0a插件，让我们看看如何为应用程序创建和管理使用者。

创建和管理应用程序

成功安装OAuth1.0插件后，我们可以转到WordPress管理员，然后转到“ 用户”>“应用程序”页面，为我们的应用程序创建和管理使用者。

在此“ 注册的应用程序”页面上，我们可以通过单击“添加新按钮”来注册一个新的应用程序，然后在结果页面上填写以下三个字段：

消费者名称 ： 消费者名称 。此名称将在授权过程中显示给用户，然后在“ 授权应用程序”部分下的用户个人资料页面上显示。
描述：消费者应用程序的可选描述。
回调URL ：回调URL。生成临时凭证时将使用此回调URL，我们将在下一步中看到。

通过单击“ 保存使用者”按钮创建后，该特定使用者的“ 客户端密钥”和“ 客户端机密”参数将显示在页面底部。

这些客户端密钥和客户端密钥参数分别充当oauth_consumer_key和oauth_consumer_secret参数。

可以通过单击页面底部的“ 重新生成密钥”按钮来创建新的客户端密钥 。

OAuth插件还提供了通过WP CLI插件在控制台中创建使用者的功能。因此，也可以通过终端中的以下命令来创建新使用者：

wp oauth1 add --name=<consumer_name> --description=<consumer_description>

然后，新创建的使用者将显示在“ 注册的应用程序”页面上，您可以在其中进行编辑。

在注册我们的应用程序之后，我们现在准备在以下各节中开始OAuth授权过程。

安装客户端CLI软件包

请注意，在编写本教程时，OAuth1.0a插件不再支持客户端CLI软件包。 客户端CLI软件包可能会在不久的将来进行更新，以与最新版本的OAuth插件一起使用，但是目前，请参考下一部分有关使用HTTP客户端生成OAuth凭据的部分。

WP REST API团队的Client-CLI包允许使用WP-CLI和WP REST API与WordPress站点进行远程交互。源码可以在GitHub上找到。

要使用此软件包，您需要在WordPress安装所在的服务器上安装并激活以下软件包：

WP CLI
WP REST API插件
OAuth 1.0a服务器插件

在要从其生成请求的机器（或客户端）上，必须安装以下组件：

WP CLI
作曲家
客户端CLI存储库本身

您可以找到将上述软件包安装在各自站点上的说明。

话虽如此，让我们通过运行以下命令在客户端上克隆存储库：

$ git clone https://github.com/WP-API/client-cli

现在，导航到克隆目录并使用Composer安装软件包依赖项：

$ cd client-cli
$ composer install

如果一切顺利，命令行应显示类似以下内容：

现在，我们已经安装了该软件包，我们准备生成令牌凭证并使用OAuth与WordPress REST API进行远程交互。

使用客户端CLI生成OAuth凭证

要开始OAuth授权过程，我们首先从服务器获取以下信息：

oauth_consumer_key
oauth_consumer_secret

这可以通过将终端定向到服务器上的WordPress安装目录并运行以下WP CLI命令来生成：

$ wp oauth1 add

这将生成如下输出：

此处获得的Key和Secret分别是oauth_consumer_key和oauth_consumer_secret 。

现在，我们需要将客户端链接到我们的WordPress网站。在客户端上，导航到上一部分中克隆的client-cli目录，然后运行以下命令：

$ wp --require=client.php api oauth1 connect http://your-dev-server/ --key=<your key here> --secret=<your secret here>

替换URL，以及上面命令中在上一步中获得的密钥和机密。输出应如下所示：

$ wp --require=client.php api oauth1 connect http://localserver/wordpress-api/ --key=kXZMTt3O5hBZ --secret=ueDNeCfgNuyNyxkiU3qHGgWZWmGsg5lZwmMyhyjANsyYgz3Q
Open in your browser: http://localserver/wordpress-api/oauth1/authorize?oauth_token=wFxrd8OzcIL6lSRkLmmvViIe
Enter the verification code:

导航到服务器给定的URL，并通过单击“ 授权”按钮进行身份验证：

在下一个屏幕上将向您显示验证令牌（或oauth_verifier ）：

复制验证程序并将其粘贴到终端中。您将获得一个Key和一个Secret ，它们基本上分别是您的oauth_token和oauth_token_secret ：

您可以在HTTP客户端或支持使用OAuth API发送经过身份验证的请求的任何其他应用程序中使用这些令牌凭据。

使用HTTP客户端生成OAuth凭证

由于OAuth 1.0a服务器插件遵循三足流程，因此生成OAuth凭据涉及三个步骤：

获得临时证书
用户授权
代币交换

让我们开始使用HTTP客户端（即Postman）实现上述每个步骤。

1.取得临时证书

要获取临时凭证，我们将POST请求发送到/oauth1/request端点。应该自动发现此临时凭据请求端点，因为服务器可能会用其自己的路由替换此路由。在上一部分中，我们在评估OAuth API的可用性时研究了自动发现功能。

POST请求应包括在为应用程序注册使用者时获取的oauth_consumer_key和oauth_consumer_secret参数。该请求可能还包含oauth_callback参数，并且此回调URL应与注册应用程序时提供的回调URL的方案，主机，端口和路径匹配。

除了oauth_consumer_key和oauth_consumer_secret参数外，请求还应包括oauth_signature和oauth_signature_method参数。使用Postman时，会自动生成oauth_signature ，我们只需要指定oauth_signature_method参数即可。当前，OAuth服务器插件仅支持HMAC-SHA1签名方法。

可以通过以下三种方式之一传递上述参数：

通过Authorization标头
通过URL中的（ GET ）查询参数
通过（ POST ）请求正文参数。在这种情况下，内容类型应为application/x-www-form-urlencoded 。

您可以使用上述任何一种方法将这些参数发送到服务器。

现在，我们通过启动Postman并将POST请求发送到临时凭据请求端点来开始该过程。但是在此之前，请复制新注册的应用程序提供的Consumer Key和Consumer Secret参数，因为在此步骤中将需要它们。

配置邮递员将POST请求发送到您的临时令牌凭证端点。然后在“ 授权”标签中，从下拉菜单中选择OAuth 1.0选项。使用消费者提供的值填写“ 消费者密钥”和“ 消费者秘密”字段。确保检查“ 签名方法”选项是否设置为HMAC-SHA1 。

除了这些，我们不需要输入任何其他值。单击更新请求按钮，最后通过单击发送按钮发送请求。

如果没有错误，服务器将返回200-OK状态代码以及内容类型为 application/x-www-form-urlencoded application/x-www-form-urlencoded 。该请求正文类似于以下文本字符串：

oauth_token=tyNCKaL3WAJXib5SI6jCnr4P&oauth_token_secret=1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF&oauth_callback_confirmed=true

该响应主体包含用于三足流下一步的三个参数。这三个参数是：

oauth_token ：授权步骤的临时OAuth令牌。
oauth_token_secret ：与oauth_token一起使用的临时机密。
oauth_callback_confirmed ：无论您是否在第一步中提供oauth_callback参数，始终返回此参数。

准备好这些临时凭证后，我们就可以进行用户授权步骤了。

2.用户授权

对于用户授权步骤，我们在浏览器中打开资源所有者授权端点，并将在上一步中获得的oauth_token和oauth_token_secret传递为查询参数，如下所示：

http://your-dev-server/oauth1/authorize?oauth_token=<token_here>&oauth_token_secret=<secret_here>

浏览器将要求您登录WordPress（如果尚未登录），然后要求您授权该应用程序：

这里的Awesome Application是注册应用程序的名称。

单击“ 授权”按钮授权应用程序，然后在下一个屏幕上将显示验证令牌：

该令牌在下一步中充当oauth_verifier令牌。

用户授权客户端后，该应用程序将显示在“ 用户”>“您的个人资料”页面上的“ 授权应用程序”部分下。

3.代币交换

三足流中的下一步也是最后一步是令牌交换。在此步骤中，将第一步中获得的临时令牌交换为客户端可以使用的长期令牌。

要启动令牌交换过程，请切换回Postman并将其配置为将POST请求发送到令牌请求端点。

通过在“ 授权”选项卡中再次使用OAuth 1.0选项，使用消费者提供的值填写“ 消费者密钥”和“ 消费者秘密 ”字段。对于“ 令牌”和“ 令牌机密”字段，请使用在第一步中获得的oauth_token和oauth_token_secret参数（临时凭据）的值。

因为我们还可以将URL中的参数作为查询参数传递，所以将oauth_verifier参数附加到URL，如下所示：

http://your-dev-server/oauth1/access?oauth_verifier=<oauth_verifier_value>

保留所有参数后，单击“ 发送”按钮发送请求。如果一切顺利，服务器将返回200-OK状态代码以及包含oauth_token和oauth_token_secret参数的响应正文。

oauth_token=<oauth_token_value>&oauth_token_secret=<oauth_secret_value>

此时，第一步中获取的临时令牌将被丢弃，无法再使用。

这些新的oauth_token和oauth_token_secret参数是您的OAuth凭据，您可以在客户端中使用它们来生成经过身份验证的请求。

发送测试验证请求

现在，我们已经获得了令牌凭证，我们可以使用Postman向服务器发送测试请求，以查看它们是否起作用（当然可以！）。

我们将向服务器发送DELETE请求，以删除ID为50的帖子。根据您的情况，此ID可以不同。

开始之前，您需要具备以下条件：

oauth_consumer_key ：在第一步中获得
oauth_consumer_secret ：在第一步中获得
oauth_token ：在最后一步中获得
oauth_token_secret ：在最后一步中获得

从邮递员的“ 授权”选项卡下的下拉列表中选择OAuth 1.0 ，然后如上所述填充前四个字段。以下是它的外观：

填写字段后，单击更新请求按钮。选中“ 将参数添加到标题”选项会将参数发送到请求的标题中，而不是将其附加到查询字符串中。

发送请求，您应该从服务器获得200-OK状态代码，表明帖子已成功删除。

结论

在这个冗长的教程中，我们概述了OAuth身份验证方法及其如何提供对第三方应用程序和服务的安全委派访问。我们还在服务器上为WordPress设置了OAuth身份验证API，并将其与HTTP客户端结合使用以获取令牌凭证。

在本系列的下一部分中，我们将研究通过WP REST API检索内容。所以请继续关注...

翻译自: https://code.tutsplus.com/tutorials/wp-rest-api-setting-up-and-using-oauth-10a-authentication--cms-24797