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 Proxy 呼叫的任何資源伺服器都應位於防火牆後方 (也就是說，除了 API Proxy 或其他安全無虞的 API 之外，不得透過任何方式存取資源)。

OAuth 2.0 授權類型有哪些？

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

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

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

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

  • implicit：視為授權碼的簡化版本。 應用程式位於用戶端時，通常會使用這類授權類型。舉例來說，應用程式的程式碼是在瀏覽器中以 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」。