This guide shows how to make sure your application and user credentials are secure.
Complete the OAuth App verification
The OAuth 2.0 scope for the Google Ads API is classified as a restricted scope, which means that you should complete the OAuth application verification process before productionizing your application. See the Google Identity documentation and Help Center article to learn more.
Secure the application credentials
You should secure your application's OAuth 2.0 client ID, and client secret. These credentials help your users and Google identify your application and thus they should be handled carefully. You should treat these application credentials like passwords. Don't share them using insecure mechanisms such as posting on public forums, sending configuration files containing these credentials in email attachments, hard coding the credentials, or committing them to a code repository. We recommend using a secret manager such as Google Cloud Secret manager or AWS Secret Manager when possible.
If your OAuth 2.0 client secrets are compromised, you can reset them. A developer token can also be reset.
Secure the developer token
The developer token lets you make API calls to an account, but has no restrictions on which accounts it can be used with to make the calls. As a result, a compromised developer token can be used by someone else to make calls that are attributed to your application. To avoid this scenario, take these preventive measures:
Treat your developer token like a password. Don't share it using insecure mechanisms such as posting on public forums or sending configuration files containing the developer tokens as an email attachment. We recommend using a secret manager such as Google Cloud Secret manager or AWS Secret Manager when possible.
If your developer token is compromised, you should reset it.
- Sign in to the Google Ads manager account that you used when applying for Google Ads API.
- Navigate to Tools & Settings > API Center.
- Click the drop-down arrow next to Developer token.
- Click the Reset token link. Your old developer token should stop working immediately.
- Update your application's production configuration to use the new developer token.
Secure the service accounts
Service accounts require domain-wide impersonation to work correctly with the Google Ads API, In addition, you should be a Google Workspace customer to set up domain-wide impersonation. For these reasons, we recommend against using service accounts when making Google Ads API calls. However, if you decide to use service accounts, you should secure them as follows:
Treat your service account key and JSON file as passwords. Secure them using a secret manager such as Google Cloud Secret manager or AWS Secret Manager when possible.
Follow the additional best practices from Google Cloud to secure and manage your service accounts.
Secure the user tokens
If your app authorizes multiple users, you should take additional steps to protect the users' refresh and access tokens. Store the tokens securely at rest and never transmit them in plain text. Use a secure storage system appropriate for your platform.
Handle refresh token revocation and expiration
If your app requests OAuth 2.0 refresh token as part of authorization, you must also handle their invalidation or expiration. Refresh tokens could be invalidated for various reasons, and your application should respond gracefully either by reauthorizing the user during their next login session, or cleaning up their data as appropriate. Offline jobs, such as cron jobs, should detect and record accounts whose refresh tokens have expired, instead of continuing to make failed requests. Google might throttle applications that generate high levels of errors over a sustained period of time to maintain the stability of the API servers.
Manage consent for multiple scopes
If your app requests authorization for multiple OAuth 2.0 scopes, the user might not grant all the OAuth scopes you've requested. Your app should handle the denial of scopes by disabling the relevant features. You can prompt the user again only after they've clearly indicated an intent to use the specific feature that requires the scope. Use incremental authorization to request appropriate OAuth scopes in such cases.
If your app's basic features require multiple scopes, explain this requirement to the user before prompting for consent.