本頁面介紹與 OAuth 2.0 整合的一些一般最佳做法。除了參考應用程式類型和開發平台的特定指南外，也請考量下列最佳做法。另請參閱應用程式正式版準備建議和 Google 的 OAuth 2.0 政策。
安全處理用戶端憑證
OAuth 用戶端憑證會識別應用程式的身分，請務必謹慎處理。請務必將這些憑證儲存在安全儲存空間，例如使用 Google Cloud Secret Manager 等密鑰管理工具。請勿以硬式編碼方式處理憑證、將憑證提交至程式碼存放區，或公開發布憑證。
安全處理使用者權杖
使用者權杖包括應用程式使用的更新權杖和存取權杖。請安全地儲存靜態權杖，且一律不要以純文字格式傳輸。請使用適合您平台的安全儲存系統，例如 Android 上的 Keystore、iOS 和 macOS 上的 Keychain Services，或 Windows 上的 Credential Locker。
不再需要權杖時，請立即撤銷權杖，並從系統中永久刪除。
此外，也請考量下列平台最佳做法：
- 如果是儲存多位使用者權杖的伺服器端應用程式，請將靜態權杖加密，並確保資料儲存庫不會公開開放網際網路存取。
- 如果是電腦版應用程式，強烈建議使用程式碼交換證明金鑰 (PKCE) 通訊協定，取得可交換存取權杖的授權碼。
使用 DPoP 限制權杖傳送者
為防止應用程式遭到權杖竊取和重送攻擊，建議您使用 DPoP (Demonstrating Proof-of-Possession) 限制權杖傳送者。標準不記名權杖可供任何攔截者使用，但 DPoP 權杖會以加密方式繫結至用戶端產生及持有的專屬金鑰組。
使用 DPoP 時，用戶端在要求或更新權杖時，會向權杖端點提供證明 (已簽署的 JSON Web Token)。這項證明可證明用戶端擁有與權杖繫結的公開金鑰相對應的私密金鑰。如果 DPoP 繫結更新權杖外洩，攻擊者在沒有私密金鑰的情況下，無法重送權杖。
DPoP 與 PKCE 搭配使用，可提供全方位防護：
- PKCE 會在初始重新導向流程中保護授權碼。
- DPoP 可保護長期更新權杖，防止權杖遭入侵時發生重送攻擊。
如果您的應用程式符合下列條件，強烈建議採用 DPoP：
- 以安裝或桌面應用程式 (或與 Backend-for-Frontend 伺服器配對的單頁應用程式) 的形式運作，更新權杖可能更容易遭到竊取。
- 存取高度機密的資料或高價值 API，權杖外洩會造成重大影響。
- 必須符合嚴格的法規遵循或安全性標準，強制要求使用傳送者限制權杖。
如需建構 DPoP 證明和要求 DPoP 繫結權杖的詳細操作說明，請參閱「DPoP 採用指南」。
使用 state 參數
處理 OAuth 2.0 回應前，請確認從 Google 收到的 state 與授權要求中傳送的 state 相符。state 參數應為應用程式產生的不重複且無法猜測的值。
使用 state 參數有助於確保要求是由使用者 (而非惡意指令碼) 發出，並降低跨網站要求偽造 (CSRF) 攻擊的風險。
處理更新權杖撤銷和到期
如果應用程式要求離線存取更新權杖，您也必須處理權杖失效或過期的情況。權杖可能因各種原因而失效，例如權杖可能已過期，或使用者或自動化程序撤銷了應用程式的存取權。在這種情況下，請仔細考量應用程式應如何回應，包括在使用者下次登入時提示使用者，或清除其資料。如要接收權杖撤銷通知，請整合跨帳戶防護服務。
使用漸進式授權
當應用程式需要某項功能時，請使用漸進式授權要求適當的 OAuth 範圍。
除非是應用程式核心功能所需，否則請勿在使用者首次驗證時要求存取資料。請遵循選取最小、最有限範圍的原則，只要求工作所需的特定範圍。
請務必在相關情境中要求範圍，協助使用者瞭解應用程式要求存取權的原因，以及資料的使用方式。
舉例來說，您的應用程式可能採用以下模式：
- 使用者透過應用程式進行驗證
- 不要求其他範圍。應用程式提供基本功能，讓使用者探索及使用不需要任何額外資料或存取權的功能。
- 使用者選取需要存取其他資料的功能
- 應用程式會針對這項功能所需的特定 OAuth 範圍提出授權要求。如果這項功能需要多個範圍，請遵循多個範圍的最佳做法。
- 如果使用者拒絕要求，應用程式會停用該功能，並向使用者提供額外背景資訊，再次要求存取權。
處理多個範圍的同意聲明
一次要求多個範圍時，使用者可能不會授予您要求的所有 OAuth 範圍。如果使用者拒絕授予範圍，應用程式應停用相關功能。
如果應用程式的基本功能需要多個範圍，請先向使用者說明，再提示使用者同意。
只有在使用者明確表示有意使用需要該範圍的特定功能時，您才能再次提示使用者。應用程式應先向使用者提供相關背景資訊和理由，再要求 OAuth 範圍。
請盡量減少應用程式一次要求的範圍數量。請改為使用漸進式授權，在功能和功能的情境中要求範圍。
使用安全的瀏覽器
在網路上，OAuth 2.0 授權要求只能透過功能完整的網路瀏覽器提出。 在其他平台上，請務必選取正確的 OAuth 用戶端類型，並視平台情況整合 OAuth。請勿透過嵌入式瀏覽環境重新導向要求，包括行動平台上的網頁檢視，例如 Android 上的 WebView 或 iOS 上的 WKWebView。請改用平台建議的 OAuth 程式庫或 Google 登入。
手動建立及設定 OAuth 用戶端
為防止濫用，您無法透過程式輔助方式建立或修改 OAuth 用戶端。您必須使用 Google Cloud 控制台明確接受服務條款、設定 OAuth 用戶端，並準備進行 OAuth 驗證。
如果是自動化工作流程，建議改用服務帳戶。
移除未使用的 OAuth 用戶端
定期稽核 OAuth 2.0 用戶端，並主動刪除應用程式不再需要或已過時的用戶端。如果用戶端憑證遭盜用，用戶端可能會遭到濫用，因此保留未使用的用戶端設定可能會造成安全風險。
為進一步降低閒置用戶端帶來的風險，系統會 自動刪除閒置六個月的 OAuth 2.0 用戶端。
建議的最佳做法是主動移除未使用的用戶端，而不是等待系統自動刪除。這種做法可盡量縮小應用程式的攻擊面，並確保良好的安全衛生。