如何使用 WP REST API 設置和使用 OAuth 身份驗證
已發表: 2016-11-30
對於 WordPress REST API,OAuth 是最常見的身份驗證處理提供程序。
OAuth 身份驗證到位後,用戶首先通過網站上使用的 WordPress 登錄表單登錄。 但是,此登錄還授權客戶端代表他們處理請求,並且所有後續請求都通過 OAuth 令牌進行驗證。 這些令牌還用於管理所有 API 訪問請求。 可以隨時撤銷此訪問權限。
或許,OAuth 身份驗證過程的最重要用途是處理 REST API 請求而不暴露用戶憑據的安全過程。 這對於經常交換憑據的生產服務器尤為重要。 在這種情況下,OAuth 身份驗證用於提供處理頻繁登錄憑據請求的安全程序。
- 傳統與 OAuth 身份驗證
- OAuth 身份驗證工作流
- 安裝 OAuth 認證
- 評估 OAuth API 的可用性
- 創建和管理應用程序
- 用於生成 OAuth 憑證的客戶端 CLI
- 用於生成 OAuth 憑證的 HTTP 客戶端
- 獲取臨時憑證
- 用戶授權
- 代幣交換
- 發送測試認證請求
傳統與 OAuth 身份驗證
為了理解 OAuth 身份驗證的意義,了解傳統和 OAuth 身份驗證模型很重要。
在傳統的認證模型中,有兩個關鍵實體; 客戶端和資源/服務提供商。 客戶端可以是 Web 應用程序、服務或用戶,而資源/服務提供者在訪問受限的環境中擁有所需的資源或服務。
當客戶端需要特定資源時,它會通過提供適當的憑據向資源提供者進行身份驗證。 雖然這是一個簡單的過程,但也存在巨大的安全漏洞風險。
相比之下,OAuth 認證模型稍微複雜一些,包含三個實體; 代表用戶操作的客戶端、需要訪問資源的用戶以及維護資源的服務器。
由於存在三個實體,因此該過程稱為三足認證。 但是,在客戶端和用戶是相同實體的情況下,身份驗證過程變為兩條腿的身份驗證。
OAuth 身份驗證工作流

- 客戶端請求用戶授權訪問服務器。
- 如果用戶同意請求,客戶將獲得進一步處理的權利。
- 客戶端將其身份和來自客戶端的授權提交給授權服務器(API) 並請求令牌。
- 在身份和授權成功驗證的情況下,授權服務器(API) 向客戶端發出訪問令牌。 至此,認證完成。
- 接下來,客戶端接近服務器以請求特定資源。 此時, Client還將訪問令牌發送給
- 如果訪問令牌經過驗證,服務器將授予對所請求資源的訪問權限。
客戶端發起對請求令牌的簽名請求。 此請求也稱為臨時憑證。 請求被發送到相關的端點 URI。 此請求包含幾個重要參數:
- oauth_consumer_key :此鍵標識發起請求的應用程序。
- oauth_timestamp :服務器使用這個時間戳來優化 nonces 存儲。
- oauth_nonce :這是為每個單獨的請求生成的唯一應用程序令牌。
- oauth_signature :API 請求的這一重要部分是請求的所有組件和一些 OAuth 值的哈希值。
- oauth_signature_method :OAuth 插件提供單一簽名方法:HMAC-SHA1。
- oath_callback : 用戶授權後重定向的 URL。 驗證請求並發出具有以下參數的請求令牌。
- oauth_token :這是從授權服務器的響應中剝離的應用程序令牌。 然後將此令牌發送到 API 服務器。
- oauth_token_secret :這類似於用戶密碼。 該請求然後由客戶端授權。 為此,會創建一個請求 URI,並將oauth_token添加到服務器授權端點 URI。 用戶通過提供適當的憑據來授權發送此請求。
如果在第一步中 oauth_callback URI 可用,服務器將重定向到 URI,並將以下參數添加到查詢字符串中:
- oauth_token :已經有令牌。
- oauth_verifier :向客戶端驗證資源所有者的身份。
如果第一步未提供oauth_callback URI,則服務器發送oauth_verifier的值,以便資源所有者可以手動通知客戶端。
收到oauth_verfier 後,客戶端向服務器請求令牌憑據。 這採用對令牌請求端點 URI 的請求的形式。 此請求包含以下參數:
- oauth_token
- oauth_verfier
- oauth_consumer_key
- oauth_signature
- oauth_signature_method
- oauth_nonce
- oauth_version
安裝 OAuth 認證
在 WordPress 的上下文中,OAuth 認證是通過安裝 WordPress 的 OAuth 認證 API 來實現的。 這是基於 OAuth 1.0a 規範,實際上通過附加參數wp_scope擴展了這些規範。 此參數被發送到臨時憑證請求端點。
該插件可從 WP REST API 團隊在 Github 上獲得。 目前,支持 4.4 及更高版本。
我將通過移動到/wp-content/plugins/目錄來開始克隆插件的過程:
git 克隆 https://github.com/WP-API/OAuth1.git

