使用者授權的運作方式

如果您不熟悉 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 API 所需的 Google 存取權杖。
• 從使用者瀏覽器啟動授權碼流程。

常用步驟

隱含和授權碼流程都是以相同的方式開始：

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 略過帳戶選擇工具的顯示方式，為使用者省下重複步驟。Sign In With Google 傳回的 ID 權杖憑證包含使用者的電子郵件地址。

僅在瀏覽器中執行的網頁應用程式可能僅仰賴 Google 進行使用者驗證，選擇不實作使用者帳戶管理系統。在本情境中稱為隱含流程，不需要將更新權杖與使用者帳戶建立關聯，並管理安全儲存空間。

或者，授權碼流程需要使用者帳戶系統。每位使用者的更新權杖必須與後端平台上的個別帳戶建立關聯，並儲存憑證供日後使用。如何實作、使用及管理使用者帳戶系統是您的平台獨有的，在討論時不會深入討論。

查看及撤銷同意聲明

使用者隨時可以透過 Google 帳戶設定查看或撤銷同意聲明。

或者，網頁應用程式或平台可以呼叫 google.accounts.oauth2.revoke 來撤銷權杖，並移除使用者同意聲明，以便在使用者從平台中刪除帳戶時相當實用。

其他授權選項

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

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

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