若你正在找 Google SSO 教學，首先要確認需求屬於哪一種：一般網站的「使用 Google 登入」通常採用 OpenID Connect（OIDC）與 OAuth 2.0；企業將 Google Workspace 當成身分識別提供者，讓員工登入 Adobe、Zoom 或其他 SaaS，則常使用 SAML 2.0。兩者都能實現 SSO 登入，但設定位置、交換資料與安全驗證方式並不相同。
Google SSO 是什麼
Google SSO 是以 Google 帳號或 Google Workspace 帳號完成集中式身分驗證的單一登入機制。使用者通過 Google 驗證後，能在授權範圍內登入已整合的應用程式，不必再為每項服務建立另一組密碼。
SSO 是一種登入架構，而不是單一協定。Google 登入常見的底層技術包括 OAuth 2.0、OpenID Connect 與 SAML 2.0。OAuth 2.0 主要處理授權；OIDC 在 OAuth 2.0 之上加入身分驗證；SAML 則使用 XML 格式的斷言，在企業身分系統與服務供應商之間傳遞驗證結果。
導入 SSO 不代表所有應用程式共用或看得到 Google 密碼。正確流程是由 Google 驗證使用者，再將具有時效性且經過簽章的驗證結果交給應用程式。
Google SSO 的運作流程
使用者從應用程式開始登入
以 Slack 的「以 Google 登入」流程說明：
- 使用者打開 Slack 並進入登入頁面。
- Slack 要求使用者登入。
- 使用者選擇「以 Google 登入」。
- Slack 將瀏覽器重新導向 Google。
- Google 要求使用者登入，必要時執行多因素驗證。
- Google 顯示應用程式要求的權限。
- 使用者同意後，Google 將瀏覽器導回 Slack 登記的回呼網址。
- Slack 驗證授權碼或權杖，建立應用程式工作階段。
- 使用者進入有權使用的工作區。
如果使用者已登入 Google，驗證畫面可能不會再次要求輸入密碼，但 Google 仍會依工作階段、風險判定及管理政策決定是否重新驗證。
應用程式背後的技術流程
採用 OIDC Authorization Code Flow 時，應用程式會產生 Google 授權網址，常見參數包括 client_id、redirect_uri、response_type=code、scope、state 與 nonce。
Google 完成驗證後，先把短效授權碼傳回應用程式。應用程式後端再使用授權碼交換 ID Token 與 Access Token。後端必須驗證 ID Token 的簽章、簽發者、接收者、有效期限及 nonce，確認無誤才能建立登入狀態。
網址中的 Client ID 是應用程式公開識別碼，不是密碼；Client Secret 則不得寫在前端 JavaScript、App 安裝包或公開程式碼儲存庫中。
Google SSO 技術比較
OIDC、OAuth 2.0 與 SAML 比較表
| 比較項目 | OpenID Connect | OAuth 2.0 | SAML 2.0 |
|---|---|---|---|
| 主要用途 | 身分驗證與登入 | 資源授權 | 企業單一登入 |
| 常見情境 | 使用 Google 登入網站或 App | 授權應用程式存取 Google API | Google Workspace 登入企業 SaaS |
| 資料格式 | JSON、JWT | Access Token | XML Assertion |
| 常見角色 | Google、網站、使用者 | 授權伺服器、用戶端、資源伺服器 | IdP、SP、使用者 |
| 行動裝置支援 | 良好 | 良好 | 通常以瀏覽器重新導向處理 |
| 適合新網站 | 是 | 需搭配 OIDC 才能完整處理登入 | 視企業需求而定 |
| 企業既有系統 | 可使用 | 不宜單獨當作登入協定 | 廣泛使用 |
| 重要安全機制 | state、nonce、PKCE、JWT 驗證 | state、PKCE、最小權限 | 憑證簽章、Audience、ACS URL |
不能只取得 Access Token 就假設使用者身分有效。若目的是登入，應使用 OIDC 並驗證 ID Token；若企業 SaaS 明確要求 Entity ID、ACS URL 與 X.509 憑證，通常應採用 SAML。
前置作業：取得 Google Client ID
建立或選擇 Google Cloud 專案
進入 Google Cloud Console，建立新專案或選擇既有專案。正式環境應使用組織管理的專案，設定明確的擁有者、帳務權限與管理責任，避免專案綁在單一離職人員的私人帳號。
Google Cloud 管理介面可能隨版本更新而調整。相關設定可能顯示在「API 和服務」或新版 Google Auth Platform 下，實際名稱應以官方控制台為準。
設定 OAuth 同意畫面
進入 OAuth 同意畫面或 Google Auth Platform 的 Branding、Audience、Data Access 頁面，填寫下列資料：
- 應用程式名稱。
- 使用者支援電子郵件。
- 開發人員聯絡資訊。
- 應用程式首頁。
- 隱私權政策及服務條款網址。
- 授權網域。
- 所需的 OAuth 權限範圍。
若應用程式只提供同一個 Google Workspace 組織使用，可依管理資格選擇「內部」。面向一般 Google 帳號時則選擇「外部」，並依發布狀態加入測試使用者。要求敏感或受限制權限，可能需要完成 Google 驗證程序。
建立 OAuth 用戶端
在憑證或 Clients 頁面建立 OAuth Client ID，並依產品選擇「網頁應用程式」、「Android」或「iOS」。網頁應用程式必須設定已授權的重新導向 URI，例如：
https://example.com/auth/google/callback
重新導向 URI 必須與程式送出的 redirect_uri 完全一致，包括 HTTPS、網域、路徑、連接埠及結尾斜線。正式環境不應使用不受控的測試網域，也不應允許任意網址作為回呼位置。
在網站加入「使用 Google 登入」
使用官方程式庫或成熟驗證框架
Google 建議網頁使用 Google Identity Services。若網站採用既有框架，也可選擇持續維護且支援 OIDC 的驗證套件，不宜自行實作權杖簽章演算法或完整 OAuth 流程。
使用者點選「使用 Google 登入」後，網站應建立隨機 state 與 nonce。公開用戶端及支援的流程應使用 PKCE，降低授權碼遭攔截後被濫用的風險。
後端驗證 ID Token
伺服器至少應檢查以下內容：
- 權杖簽章是否能以 Google 公開金鑰驗證。
iss是否為可信任的 Google 簽發者。aud是否符合網站的 Client ID。exp是否尚未過期。nonce是否與登入請求一致。- 需要電子郵件時，確認
email_verified狀態。 - 企業限定登入時，檢查實際組織政策與網域資料。
不應只依電子郵件文字判斷帳號歸屬，也不能只在前端解析 JWT。前端傳來的使用者名稱、電子郵件及權限資料都必須由後端重新驗證。
建立本機帳號與工作階段
Google 回傳穩定的使用者識別資訊後，應用程式可將其對應至本機帳號。資料庫的主要外部識別鍵應優先使用 Google 提供的 sub，而不是可能變更的電子郵件地址。
建立工作階段 Cookie 時，應設定 Secure、HttpOnly 與適當的 SameSite 屬性，並規劃閒置逾時、絕對有效期限、登出及撤銷機制。
使用 Google Workspace 設定 SAML SSO
確認 IdP 與 SP 的方向
當員工使用 Google Workspace 帳號登入 Adobe、Zoom 或其他 SaaS 時，Google 通常是身分識別提供者（IdP），SaaS 是服務供應商（SP）。
若企業要讓使用者透過其他 IdP 登入 Google Workspace，方向則相反：Google 成為 SP，第三方平台成為 IdP。兩種設定不能混用，開始操作前應先確認誰負責驗證使用者。
在 Google 管理控制台新增 SAML 應用程式
管理員可在 Google Admin Console 的「應用程式」及「網頁和行動應用程式」區域，尋找既有 SaaS 範本或新增自訂 SAML 應用程式。一般流程如下：
- 建立新的 SAML 應用程式。
- 取得 Google 的 SSO URL、Entity ID 與憑證。
- 將資料填入 SaaS 管理後台。
- 從 SaaS 取得 ACS URL 與 SP Entity ID。
- 將 ACS URL、Entity ID 填回 Google 管理控制台。
- 設定 Name ID 格式及使用者屬性對應。
- 將應用程式指派給測試群組或組織單位。
- 完成測試後再逐步開放。
Adobe Admin Console、Zoom、Logto Cloud Console 等產品的欄位名稱與選單位置不完全相同，應搭配各服務的官方 SAML 文件設定，不能直接將另一家產品的 URL 或 Entity ID 套用過去。
SSO 帳號與權限管理
登入成功不等於具有使用權限
SSO 解決的是身分驗證問題，應用程式授權仍須另外管理。使用者即使通過 Google 驗證，也不一定擁有 Adobe 授權、Slack 工作區成員資格或企業內部系統角色。
組織應明確定義下列生命週期：
- 新進人員帳號建立與應用程式指派。
- 部門異動後的角色調整。
- 留職停薪或暫停帳號的處理。
- 離職時撤銷 Google 帳號、工作階段及 SaaS 權限。
- 退休人員、校友與外部協作者的存取期限。
大型組織可搭配 SCIM 或供應商提供的自動佈建功能管理帳號，但仍需確認停權、刪除與授權回收是否同步生效。
Google SSO 安全設定重點
強制使用多因素驗證
Google Workspace 管理員應依組織風險要求啟用兩步驟驗證，優先採用安全金鑰、Passkey 或其他抗網路釣魚方式。SSO 減少密碼數量，但也提高主要帳號遭入侵後的影響，因此核心帳號需要更強的保護。
落實最小權限
只申請產品實際需要的 OAuth Scope。單純登入通常只需基本 OIDC 範圍，例如 openid、email 與 profile。若要求 Gmail、Google Drive 或管理員資料權限，必須說明用途並遵循 Google API 使用者資料政策。
保留緊急管理方式
若 SAML 設定錯誤、憑證過期或 IdP 中斷，管理員可能無法登入。正式啟用前應保留受嚴格控管的緊急管理帳號，記錄復原程序，並避免所有超級管理員都依賴同一條 SSO 路徑。
監控登入與憑證期限
組織應定期檢查登入紀錄、異常地點、失敗驗證、管理員操作與 OAuth 應用程式授權。SAML 憑證也有有效期限，必須在到期前完成新舊憑證輪替及測試。
常見設定失敗原因
Redirect URI 不相符
這是 OAuth 登入最常見的錯誤之一。應確認程式與 Google Cloud Console 的 URI 完全相同，並檢查 HTTP、HTTPS、子網域、連接埠及結尾斜線。
應用程式仍處於測試狀態
外部應用程式若尚未正式發布，只有列入測試名單的帳號能登入。測試權杖也可能受較短的有效政策限制，不適合直接當成正式環境。
SAML 時間或欄位錯誤
SAML Assertion 具有時間限制。伺服器時間偏差、Audience 不符、ACS URL 錯誤、Name ID 格式錯誤或簽章憑證過期，都可能造成 SSO 登入失敗。
使用者尚未被指派應用程式
Google 管理控制台完成 SAML 設定後，仍需把服務開放給指定組織單位或群組。SaaS 端若未啟用即時建立帳號，還必須先建立使用者或透過 SCIM 佈建。
上線前檢查清單
技術與管理檢查項目
- 正式環境全面使用 HTTPS。
- Client Secret 僅保存在後端祕密管理系統。
- 已驗證
state、nonce、簽章、aud、iss與有效期限。 - OAuth Scope 符合最小權限原則。
- 測試新使用者、既有使用者、停權帳號與未授權帳號。
- 測試登入、登出、逾時與權杖撤銷。
- 設定多因素驗證與異常登入告警。
- 確認 SaaS 權限不會因登入成功而自動過度授權。
- 記錄 SAML 憑證到期日與輪替負責人。
- 建立 IdP 中斷時的緊急管理程序。
結論
Google SSO 的正確做法取決於使用情境：網站提供「使用 Google 登入」時，應採用 OIDC Authorization Code Flow、Google Identity Services 及完整的 ID Token 驗證；Google Workspace 員工登入企業 SaaS 時，則通常使用 SAML 2.0，並在 Google Admin Console 與服務供應商兩端交換設定。
真正安全的單一登入不只是新增一顆登入按鈕，還包括最小權限、多因素驗證、工作階段管理、帳號生命週期、憑證輪替、日誌監控與緊急復原。控制台選單可能改版，實際部署時應以 Google Identity、Google Cloud、Google Workspace Admin Help 及 SaaS 供應商的最新官方文件為準。
常見問題
1. Google SSO 與「使用 Google 登入」相同嗎？
不完全相同。「使用 Google 登入」多半指 OIDC 社群登入；Google SSO 也可能指 Google Workspace 透過 SAML 登入企業應用程式，需依整合情境判斷。
2. Google SSO 一定要使用 Google Workspace 嗎？
不一定。一般網站可讓個人 Google 帳號透過 OIDC 登入；若要集中管理員工、群組、組織單位與企業 SaaS，通常會使用 Google Workspace。
3. OAuth 2.0 可以單獨用來確認身分嗎？
OAuth 2.0 的核心用途是授權，不是身分驗證。登入功能應搭配 OpenID Connect，取得並驗證 ID Token。
4. Client ID 出現在前端安全嗎？
Client ID 是公開的應用程式識別碼，可以出現在授權網址。Client Secret 才是機密資料，不得放在前端程式碼或公開儲存庫。
5. 為什麼會出現 redirecturimismatch？
通常是程式送出的重新導向 URI 與 Google Cloud Console 登記內容不完全一致。請逐一檢查通訊協定、網域、路徑、連接埠與結尾斜線。
6. Google SSO 可以限制只有公司帳號登入嗎？
可以，但不能只依前端電子郵件網域判斷。應使用 Google Workspace 內部應用程式設定、後端權杖驗證及組織端存取政策共同限制。
7. 啟用 SSO 後還需要多因素驗證嗎？
需要。SSO 會集中登入入口，一旦主要帳號被入侵，可能影響多個系統，因此更應啟用多因素驗證或 Passkey。
8. SAML 的 ACS URL 是什麼？
ACS URL 是服務供應商接收 SAML Response 的端點，必須由 SaaS 或企業應用程式提供，並正確登記在 Google 管理控制台。
9. SSO 可以自動刪除離職員工的 SaaS 帳號嗎？
不一定。停用 Google 帳號通常能阻止後續登入，但 SaaS 內的帳號、資料及授權可能仍存在。若需自動佈建與撤銷，應評估 SCIM 或供應商的生命週期管理功能。
10. 如何確認 Google SSO 已可正式上線？
應完成不同帳號狀態、錯誤流程、登出、逾時、權限撤銷、多因素驗證、憑證輪替及 IdP 中斷測試，並確認監控、復原與管理責任均已建立。