本指南說明如何確保應用程式和使用者憑證安全無虞。
完成 OAuth 應用程式驗證
Google Ads API 的 OAuth 2.0 範圍屬於受限範圍，因此您應先完成 OAuth 應用程式驗證程序，再將應用程式投入正式環境。詳情請參閱 Google Identity 說明文件、說明中心有關未經驗證應用程式的文章，以及設定 OAuth 同意畫面的文件。
保護應用程式憑證
您應保護應用程式的 OAuth 2.0 用戶端 ID 和用戶端密鑰。這些憑證可協助使用者和 Google 識別您的應用程式，因此請務必謹慎處理。請妥善保管這些應用程式憑證，請勿使用不安全的機制分享這些憑證，例如在公開論壇上發布、在電子郵件附件中傳送含有這些憑證的設定檔、將憑證硬式編碼，或將憑證提交至程式碼存放區。建議盡可能使用密鑰管理工具，例如 Google Cloud Secret Manager 或 AWS Secret Manager。
如果 OAuth 2.0 用戶端密鑰遭盜用，您可以重設密鑰。
保護服務帳戶
如果您使用服務帳戶，請按照下列步驟保護帳戶安全：
請將服務帳戶金鑰和 JSON 檔案視為密碼，盡可能使用密鑰管理工具 (例如 Google Cloud Secret Manager 或 AWS Secret Manager) 保護密鑰。
請遵循 Google Cloud 提供的其他最佳做法，確保服務帳戶安全無虞並妥善管理。
保護使用者權杖
如果應用程式授權多位使用者，您應採取額外步驟，保護使用者的重新整理和存取權杖。請以靜態方式安全儲存權杖，且絕不以純文字傳輸權杖。使用適合您平台的安全儲存系統。
處理更新權杖的撤銷和到期情形
如果應用程式在授權時要求 OAuth 2.0 更新權杖，您也必須處理權杖失效或過期的情況。更新權杖可能會因各種原因而失效，您的應用程式應妥善因應，方法是在使用者下次登入時重新授權，或視情況清除資料。離線工作 (例如 cron 工作) 應偵測並記錄重新整理權杖已過期的帳戶，而不是繼續發出失敗的要求。如果應用程式在一段時間內持續產生大量錯誤，Google 可能會限制應用程式的流量，以維持 API 伺服器的穩定性。
管理多個範圍的同意聲明
如果應用程式要求多個 OAuth 2.0 範圍的授權，使用者可能不會授予您要求的所有 OAuth 範圍。應用程式應處理範圍遭拒的情況，方法是停用相關功能。只有在使用者明確表示有意使用需要範圍的特定功能時，您才能再次提示使用者。在這種情況下，請使用增量授權要求適當的 OAuth 範圍。
如果應用程式的基本功能需要多個範圍，請先向使用者說明這項需求，再徵求同意。