OAuth 2.0 簡介

查看 Apigee Edge 說明文件。
前往 Apigee X說明文件。 資訊

OAuth 首頁： 請參閱 OAuth 首頁，概略瞭解我們提供的 OAuth 指南 提供

本主題提供 Apigee Edge 的 OAuth 2.0 基本總覽。

什麼是 OAuth 2.0？

目前提供 OAuth 2.0 相關書籍、網誌和網站相當多。我們強烈建議您 請先詳閱 IETF OAuth 2.0 規格。以下是 OAuth 2.0 IETF 規格的 OAuth 2.0 定義 ：

「OAuth 2.0 授權架構可讓第三方 取得 HTTP 服務的有限存取權，您可以 自動化調度管理資源擁有者與 HTTP 服務之間的核准互動，或是 允許第三方應用程式自行取得存取權。」

您需要特別注意的是，OAuth 2.0 可讓應用程式有限存取使用者受保護的資源 (例如銀行帳戶或任何其他資源) 使用者可能想從應用程式存取的機密資訊)，而無需使用者 將登入憑證提供給應用程式。

OAuth 2.0 流程

以下是 OAuth 2.0 安全性架構的一般流程。我們會詳細說明這個流程 ，首先從圖表著手，以進一步說明 OAuth 2.0 的運作方式。 如果您不熟悉本圖中使用的術語，請閱讀本節的內容 簡介

不可不知的條款

  • 用戶端：也稱為「應用程式」。可能是在行動裝置上執行的應用程式 或是使用傳統網頁應用程式應用程式為了受保護，向資源伺服器發出要求 管理資源資源擁有者必須授予應用程式權限 存取受保護的資源
  • 資源擁有者：也稱為「使用者」。這通常是指 能夠授予受保護資源存取權的人員 (或其他實體)。適用對象 舉例來說，如果應用程式需要使用您其中一個社群媒體網站的資料，您 資源擁有者：只有這個人可以將資料存取權授予應用程式。
  • 資源伺服器：您可以將資源伺服器視為 Facebook、Google 或 Twitter；或內部網路上的人資服務；或在 Google Cloud 上 B2B 多網路。每當需要驗證 OAuth 權杖時，Apigee Edge 是資源伺服器 能夠處理 API 要求資源伺服器需要某種授權才能提供服務 以便取得受保護的資源
  • 授權伺服器：已導入授權伺服器 以符合 OAuth 2.0 規格 驗證授權授予並核發存取權 權杖 ，讓應用程式存取資源伺服器上的使用者資料。個人中心 可以設定「憑證端點」會由 Edge 負責處理 授權伺服器執行。
  • 授權：授予應用程式擷取存取權 管理權杖OAuth 2.0 定義了四種特定的「授權類型」。請參閱「OAuth 2.0 授權類型是什麼」。
  • 存取權杖：做為憑證的一長串字元 存取受保護的資源另請參閱「什麼是存取權？ 權杖？」。
  • 受保護的資源：資源擁有者擁有的資料。舉例來說， 使用者的聯絡人清單、帳戶資訊或其他機密資料。

Apigee Edge 的適用範圍

您可以使用 OAuth 2.0，保護透過 Apigee Edge 所有經 Proxy 處理的 API。Edge 包含 授權伺服器實作，因此會產生並驗證存取權杖。 開發人員首先會使用 Apigee Edge 註冊應用程式。 已註冊的應用程式可以透過四種授權 type 互動。

Apigee 提供多重面向的 OAuthV2 政策， 取得各種授權類型的詳細資訊，方便您在 Apigee Edge 上輕鬆設定 OAuth。適用對象 舉例來說，您可以設定政策來接收存取權杖要求。 必要憑證，如果憑證有效，則傳回存取權杖。

請注意，您的安全 API Proxy 呼叫應位於防火牆保護的任何資源伺服器 (也就是說，除了 API Proxy 之外，也無法透過其他方式存取資源)。 安全無虞的 API)。

