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 的 OAuth 2.0 定義 (根據 OAuth 2.0 IETF 規格本身)：

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

值得注意的是，OAuth 2.0 可讓應用程式有限存取使用者受保護的資源 (例如銀行帳戶，或是使用者可能會想從應用程式存取的其他機密資訊)，而不需讓使用者取得應用程式的登入憑證。

OAuth 2.0 流程

以下是 OAuth 2.0 安全性架構的一般流程。我們會在本主題中深入探討這個流程，首先從圖表開始，當中會概略說明 OAuth 2.0 的運作方式。如果您不熟悉下圖中的術語，請參閱本節的簡要說明。

重要詞彙

  • 用戶端：也稱為「應用程式」。可以是在行動裝置或傳統網頁應用程式中執行的應用程式，應用程式會代表資源擁有者，向資源伺服器發出受保護資產的要求。資源擁有者必須授權應用程式存取受保護的資源。
  • 資源擁有者：也稱為「使用者」。這通常是能夠授予受保護資源存取權的人員 (或其他實體)。舉例來說，如果應用程式需要使用您其中一個社群媒體網站的資料，則您是資源擁有者，也就是唯一可以授權應用程式存取您的資料的人。
  • 資源伺服器：您可以將資源伺服器視為服務 (例如 Facebook、Google 或 Twitter) 或您內部網路的人力資源服務，或 B2B 額外網上的合作夥伴服務。每當需要 OAuth 權杖驗證來處理 API 要求時，Apigee Edge 都是資源伺服器。資源伺服器需要取得某種授權，才能為應用程式提供受保護的資源。
  • 授權伺服器：授權伺服器是依照 OAuth 2.0 規格實作，並負責驗證授權授權及核發存取權杖，讓應用程式能夠存取資源伺服器上的使用者資料。您可以在 Apigee Edge 上設定「權杖端點」，在此情況下，Edge 會負責處理授權伺服器的角色。
  • 授權授權：授予應用程式代表使用者擷取存取權杖的權限。OAuth 2.0 定義了四種具體的「授權類型」。請參閱下方「什麼是 OAuth 2.0 授權類型」一節。
  • 存取權杖：一長串字元，可做為存取受保護資源的憑證。另請參閱下文「什麼是存取權杖？」一節。
  • 受保護的資源：資源擁有者擁有的資料。例如使用者的聯絡人清單、帳戶資訊或其他機密資料。

Apigee Edge 適用的位置

您可以使用 OAuth 2.0 保護透過 Apigee Edge 執行的任何 API。Edge 包含授權伺服器實作項目，因此可以產生和驗證存取權杖。 開發人員先使用 Apigee Edge 註冊應用程式。已註冊的應用程式可以透過四種授權類型互動中的任一種，要求存取權杖。

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 可以授予應用程式有限資源的存取權。舉例來說，應用程式可能只具備特定資源的存取權、更新資源，或者只授予唯讀存取權。在所謂的「三足式」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)
  • 應用程式一律無法查看使用者名稱和密碼
  • 應用程式必須向服務供應商註冊
B2C 讓一名行動裝置使用者 (行動裝置使用者) 和使用者憑證儲存在行動裝置上。
  • 隱性
  • 應用程式必須向服務供應商註冊。
  • 使用者憑證會儲存在執行應用程式的裝置上。

OAuth 2.0 與 API 金鑰安全性

API 金鑰驗證程序必須要有應用程式，才能將金鑰傳送至 Edge。金鑰必須是與 API Proxy 相關聯的 Apigee Edge 開發人員應用程式中的有效用戶端金鑰。如果因為某些原因而需要撤銷用戶端應用程式呼叫 Proxy 的權限，您必須撤銷該用戶端金鑰。凡是使用這個金鑰的用戶端應用程式，也都將無法存取 API Proxy。另一方面，您可以隨時撤銷 OAuth 權杖，不必撤銷應用程式的金鑰。應用程式只需代表使用者要求新的權杖，當取得權杖後，應用程式即可繼續使用 API Proxy。

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

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

推薦資源

閱讀資源

請參閱瞭解 OAuth 2.0。