使用者授權的運作方式

如果您是 Google Identity 服務或授權的新手，請先閱讀總覽。

Google 提供包含授權功能的 JavaScript 程式庫，可協助您管理範圍、取得使用者同意聲明，以及簡化標準 OAuth 2.0 流程。在使用者瀏覽器中執行的網頁應用程式會使用這個程式庫管理 OAuth 2.0 隱含流程，或啟動授權碼流程，並在後端平台完成流程。

僅限驗證的範圍

只有使用者驗證會用到下列範圍：email、profile 和 openid。如果應用程式只使用這些範圍，請考慮是否可使用 JWT ID 權杖和使用 Google 帳戶登入功能，讓使用者註冊及登入。在大多數情況下，這是最直接的使用者驗證方法。

重要詞彙與概念

這些指南假設您已基本瞭解 OAuth 2.0 概念和 IETF 標準，例如 RFC6749。授權指南中會使用下列術語：

  • 存取權杖是 Google 核發的短期使用者憑證，用於安全地呼叫 Google API 和存取使用者資料。
  • 授權碼是 Google 發放的臨時代碼，用於安全地識別透過瀏覽器登入 Google 帳戶的個別使用者。後端平台會將這個授權碼換成存取和重新整理權杖。
  • 更新權杖是 Google 核發的長期有效使用者憑證，安全地儲存在您的平台，即使使用者不在，也能用來取得新的有效存取權杖。
  • 範圍會將權杖限制為特定且有限的使用者資料量，詳情請參閱「Google API 適用的 OAuth 2.0 範圍」。
  • 彈出式視窗模式：授權碼流程，以使用者瀏覽器中執行的 JavaScript 回呼為基礎。Google 會叫用回呼處理常式，然後由該常式負責將授權碼傳送至平台，具體做法則由您決定。
  • 重新導向模式是以 HTTP 重新導向為基礎的授權碼流程。使用者代理程式會先重新導向至 Google，然後 Google 會再次重新導向至您平台的授權碼端點，其中包含授權碼。

權杖有效期限由發行者 Google 設定。確切時間長度可能因各種因素而異。

OAuth 2.0 流程

本文將討論隱含和授權碼這兩種流程。兩者都會傳回適合搭配 Google API 使用的存取權杖。

建議使用授權碼流程，因為這樣可提升使用者安全性。這個流程也會傳回更新權杖，可用於取得存取權杖，不必有使用者在場，讓平台執行非同步動作，例如傳送簡訊提醒即將召開的會議 (該會議是臨時安排的)。選擇授權模型一文會更詳細說明這兩種流程的差異。

Google Identity 服務 JavaScript 程式庫遵循 OAuth 2.0 標準，可執行下列操作：

  • 管理隱含流程，讓瀏覽器中的網頁應用程式快速從 Google 取得存取權杖，以便呼叫 Google API。
  • 從使用者的瀏覽器啟動授權碼流程。

常見步驟

隱含和授權碼流程的啟動方式相同：

  1. 您的應用程式要求存取一或多個範圍。
  2. Google 會向使用者顯示同意聲明對話方塊，並視需要先讓使用者登入 Google 帳戶。
  3. 使用者個別核准每個要求的範圍。

每個流程的最後步驟都不相同。

使用隱含流程時

  • Google 會使用回呼處理常式，將同意聲明結果通知您的應用程式，並針對任何核准的範圍傳回存取權杖。

使用授權碼流程時

  • Google 會傳回每個使用者的授權碼：
    • 在重新導向模式中，系統會將授權碼傳回至平台的授權碼端點。
    • 在對話方塊模式中，系統會將程式碼傳回瀏覽器內應用程式的回呼處理常式，使用者不必離開網站。
  • 從「步驟 4：處理 OAuth 2.0 伺服器回應」開始，後端平台會與 Google 完成伺服器對伺服器的交換作業，最終會將每個使用者的更新權杖和存取權杖傳回平台。

取得存取權杖前，個別使用者必須先同意您的應用程式存取所要求的範圍。為此，Google 會在步驟 2 顯示同意聲明對話方塊，並在 myaccount.google.com/permissions 中記錄結果。

系統會向使用者顯示應用程式名稱、標誌、隱私權政策、服務條款和要求的範圍，以及核准或取消要求的選項。

圖 1 顯示單一範圍的同意聲明對話方塊。如果只要求單一範圍，就不必勾選核准或拒絕範圍的核取方塊。

使用者同意聲明對話方塊會顯示「取消」或「繼續」按鈕，以及單一範圍，不會顯示核取方塊。

圖 1：使用者同意聲明對話方塊，其中包含單一範圍。

圖 2 顯示多個範圍的同意聲明對話方塊。如果要求多個範圍，使用者必須勾選個別核取方塊，才能核准或拒絕每個範圍。

使用者同意聲明對話方塊，內含「取消」或「繼續」按鈕，以及多個範圍，每個範圍都有核取方塊選取器。

圖 2：包含多個範圍的使用者同意聲明對話方塊。

使用者帳戶

您必須具備 Google 帳戶，才能記錄同意聲明和核發存取權杖。 在此之前，個別使用者必須登入 Google 帳戶，向 Google 驗證身分。

雖然不是必要條件，但建議您使用「使用 Google 帳戶登入」功能，在網頁應用程式或後端平台註冊及登入。這樣做可減少必要步驟，降低使用者摩擦，並視需要將存取權杖與平台上的個別帳戶建立關聯。

舉例來說，使用「使用 Google 帳戶登入」功能可建立有效的 Google 帳戶工作階段，因此在提出授權要求時，就不必再提示使用者登入 Google 帳戶。如果您選擇透過其他方式 (例如使用者名稱和密碼，或其他身分識別供應商) 驗證應用程式的使用者，使用者仍須先登入 Google 帳戶才能提供同意聲明。

在授權初始化期間新增登入提示 (通常是使用者 Google 帳戶的電子郵件地址)，可讓 Google 略過帳戶選擇工具，為使用者省下一個步驟。使用 Google 帳戶登入傳回的 ID 權杖憑證包含使用者的電子郵件地址。

如果網頁應用程式只在瀏覽器中執行，可能只會依賴 Google 進行使用者驗證，而選擇不實作使用者帳戶管理系統。在這個情境 (稱為隱含流程) 中，不需要將更新權杖與使用者帳戶和管理安全儲存空間建立關聯。

或者，授權碼流程需要使用者帳戶系統。每個使用者的重新整理權杖都必須與後端平台上的個別帳戶建立關聯，並儲存以供日後使用。如何實作、使用及管理使用者帳戶系統，會因平台而異，因此本文不會詳細說明。

使用者隨時可以前往 Google 帳戶設定頁面查看或撤銷同意聲明。

視需要，您的網頁應用程式或平台可以呼叫 google.accounts.oauth2.revoke 撤銷權杖並移除使用者同意聲明，這在使用者從您的平台刪除帳戶時非常實用。

其他授權選項

或者，瀏覽器也可以直接呼叫 Google 的 OAuth 2.0 端點，如「用戶端網頁應用程式的 OAuth 2.0」所述，透過隱含流程取得存取權杖。

同樣地，您也可以選擇自行實作授權碼流程的方法，並按照「在網路伺服器應用程式實作 OAuth 2.0」一文中的步驟操作。

無論是哪種情況，我們都強烈建議使用 Google Identity 服務程式庫，以減少開發時間和精力，並盡可能降低安全風險，例如 OAuth 2.0 安全性最佳做法所述的風險。