什麼是 OAuth 2.0 授權類型？

請將授權類型想成是應用程式取得存取權時可採用的不同路徑或互動方式 產生下一個符記每種授權類型都適用於一或多個用途，您必須選取 按照自己的需求使用。一般來說，每種授權類型都有優點和 缺點一 重要的考量因素之一以便存取您資料的應用程式。 一般來說，相較於在 企業。

Apigee Edge 支援四種主要 OAuth 2.0 授權類型：

  • 授權碼 -- 我們認為最安全的授權類型。之前 授權伺服器發出存取權杖，應用程式必須先接收授權碼 從資源伺服器載入資料每次應用程式開啟瀏覽器並前往 資源伺服器的登入頁面，並邀請您登入實際的帳戶 (例如 Facebook 或 Twitter)。

如果成功登入，應用程式就會收到授權 程式碼，使用該組程式碼與授權伺服器協商存取權杖。一般而言，這個 授權類型用於應用程式位於伺服器 (而非用戶端) 時。這個授權類型為 用戶端應用程式絕對不會處理或查看使用者名稱， 資源伺服器的密碼 (例如應用程式從未檢視或處理 Twitter 憑證)。這種授權類型流程又稱為「三足式」OAuth。

  • 隱含 -- 考慮用的簡化版授權碼。 一般來說，當應用程式位於用戶端時，就會使用這個授權類型。例如，應用程式的 程式碼是使用 JavaScript 或其他指令碼語言在瀏覽器中執行 (而非 和在另一個網路伺服器上執行)。在授權類型流程中 伺服器會在驗證使用者後直接傳回存取權杖，而不是核發 授權碼在某些情況下，隱含授權可提升應用程式回應速度 這項優勢必須衡量潛在的安全性影響，如 IETF 規格。
  • 資源擁有者密碼憑證 -- 在這個流程中，系統會核發用戶端 在使用者的使用者名稱/密碼經過授權伺服器驗證時，產生存取權杖。 對於高度信任的應用程式，建議採用此流程。相較於這個流程 基本驗證，是使用者只留下使用者名稱/密碼一次。之後 開啟，並使用存取權杖。
  • 用戶端憑證：建議在用戶端憑證 應用程式就會自行運作。也就是說，用戶端也會是資源擁有者。這個授予項目 類型通常是在應用程式需要存取後端資料儲存服務時使用， 範例。應用程式需要使用服務才能執行作業，而服務在其他情況下是不透明的 供使用者參考使用此授權類型時，應用程式可透過 用戶端 ID 和用戶端密鑰傳送至授權伺服器。您不需要採取其他步驟。 Edge 提供立即可用的用戶端憑證解決方案，可以輕鬆導入 並存取 API Proxy

什麼是存取權 符記？

存取權杖是一長串字元，可做為存取憑證 受保護的資源資源權杖 (又稱為不記名權杖) 會在授權中傳送 標題，如下所示：

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

資源伺服器理解存取權杖「代表」這類憑證 使用者名稱和密碼此外，存取符記可能會設有限制，因此 舉例來說，應用程式可以讀取資源伺服器中的資料，但無法寫入或刪除資料。請注意， 例如應用程式遭到入侵。在這種情況下，您需要 取得新的存取權杖以繼續使用應用程式；但您不需要變更 受保護資源伺服器上的使用者名稱或密碼 (例如，Facebook 或 Twitter)。

基於安全考量，存取權杖通常都有有效期限。有些授權類型 授權伺服器發出更新權杖，讓應用程式擷取新的存取權杖 就會失效如要進一步瞭解存取和更新權杖，請參閱 IETF OAuth 2.0 規格。

透過以下應用程式限制存取權： 範圍

