為Web應用程序使用自己的API - 使用OAuth2進行身份驗證過程

Question

概觀

我目前正在為圖像共享應用程序創建一個API，該應用程序將在網絡上運行，並在將來的某個時間在移動設備上運行。 我理解API構建的邏輯部分，但我仍然在努力滿足自己對身份驗證部分的要求。

因此，我的API必須是全世界都可訪問的：具有訪客訪問權限（例如，未登錄的人可以上載）以及注冊用戶。 因此，當注冊用戶上傳時，我顯然希望將用戶信息與請求一起發送，並通過我的數據庫中的外鍵將該用戶信息附加到上載的圖像。

---

通過OAuth2進行身份驗證 - 實施

我已經明白OAuth2是API身份驗證的方法，所以我要實現這一點，但我真的很想知道如何處理我的情況。 我想過使用client credentials授權並為我的Web應用程序生成一組憑據，並讓它向API發送請求，並使用其client secret獲取訪問令牌並讓用戶執行操作。 用戶注冊過程本身將使用此授權進行處理。

但是當用戶注冊並登錄時呢？ 我現在如何處理身份驗證？ 這是否需要另一筆補助金來接管？ 我在考慮在用戶登錄期間進行一些授權過程，以生成新的訪問令牌。 這種方法有誤嗎？

---

我需要幫助的是什么

我需要你的輸入如何正確處理我的情況下的身份驗證流程。 這種雙向身份驗證過程可能不是我需要的，但它是我理解它的方式。 我非常感謝您的支持。

Answer 1

你的方法似乎可行。

Oauth2有4個主要部分：

• 資源服務器（您的API）
• 資源所有者（在資源服務器上有數據的最終用戶）
• 授權服務器（獲取授權和簽發令牌）
• 客戶（您的網絡應用 - 以及未來的應用）

請記住使用客戶端憑據授予，您發出的令牌可能沒有任何用戶上下文。 因此，如果您的API端點依賴於令牌中包含的用戶標識符/資源所有者，那么您將需要為此類型的令牌編寫代碼。

如果您確實需要令牌為您的API擁有一些資源所有者上下文，並且您的Web應用程序恰好是您的身份提供者，那么您可以使用資源所有者密碼授予，它將在上下文中為您提供令牌和刷新令牌。資源所有者/用戶。

授權代碼授權很好，前提是您的API消費者是Web應用程序（即在服務器上運行）。 如果您計划允許移動/本機應用程序使用您的API，那么您應該考慮在授權服務器中允許隱式授權。

如果您的API沒有最終用戶，並且每個客戶端具有不同的API訪問權限，具體取決於它是什么應用程序，那么您可以使用客戶端憑據授予並使用范圍來限制API訪問。

編輯

因此，我的API必須可供訪客訪問（例如，未登錄的人員可以上傳）和注冊用戶訪問。 因此，當注冊用戶上傳時，我顯然希望將用戶與請求一起發送並將該用戶附加到上傳的圖像

為實現此目的，您的API上傳端點可以處理Oauth2.0承載令牌，但不依賴於它們。 例如，任何人都可以使用端點，並且在標頭中提供訪問令牌的人將使其上傳與API從令牌中獲取的用戶上下文相關聯。 然后，如果需要，您可以使其他端點依賴於令牌。

根據評論編輯

注冊過程本身會使用客戶端憑據授權，對嗎？

我不認為注冊過程本身應該是Oauth保護的資源。 理想情況下，注冊應由您的身份提供商處理（例如谷歌，臉書或您自己的用戶會員數據庫）。 關於Oauth2.0的另一個優點是它不再需要API來執行用戶管理工作。

Answer 2

您真的不需要oauth來驗證您自己的API。

如果您希望其他應用程序訪問您的API，OAuth2非常有用。

讓我解釋一下OAuth2的工作原理：

• 客戶端（應用程序）想要使用您的API，因此您可以為其提供客戶端憑據（client_token和client_secret）。 並在數據庫中設置一組客戶端可以使用的重定向位置。
• 客戶需要用戶授權才能代表用戶使用您的API。 因此，客戶端將用戶發送到您站點上的URL（使用client_token，客戶端需要的范圍[您定義不同范圍的含義]，重定向uri和response_type [oauth2定義不同的response_type但讓我們關注'代碼' “]）
• 用戶登錄您的站點並接受代表用戶訪問您的API的客戶端。 當用戶接受此權限時，您將生成一個授權（授權包含用戶的信息，請求的憑據[范圍]以及可以“聲明”授予訪問權限的客戶端）。
• 然后，用戶被重定向到客戶端請求的redirect_uri（當客戶端將用戶發送到您的auth站點時），並且在URL參數中，您將包含授權代碼（它只是一個id）。
• 在此階段，客戶端將向您的API發出請求，提供授權代碼，他自己的client_token，他的client_secret和grant_type（authorization_code），他將獲得以下響應：authorization_token，refresh_token，token_type（對於這種情況） ，Bearer），expires_in（以秒為單位的到期時間）和范圍。
• 完成所有這些后，客戶端將能夠代表用戶使用access_token進行API請求，直到令牌過期。 一旦令牌過期，客戶端將不得不使用refresh_token（而不是授權碼）請求新的access_token。

Answer 3

iandayman的答案有很多很好的信息，但我認為更狹隘的更具體的答案可能會對你有所幫助。

因此對於初學者來說， 客戶端憑據授權不適合您 。 如果我們查看OAuth2規范 ，則客戶端憑據授權適用於

當授權范圍僅限於客戶端控制下的受保護資源時...當客戶端代表自己行事時

出於兩個原因，這不適合你。
首先，您的客戶無法控制受保護的資源。 您訪問的所有資源都是不受保護的（未登錄人員上傳）或受最終用戶控制。 此外，您無法在瀏覽器中保留機密（例如客戶端機密）; 您的應用程序的任何用戶都可以使用瀏覽器的開發人員工具來查看和破壞秘密。
其次，正如我所提到的，客戶永遠不會代表自己行事。 它始終代表可能登錄或未登錄的用戶。

您希望資源所有者密碼憑據授予 。
當用戶未登錄時（就像您上傳的那樣），您只是沒有授權。 用戶登錄時，將其憑據發送到授權服務器。 如果密碼與用戶名匹配，則授權服務器生成令牌並持久保存從該令牌到用戶的映射並返回令牌。 然后，每次客戶端向登錄用戶發出另一個請求時，都會將該令牌放入Authorization標頭中。 在后端，你會說“如果授權標題中有一個令牌，找出它對應的用戶，並將它們與此上傳相關聯（或檢查它們是否允許上傳）”。

用戶注冊如何工作？ 很簡單，你發布一些像這樣的用戶對象

name: jim beam
username: jimb
password: correct horse battery staple

到您的用戶創建端點（ POST /users或其他東西）。 生成salt並哈希密碼，然后將用戶的信息與salt和hash一起存儲在數據庫中。 此端點無權授權。

希望這更像是你在尋找的東西。