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