透過設定範圍機制，OAuth 2.0 可以授權應用程式存取受保護的部分 再複習一下，機構節點 是所有 Google Cloud Platform 資源的根節點舉例來說，某個應用程式只能存取特定資源，或許可以更新 或僅授予唯讀存取權。下稱為「三腳式」OAuth 流程 使用者通常會透過同意聲明頁面 (例如網頁) 指定存取層級 則使用者可透過其他機制的核取方塊選取範圍)。

註冊應用程式

所有用戶端 (應用程式) 都必須向其提供的 OAuth 2.0 授權伺服器註冊 要求存取權杖註冊應用程式時，您會收到一組金鑰。第一個是 公開金鑰稱為用戶端 ID，另一個則是名為「用戶端」的密鑰 密鑰。如果沒有這些金鑰，應用程式就無法發出授權碼或存取權杖要求 授權伺服器。請注意，IETF OAuth 規格呼叫這些金鑰用戶端時 ID 和用戶端密鑰，Apigee Edge UI 將其稱為用戶端 ID 和用戶端密鑰。這些 。

OAuth 2.0 使用案例摘要

您選擇執行的 OAuth 2.0 授權類型流程會因您的用途而異。 某些授權類型的安全性較高。您選擇的授權類型取決於 用戶端應用程式的可信度，並且需要審慎考量， 資料表：

用途 值得信賴 建議的 OAuth 2.0 授權類型 說明
B2B (額外網路)、內部網路、其他

高度可信任的應用程式，是由內部開發人員或值得信賴的開發人員編寫 您與 API 供應商之間的業務關係

需要代表自己存取資源的應用程式，
  • 用戶端憑證
  • 一般來說，應用程式也會是資源擁有者
  • 必須提供用戶端 ID 和用戶端密鑰
  • 應用程式必須向服務供應商註冊
內部網路網站、入口網站

由內部或信任的第三方開發人員編寫的可信任應用程式。

登入貴公司的人資網站選擇保險服務，就是個好例子 提交評論或變更個人資訊
  • 密碼
  • 隱性偏誤
  • 必須提供用戶端 ID 和密鑰，以及使用者名稱和密碼
  • 應用程式必須向服務供應商註冊
公開的應用程式 不信任的應用程式是由非可靠業務的第三方開發人員所編寫 與 API 供應商的關係舉例來說，註冊公用 API 的開發人員 這些程式通常不應受到信任的
  • 授權碼
  • 使用者必須登入第三方資源供應器 (例如Twitter、 Facebook)
  • 應用程式看不到使用者的使用者名稱和密碼
  • 應用程式必須向服務供應商註冊
企業對消費者 涉及個別使用者 (行動裝置使用者)，且儲存使用者憑證 行動裝置使用者
  • 隱性偏誤
  • 應用程式必須向服務供應商註冊。
  • 使用者憑證會儲存在執行應用程式的裝置上。

OAuth 2.0 與 API 金鑰的比較 安全性

API 金鑰驗證需要應用程式將金鑰傳送至 Edge。金鑰必須是有效的消費者金鑰 。如果您基於某種原因 要撤銷用戶端應用程式呼叫 Proxy 的權限，您必須撤銷該權限， 用戶端金鑰。所有使用該金鑰的用戶端應用程式也無法存取 API Proxy。每月中的特定幾天 使用者可隨時撤銷 OAuth 權杖，不必撤銷應用程式的金鑰。應用程式 可以直接代表使用者要求新權杖 如果獲得權杖，應用程式 繼續使用 API Proxy

API 金鑰與權杖的另一項差異是，權杖可以包含中繼資料 屬性例如，您可以儲存使用者 ID ，並使用該呼叫來自訂對後端目標服務的呼叫。

如要進一步瞭解 API 金鑰驗證，請參閱 API 金鑰。如要瞭解如何搭配 OAuth 權杖使用自訂屬性，請參閱自訂權杖與 授權碼。

建議 資源

閱讀

請參閱瞭解 OAuth 2.0。