本頁會說明整合 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 控制台明確確認服務條款、設定 OAuth 用戶端，並準備 OAuth 驗證作業。
如果是自動化工作流程，請考慮改用服務帳戶。