最佳做法

安全地處理用戶端憑證

OAuth 用戶端憑證會識別應用程式的身分，請務必謹慎處理。請務必將這些憑證儲存在安全儲存空間中，例如使用 Google Cloud Secret Manager 等密鑰管理工具。請勿將憑證以硬式編碼方式加入程式碼，也不要提交至程式碼存放區或公開發布。

安全處理使用者權杖

使用者權杖包括應用程式使用的更新權杖和存取權杖。安全地靜態儲存權杖，且絕不以純文字傳輸權杖。使用適合您平台的安全儲存系統，例如 Android 的 Keystore、iOS 和 macOS 的 Keychain Services，或是 Windows 的 Credential Locker。

不再需要權杖時，請立即撤銷權杖，並從系統中永久刪除。

此外，也請考慮為平台採用下列最佳做法：

• 對於儲存多位使用者權杖的伺服器端應用程式，請在權杖閒置時加密，並確保網際網路無法公開存取資料儲存庫。
• 對於原生電腦應用程式，強烈建議使用程式碼交換驗證金鑰 (PKCE) 通訊協定，取得可交換存取權杖的授權碼。

處理更新權杖的撤銷和到期情形

如果應用程式已要求離線存取權的重新整理權杖，您也必須處理權杖失效或過期的情況。權杖可能因各種原因而失效，例如權杖可能已過期，或是使用者或自動程序撤銷了應用程式的存取權。在這種情況下，請仔細考量應用程式應如何回應，包括在使用者下次登入時提示他們，或是清除他們的資料。如要接收權杖撤銷通知，請整合跨帳戶防護服務。

使用增量授權

應用程式需要某項功能時，請使用增量授權要求適當的 OAuth 範圍。

除非是應用程式核心功能不可或缺的權限，否則請勿在使用者首次驗證時要求存取資料。請遵循盡可能選取最小、最有限範圍的原則，只要求工作所需的特定範圍。

請務必在相關情境中要求範圍，協助使用者瞭解應用程式要求存取權的原因，以及資料的用途。

舉例來說，您的應用程式可能遵循下列模型：

1. 使用者透過您的應用程式進行驗證
   1. 未要求其他範圍。應用程式提供基本功能，讓使用者探索及使用不需要任何額外資料或存取權的功能。
2. 使用者選取需要存取額外資料的功能
   1. 您的應用程式會針對這項功能所需的特定 OAuth 範圍發出授權要求。如果這項功能需要多個範圍，請按照下列最佳做法操作。
   2. 如果使用者拒絕要求，應用程式會停用該功能，並提供額外背景資訊，讓使用者再次要求存取權。

處理多個範圍的同意聲明

一次要求多個範圍時，使用者可能不會授予您要求的所有 OAuth 範圍。應用程式應處理範圍遭拒的情況，方法是停用相關功能。

如果應用程式的基本功能需要多個範圍，請先向使用者說明，再提示他們同意。

只有在使用者明確表示要使用需要該範圍的特定功能時，您才能再次提示使用者。應用程式應先向使用者提供相關背景資訊和理由，再要求 OAuth 範圍。

請盡量減少應用程式一次要求授權的範圍數量。請改用增量授權，在功能和函式的背景資訊中要求範圍。

使用安全瀏覽器

在網路上，OAuth 2.0 授權要求只能透過功能齊全的網頁瀏覽器提出。 在其他平台上，請務必選取正確的 OAuth 用戶端類型，並視平台需要整合 OAuth。請勿透過嵌入式瀏覽環境重新導向請求，包括行動平台上的 WebView，例如 Android 上的 WebView 或 iOS 上的 WKWebView。請改用平台適用的原生 OAuth 程式庫或 Google 登入。

手動建立及設定 OAuth 用戶端

為防止濫用，OAuth 用戶端無法透過程式建立或修改。您必須使用 Google 開發人員控制台，明確確認服務條款、設定 OAuth 用戶端，並準備進行 OAuth 驗證。

如果是自動化工作流程，請考慮改用服務帳戶。

移除未使用的 OAuth 用戶端

定期稽核 OAuth 2.0 用戶端，並主動刪除應用程式不再需要或已過時的用戶端。如果設定了未使用的用戶端，一旦用戶端憑證遭盜用，用戶端就可能遭到濫用，造成潛在安全風險。

為進一步降低未使用用戶端帶來的風險，系統會 自動刪除閒置六個月的 OAuth 2.0 用戶端。

建議的最佳做法是不要等待系統自動刪除，而是主動移除未使用的用戶端。這種做法可縮小應用程式的攻擊面，確保良好的安全衛生。