Google API 使用 OAuth 2.0 通訊協定進行驗證及授權。Google 支援常見的 OAuth 2.0 使用情境，例如網路伺服器、用戶端、已安裝及輸入受限裝置應用程式。
首先，請從 Google API Console取得 OAuth 2.0 用戶端憑證。接著，用戶端應用程式會向 Google 授權伺服器要求存取權杖，從回應中擷取權杖，然後將權杖傳送至要存取的 Google API。如需 OAuth 2.0 與 Google 搭配使用的互動示範 (包括示範如何使用自己的用戶端憑證)，歡迎試用 OAuth 2.0 Playground。
本頁提供 Google 支援的 OAuth 2.0 授權情境總覽，並提供更詳細內容的連結。如要瞭解如何使用 OAuth 2.0 進行驗證，請參閱 OpenID Connect。
基本步驟
使用 OAuth 2.0 存取 Google API 時，所有應用程式都會遵循基本模式。大致來說，您需要完成下列五個步驟：
1. 從 Google API Console取得 OAuth 2.0 憑證。
前往 Google API Console 取得 OAuth 2.0 憑證，例如 Google 和應用程式都知道的用戶端 ID 和用戶端密鑰。值集會因您建構的應用程式類型而異。舉例來說，JavaScript 應用程式不需要密鑰，但網路伺服器應用程式需要。
您必須為應用程式執行的平台建立適當的 OAuth 用戶端，例如：
- 程式碼 如果是伺服器端或 JavaScript 網頁應用程式，請使用「網頁」用戶端類型。請勿將這個用戶端類型用於任何其他應用程式，例如原生或行動應用程式。
- 如果是 Android 應用程式，請使用「Android」用戶端類型。
-
如果是 iOS 和 macOS 應用程式，請使用「iOS」用戶端類型。
- 如果是通用 Windows 平台應用程式，請使用「通用 Windows 平台」用戶端類型。
- tv 如果是輸入受限的裝置 (例如電視或嵌入式裝置)，請使用「電視和輸入受限的裝置」用戶端類型。
- 主機 如要進行伺服器對伺服器的互動，請使用服務帳戶。
2. 從 Google 授權伺服器取得存取權杖。
應用程式必須先取得存取憑證，才能使用 Google API 存取私人資料。單一存取權杖可授予多個 API 不同程度的存取權。名為 scope 的變數參數會控管存取權杖允許的資源和作業集。在存取權杖要求期間，應用程式會在 scope 參數中傳送一或多個值。
提出這類要求的方式有很多種，實際做法視您建構的應用程式類型而定。舉例來說，JavaScript 應用程式可能會使用瀏覽器重新導向至 Google 的方式要求存取權杖，而安裝在沒有瀏覽器的裝置上的應用程式則會使用網路服務要求。
部分要求需要驗證步驟，使用者必須登入 Google 帳戶。登入後，系統會詢問使用者是否願意授予應用程式要求的一或多項權限。這項程序稱為「使用者同意聲明」。
如果使用者授予至少一項權限，Google 授權伺服器會將存取權杖 (或授權碼，應用程式可使用該授權碼取得存取權杖) 和該權杖授予的存取範圍清單傳送給您的應用程式。如果使用者未授予權限，伺服器會傳回錯誤。
一般而言，最佳做法是在需要存取權時，逐步要求範圍，而非預先要求。舉例來說，如果應用程式要支援將活動儲存至日曆，就不應要求 Google 日曆存取權，直到使用者按下「新增至日曆」按鈕為止；請參閱增量授權。
3. 檢查使用者授予的存取範圍。
比較存取權杖回應中包含的範圍，以及存取應用程式功能所需的範圍，這些功能取決於存取相關 Google API。如果應用程式的某些功能無法在沒有相關 API 存取權的情況下運作，請停用這些功能。
即使使用者授予所有要求的範圍，要求中包含的範圍可能與回應中包含的範圍不符。如要瞭解存取權範圍，請參閱各項 Google API 的說明文件。API 可能會將多個範圍字串值對應至單一存取範圍，並為要求中允許的所有值傳回相同的範圍字串。示例：應用程式要求使用者授權 https://www.google.com/m8/feeds/ 範圍時，Google People API 可能會傳回 https://www.googleapis.com/auth/contacts 範圍；Google People API 方法 people.updateContact 需要已授權的 https://www.googleapis.com/auth/contacts 範圍。
4. 將存取權杖傳送至 API。
應用程式取得存取權杖後，會透過 HTTP 授權要求標頭將權杖傳送至 Google API。 您可以將權杖做為 URI 查詢字串參數傳送，但我們不建議這麼做，因為 URI 參數可能會出現在不完全安全的記錄檔中。此外，避免建立不必要的 URI 參數名稱，也是良好的 REST 做法。
存取權杖僅適用於權杖要求 scope 中所述的一組作業和資源。舉例來說，如果存取權杖是為 Google 日曆 API 核發，就無法用來存取 Google 聯絡人 API。不過，您可以多次將該存取權杖傳送至 Google Calendar API，執行類似作業。
5. 視需要重新整理存取權杖。
存取權杖的生命週期有限。如果應用程式需要存取 Google API，且存取時間超過單一存取權杖的有效期限，可以取得更新權杖。應用程式可透過更新權杖取得新的存取權杖。
情境
網路伺服器應用程式
Google OAuth 2.0 端點支援使用 PHP、Java、Go、Python、Ruby 和 ASP.NET 等語言和架構的網頁伺服器應用程式。
應用程式將瀏覽器重新導向至 Google 網址時，授權程序就會開始。該網址包含查詢參數，指出所要求的存取類型。Google 會處理使用者驗證、工作階段選取和使用者同意聲明。結果是授權碼，應用程式可將其交換為存取權杖和更新權杖。
應用程式應儲存更新權杖以供日後使用，並使用存取權杖存取 Google API。存取權杖到期後，應用程式會使用重新整理權杖取得新的權杖。
詳情請參閱「使用 OAuth 2.0 處理網路伺服器應用程式」。
已安裝的應用程式
Google OAuth 2.0 端點支援安裝在電腦、行動裝置和平板電腦等裝置上的應用程式。透過 Google API Console建立用戶端 ID 時，請指定這是已安裝的應用程式，然後選取 Android、Chrome 應用程式、iOS、 通用 Windows 平台 (UWP) 或桌面應用程式做為應用程式類型。
這個程序會產生用戶端 ID，有時也會產生用戶端密鑰，您可將這些資訊嵌入應用程式的原始碼。(在這個情況下，用戶端密鑰顯然不會視為密鑰)。
應用程式將瀏覽器重新導向至 Google 網址時，授權程序就會開始。該網址包含查詢參數，指出所要求的存取類型。Google 會處理使用者驗證、工作階段選取和使用者同意聲明。結果是授權碼，應用程式可將其交換為存取權杖和更新權杖。
應用程式應儲存更新權杖以供日後使用，並使用存取權杖存取 Google API。存取權杖到期後，應用程式會使用重新整理權杖取得新的權杖。
詳情請參閱「 針對已安裝的應用程式使用 OAuth 2.0」。
用戶端 (JavaScript) 應用程式
Google OAuth 2.0 端點支援在瀏覽器中執行的 JavaScript 應用程式。
應用程式將瀏覽器重新導向至 Google 網址時，授權程序就會開始。該網址包含查詢參數，指出所要求的存取類型。Google 會處理使用者驗證、工作階段選取和使用者同意聲明。
結果是存取權杖，用戶端應先驗證權杖，再將其納入 Google API 要求。權杖到期時，應用程式會重複這個程序。
詳情請參閱「針對用戶端應用程式使用 OAuth 2.0」。
輸入受限裝置的應用程式
Google OAuth 2.0 端點支援在輸入受限的裝置上執行的應用程式，例如遊戲主機、攝影機和印表機。
授權程序開始時，應用程式會向 Google 網址發出網路服務要求，以取得授權碼。回應包含多個參數，包括應用程式向使用者顯示的網址和代碼。
使用者從裝置取得網址和代碼，然後切換到其他裝置或電腦，透過更豐富的輸入功能進行操作。使用者開啟瀏覽器，前往指定網址登入並輸入代碼。
同時，應用程式會以指定間隔輪詢 Google 網址。使用者核准存取權後，Google 伺服器的回應會包含存取權杖和重新整理權杖。應用程式應儲存更新權杖以供日後使用，並使用存取權杖存取 Google API。存取權杖到期後，應用程式會使用重新整理權杖取得新的權杖。
詳情請參閱「使用 OAuth 2.0 處理裝置」。
服務帳戶
Google API (例如 Prediction API 和 Google Cloud Storage) 可代表應用程式執行動作，不必存取使用者資訊。在這種情況下，應用程式必須向 API 證明自己的身分，但不需要使用者同意。同樣地，在企業情境中，應用程式可以要求對某些資源的委派存取權。
這類伺服器間的互動需要服務帳戶，這類帳戶屬於應用程式，而非個別使用者。您的應用程式會代表服務帳戶呼叫 Google API，因此不需要使用者同意。(在非服務帳戶情境中，應用程式會代表使用者呼叫 Google API，有時需要使用者同意)。
服務帳戶的憑證 (可從 Google API Console取得) 包含產生的專屬電子郵件地址、用戶端 ID，以及至少一組公開/私密金鑰。您可以使用用戶端 ID 和一個私密金鑰建立已簽署的 JWT，並以適當格式建立存取權杖要求。接著，應用程式會向 Google OAuth 2.0 授權伺服器傳送權杖要求，伺服器會傳回存取權杖。應用程式會使用權杖存取 Google API。權杖到期時，應用程式會重複這個程序。
詳情請參閱 服務帳戶說明文件。
權杖大小
權杖大小可能不同，但不得超過下列限制：
Google Cloud 的 Security Token Service API 傳回的存取權杖結構與 Google API OAuth 2.0 存取權杖類似，但權杖大小限制不同。詳情請參閱 API 說明文件。
Google 保留在這些限制內變更權杖大小的權利，您的應用程式必須支援相應的權杖大小變數。
更新權杖到期時間
您必須編寫程式碼，預期獲准的重新整理權杖可能不再有效。重新整理權杖可能因下列原因而無法運作：
如果 Google Cloud Platform 專案的 OAuth 同意畫面是為外部使用者類型設定，且發布狀態為「測試中」，系統就會核發 7 天後過期的重新整理權杖，但如果要求的 OAuth 範圍僅限於名稱、電子郵件地址和使用者設定檔 (透過
userinfo.email, userinfo.profile, openid 範圍或對應的 OpenID Connect 範圍)，則不在此限。
目前每個 OAuth 2.0 用戶端 ID 的 Google 帳戶最多可有 100 個更新權杖。 達到上限後，一旦建立新權杖，最舊的權杖就會自動失效，且系統不會發出警告。這項限制不適用於服務帳戶。
此外，使用者帳戶或服務帳戶在所有用戶端擁有的重新整理權杖總數也有較高的限制。一般使用者不會超過這個限制，但用於測試實作的開發人員帳戶可能會。
如需授權多個程式、電腦或裝置，其中一個解決方法是將每個 Google 帳戶授權的用戶端數量限制為 15 或 20 個。如果您是 Google Workspace 管理員，可以建立具有管理員權限的其他使用者，並使用這些使用者授權部分用戶端。
處理 Google Cloud Platform (GCP) 機構的工作階段控制政策
GCP 機構管理員可以使用 Google Cloud 工作階段控制功能，要求使用者在存取 GCP 資源時經常重新驗證。這項政策會影響 Google Cloud 控制台、Google Cloud SDK (也稱為 gcloud CLI)，以及任何需要 Cloud Platform 範圍的第三方 OAuth 應用程式。如果使用者已啟用工作階段控制政策，工作階段時間到期後，API 呼叫會發生錯誤，與權杖遭撤銷的情況類似。呼叫會失敗並傳回 invalid_grant 錯誤類型；error_subtype 欄位可用於區分權杖遭撤銷，以及因工作階段控制政策而失敗的情況 (例如 "error_subtype": "invalid_rapt")。由於工作階段時間可能非常短 (1 到 24 小時)，因此必須重新啟動驗證工作階段，才能妥善處理這種情況。
同樣地，您不得使用或鼓勵使用使用者憑證進行伺服器對伺服器部署作業。如果使用者憑證部署在伺服器上，用於長時間執行的工作或作業，且客戶對這類使用者套用工作階段控制政策，伺服器應用程式就會失敗，因為工作階段時間到期時，系統無法重新驗證使用者。
如要進一步瞭解如何協助顧客部署這項功能，請參閱這篇以管理員為對象的說明文章。
用戶端程式庫
下列用戶端程式庫與熱門架構整合，可簡化 OAuth 2.0 的實作程序。我們日後會陸續在程式庫中推出更多新功能，敬請期待。