下載完成後,通過 WordPress CLI 激活插件:
wp 插件激活 OAuth1
如果您不想使用 WordPress CLI,您可以轉到 WordPress Admin >> Plugins 並從菜單中激活插件。 或者,如果您不想使用 WP CLI,也可以通過將瀏覽器導航到 WordPress 管理插件部分來激活它。
評估 OAuth API 的可用性
在我發起 OAuth 握手之前,我會首先檢查服務器上是否啟用了 API。 這是通過發送一個簡單的GET請求到 /wp-json/端點,然後分析服務器發送的響應。
獲取 http://Server-Dev/wp-json/
這將返回一個 JSON 響應,如下所示:

我在這裡的重點是身份驗證屬性值中的oauth1值。 該對象定義了以下屬性:
- request :臨時憑證請求端點
- 授權:資源所有者授權端點
- 訪問:令牌請求端點
- version : 使用的 OAuth 版本
如果未為站點啟用 OAuth API,則服務器響應將包含一個空的授權屬性值。

創建和管理應用程序
第一步是確保 OAuth1.0 插件已正確安裝和激活。
接下來,我可以通過轉到 WordPress Admin >> Users >> Applications 創建和管理應用程序。

在這個已註冊的應用程序頁面上,我將通過單擊添加新按鈕然後填寫以下三個字段來註冊一個新應用程序:
- 客戶端名稱:在授權應用程序部分和授權過程中出現的客戶端名稱。
- 描述:客戶端的可選描述。
- 回調 URL :生成臨時憑證時使用回調 URL。
單擊“保存客戶端”按鈕創建後,“客戶端密鑰”和“客戶端密鑰”參數將顯示在此特定客戶端的頁面底部。


我現在將通過運行以下命令克隆客戶端上的存儲庫:
git 克隆 https://github.com/WP-API/client-cli

現在導航到克隆目錄並使用 Composer 安裝包依賴項:
cd 客戶端-cli 作曲家安裝
如果一切順利,命令行應顯示類似於以下內容:

用於生成 OAuth 憑證的客戶端 CLI
要開始 OAuth 授權過程,我將首先從服務器獲取以下參數:
- oauth_consumer_key
- oauth_consumer_secret
這將通過終端生成並運行以下 WordPress CLI 命令:
wp oauth1 添加
Key和Secret是oauth_consumer_key 和oauth_consumer_secret分別。
現在我需要將客戶端鏈接到 WordPress 站點。 在客戶端上,導航到client-cli目錄(之前克隆)並運行以下命令:
wp --require=client.php api oauth1 connect http://Server-Dev/ --key=<你的密鑰在這裡> --secret=<你的秘密在這裡>
替換上述命令中的 URL、密鑰和秘密。 輸出應如下所示:
wp --require=client.php api oauth1 連接 http://your-server/wordpress-api/ --key=<your key> --secret=<your secret code> 在瀏覽器中打開:http://your-server/wordpress-api/oauth1/authorize?oauth_token=<your-token> 輸入驗證碼:
導航到服務器提供的 URL 並通過單擊授權按鈕進行身份驗證:

您將在下一個屏幕上看到驗證令牌(或 oauth_verifier):

複製驗證器並將其粘貼到終端中。 您將獲得一個Key和一個Secret ,它們基本上分別是oauth_token和oauth_token_secret :
用於生成 OAuth 憑證的 HTTP 客戶端
由於 OAuth 1.0a 服務器插件遵循標準的三足流程,因此生成 OAuth 憑據涉及以下步驟:
- 獲取臨時憑證
- 用戶授權
- 代幣交換
獲取臨時憑證
我將向 /oauth1/request 端點發送POST請求以獲取臨時憑證。 請注意,此端點應該是可自動發現的,因為服務器可能會自行替換路由。
POST請求應包括在為應用程序註冊使用者時獲取的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 簽名方法。
我現在將配置 Postman 以向臨時令牌憑據端點發送POST請求。 接下來,在授權選項卡中,從下拉列表中選擇OAuth 1.0選項。 使用消費者提供的值填寫消費者密鑰和消費者秘密字段。 最後,檢查Signature Method選項是否設置為HMAC-SHA1 。
用戶授權
對於用戶授權步驟,我將在瀏覽器中打開資源所有者授權端點並傳遞oauth_token 和上一步中獲得的oauth_token_secret作為查詢參數:
http://server-dev/oauth1/authorize?oauth_token=<token_here>&oauth_token_secret=<secret_here>

單擊授權按鈕授權應用程序。 下一個屏幕將顯示驗證令牌。 此令牌現在將在下一步中充當oauth_verifier令牌。
用戶授權客戶端后,應用程序將顯示在用戶 > 您的個人資料頁面上的授權應用程序部分下。
代幣交換
通過在Authorization選項卡中再次使用OAuth 1.0選項,使用消費者提供的值填寫Consumer Key和Consumer Secret的字段。 在Token和Token Secret字段中,插入值oauth_token和oauth_token_secret參數(臨時憑證)。
由於我還可以將 URL 中的參數作為查詢參數傳遞,因此將oauth_verifier參數附加到 URL 中,如下所示:
http://server-dev/oauth1/access?oauth_verifier=<oauth_verifier_value>
準備好所有參數後,單擊“發送”按鈕發送請求。 如果一切順利,服務器將返回200 – OK狀態代碼以及包含oauth_token和 o auth_token_secret參數的響應主體。
oauth_token=<oauth_token_value>&oauth_token_secret=<oauth_secret_value>
此時,之前獲得的臨時令牌被丟棄,不能再使用。
新的oauth_token和oauth_token_secret參數是您可以在客戶端中用於生成經過身份驗證的請求的 OAuth 憑據。
發送測試認證請求
現在我有了令牌憑據,我將使用 Postman 向服務器發送測試請求。 該請求將需要以下參數:
在開始之前,您需要具備以下條件:
- oauth_consumer_key
- oauth_consumer_secret
- oauth_token
- oauth_token_secret
從 Postman授權選項卡下的下拉列表中選擇OAuth 1.0 。

填寫完所有字段後,單擊“更新請求”按鈕。 選中Add params to header選項以在請求的標頭中發送參數,而不是附加到查詢字符串。
如果請求成功,服務器將發送200 – OK狀態代碼。
包起來!
在本教程中,我討論瞭如何在服務器上為 WordPress 設置 OAuth 身份驗證 API,以及如何使用 HTTP 客戶端獲取令牌憑據。 如果您發現代碼中的問題或想添加到討論中,請在下面發表評論。
