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](https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification), which means that you should
complete the OAuth app verification process before productionizing your
application. See the
[Google Identity documentation](https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification), [Help Center
article on unverified apps](https://support.google.com/cloud/answer/9110914), and docs on [setting up OAuth
consent screen](https://support.google.com/cloud/answer/10311615) 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](https://cloud.google.com/secret-manager) or [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) when
possible.

If your OAuth 2.0 client secrets are compromised, you can
[reset them](https://support.google.com/cloud/answer/6158849#rotate-client-secret).

## Secure the service accounts

If you use service accounts, 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](https://cloud.google.com/secret-manager)
  or [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) when possible.

- Follow the [additional best practices](https://cloud.google.com/iam/docs/best-practices-service-accounts) 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](https://en.wikipedia.org/wiki/Data_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 an OAuth 2.0 refresh token as part of authorization, you
must also handle its invalidation or expiration. Refresh tokens could be
[invalidated for various reasons](https://developers.google.com/identity/protocols/oauth2#expiration), 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](https://developers.google.com/identity/protocols/oauth2/web-server#incrementalAuth) 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.