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