OAuth 2.0 簡介

本頁適用於 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 說明文件。

OAuth 首頁：請參閱 OAuth 首頁，瞭解我們提供的 OAuth 指南總覽。

本主題將簡要介紹 Apigee 上的 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 的運作方式。如果您不熟悉這張圖表中使用的術語，請參閱本節的快速介紹。

OAuth 2.0 安全性架構的一般流程。

重要用語須知

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

Apigee 的適用情況

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

Apigee 提供多面向的 OAuthV2 政策，可實作各授權類型的詳細資料，讓您輕鬆在 Apigee 上設定 OAuth。舉例來說，您可以設定政策，讓系統接收存取權杖要求、評估所有必要憑證，並在憑證有效時傳回存取權杖。

請注意，安全 API 代理程式呼叫的任何資源伺服器都應位於防火牆後方 (也就是說，除了 API 代理程式或其他安全的 API 之外，任何人都無法存取這些資源)。

什麼是 OAuth 2.0 授權類型？

您可以將授權類型視為應用程式可用來取得存取權權杖的不同路徑或互動。每個授權類型都適用於一或多個用途，您必須根據自身需求選取要使用的授權類型。一般來說，每種補助金類型都有優缺點，您必須根據業務用途權衡利弊。其中一個重要考量是，將存取您資料的應用程式是否可信任。一般來說，第三方應用程式比企業內部開發及使用的應用程式可信度較低。

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

  • 授權碼：一般認為安全性最高的授權類型。授權伺服器發出存取權權杖之前，應用程式必須先從資源伺服器接收授權碼。您在應用程式開啟瀏覽器連往資源伺服器的登入頁面，並邀請您登入實際帳戶 (例如 Facebook 或 Twitter) 時，就會看到這個流程。

如果您成功登入，應用程式會收到授權碼，可用於與授權伺服器協商存取權杖。通常，當應用程式位於伺服器而非用戶端時，就會使用這類授權類型。由於用戶端應用程式不會處理或查看資源伺服器的使用者名稱或密碼 (也就是說，應用程式不會查看或處理您的 Twitter 憑證)，因此這類授權類型被視為高度安全。這種授權類型流程也稱為「三方 OAuth」。

  • 隱含：可視為授權碼的簡化版本。 通常，當應用程式位於用戶端時，就會使用這類授權類型。舉例來說，應用程式的程式碼是使用 JavaScript 或其他指令碼語言在瀏覽器中實作 (而非位於個別網頁伺服器上執行)。在這種授權類型流程中，授權伺服器會在使用者通過驗證時直接傳回存取權權杖，而不會先發出授權碼。在某些情況下，隱含授權可改善應用程式的回應速度，但這項優點必須與 IETF 規格中所述的潛在安全性影響權衡。
  • 資源擁有者密碼憑證：在這個流程中，當授權伺服器驗證使用者的使用者名稱/密碼時，系統會為用戶端發出存取權權杖。我們建議您將這項流程用於高度信任的應用程式。相較於基本驗證，這個流程的優點在於使用者只需提供一次使用者名稱/密碼。從那時起，系統就會使用存取權杖。
  • 用戶端憑證：建議在用戶端應用程式代表自身執行操作時使用。也就是說，用戶端也是資源擁有者。這類授權類型通常用於應用程式需要存取後端資料儲存服務的情況。應用程式需要使用服務來執行工作，否則使用者無法瞭解服務。使用這類授權類型時，應用程式可以向授權伺服器提供用戶端 ID 和用戶端密鑰，以便接收存取權杖。您不需要採取進一步行動。 提供立即可用的用戶端憑證解決方案，可輕鬆為任何 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 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 金鑰驗證時，應用程式必須將金鑰傳送至 Apigee。金鑰必須是與 API Proxy 相關聯的 Apigee 開發人員應用程式中的有效消費者金鑰。如果您基於某些原因需要撤銷用戶端應用程式呼叫 Proxy 的權限，則必須撤銷該消費者金鑰。使用該金鑰的所有用戶端應用程式也無法存取 API 代理程式。另一方面，您隨時可以撤銷 OAuth 權杖，而不會撤銷應用程式的金鑰。應用程式只要代表使用者要求新的權杖，如果系統授予權杖，應用程式就能繼續使用 API Proxy。

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

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

權杖到期和清除時間對磁碟儲存空間的影響

使用 OAuthV2 政策產生新的 OAuth 權杖時，您可以使用 ExpiresIn 屬性為權杖設定到期時間。根據預設，權杖會在到期後的三天內從儲存空間中清除。如果您設定較長的到期時間 (例如 48 小時)，Cassandra 的磁碟空間用量可能會意外增加。為避免使用過多的磁碟空間，您可以設定較短的到期時間 (建議為一小時) 和/或設定將到期後延遲三天的延遲時間縮短至較短的時間。

Apigee Hybrid 客戶可以在覆寫檔案中設定下列設定，以變更預設清除時間：

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "SECONDS"

其中 SECONDS 是 Apigee 在權杖到期後等待清除權杖的秒數。請務必將這段詩句完整輸入，包括引號。

舉例來說，如要將清除時間設為到期後一小時：

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "3600"

建議的資源

閱讀

請參閱「瞭解 OAuth 2.0」。