本頁說明整合 OAuth 2.0 的一些一般最佳做法。除了適用於應用程式與開發平台類型的特定指南外，您也可以考慮這些最佳做法。另請參閱為應用程式做好正式發布的準備建議和 Google 的 OAuth 2.0 政策。
安全處理用戶端憑證
OAuth 用戶端憑證會用於識別應用程式的身分，請謹慎處理。請只將這些憑證儲存在安全的儲存空間中，例如使用 Google Cloud Secret Manager 等密鑰管理工具。請勿將憑證硬式編碼、提交至程式碼存放區或公開發布。
安全處理使用者權杖
使用者權杖包含應用程式使用的更新權杖和存取權杖。以安全的方式儲存權杖，切勿以純文字格式傳送權杖。使用適合您平台的安全儲存系統，例如 Android 上的 Keystore、iOS 和 macOS 的 Keychain Services，或是 Windows 的 Credential Locker。
請盡快撤銷權杖，並將這些權杖從系統中永久刪除。
此外，也建議您考量下列平台最佳做法：
- 如果是用於為許多使用者儲存權杖的「伺服器端」應用程式，請在靜態資料加密，確保資料儲存庫不會透過網際網路公開存取。
- 如果是原生電腦版應用程式，強烈建議使用程式碼交換金鑰 (PKCE) 通訊協定來取得可交換存取權杖的授權碼。
處理更新權杖撤銷和到期時間
如果應用程式已要求用於離線存取的更新權杖，則您也必須處理這些項目的撤銷或到期時間。權杖可能會基於不同原因而失效，例如權杖已過期，或是應用程式存取權可能已由使用者撤銷，或有自動化程序撤銷。在這種情況下，請審慎考量應用程式應如何回應，包括在使用者下次登入時提示使用者，或是清除他們的資料。如要接收權杖撤銷通知，請整合跨帳戶防護服務。
使用漸進式授權
如果應用程式需要這項功能，請使用漸進式授權來要求適當的 OAuth 範圍。
除非對使用者應用程式的核心功能有必要，否則您不應在使用者第一次驗證時要求存取資料。請改為僅要求工作所需的特定範圍，請遵循原則來選取最小、限制範圍最多的範圍。
務必在使用情境中要求範圍，協助使用者瞭解應用程式要求存取權的原因及資料用途。
舉例來說，您的應用程式可能採用以下模型：
- 使用者使用您的應用程式進行驗證
- 無須要求任何其他範圍。應用程式提供基本功能，讓使用者能探索及使用不需要任何其他資料或存取權的功能。
- 使用者選取需要存取其他資料的功能
- 您的應用程式針對這項功能所需的這個特定 OAuth 範圍提出授權要求。如果這項功能需要多個範圍，請遵循下列最佳做法。
- 如果使用者拒絕要求，應用程式會停用該功能，並提供額外的背景資訊，讓使用者再次要求存取權。
處理多個範圍的同意聲明
如果您一次要求多個範圍，使用者可能不會授予您要求的所有 OAuth 範圍。應用程式應停用相關功能，以處理拒絕範圍的問題。
如果應用程式的基本功能需要多個範圍，請在顯示同意聲明提示前向使用者說明。
只有在使用者明確指出意圖使用需要該範圍的特定功能時，您才能再次提示使用者。在要求 OAuth 範圍之前，應用程式應向使用者提供相關背景資訊和理由。
建議您一次減少應用程式要求的範圍數量。而是可以運用漸進式授權在功能與功能的情境中要求範圍。
使用安全的瀏覽器
在網路上，OAuth 2.0 授權要求只能透過功能完整的網路瀏覽器提出。 在其他平台上，請務必選取正確的 OAuth 用戶端類型，並視情況整合 OAuth。請勿透過嵌入式瀏覽環境 (包括行動平台上的 WebView 或 iOS 上的 WKWebView) 重新導向要求。建議您針對平台採用原生 OAuth 程式庫或 Google 登入機制。
手動建立和設定 OAuth 用戶端
為避免濫用，我們不允許透過程式建立或修改 OAuth 用戶端。您必須透過 Google Developers Console 明確瞭解服務條款、設定 OAuth 用戶端，並準備進行 OAuth 驗證。
如需自動化工作流程，請考慮改用服務帳戶。