หากต้องการพูดคุยและแสดงความคิดเห็นเกี่ยวกับผลิตภัณฑ์ของเรา โปรดเข้าร่วมช่อง Discord อย่างเป็นทางการของ Google Ads ในเซิร์ฟเวอร์ชุมชนการโฆษณาและการวัดผลของ Google
บัญชีบริการต้องมีการแอบอ้างเป็นผู้ใช้ทั้งโดเมนเพื่อให้ทำงานร่วมกับ Google Ads API ได้อย่างถูกต้อง นอกจากนี้ คุณควรเป็นลูกค้า Google Workspace เพื่อตั้งค่าการแอบอ้างเป็นผู้ใช้ทั้งโดเมน ด้วยเหตุนี้ เราจึงไม่แนะนำให้ใช้บัญชีบริการ
เมื่อทำการเรียก Google Ads API อย่างไรก็ตาม หากตัดสินใจใช้บัญชีบริการ คุณควรรักษาความปลอดภัยของบัญชีดังกล่าวดังนี้
[null,null,["อัปเดตล่าสุด 2025-08-31 UTC"],[[["\u003cp\u003eThis guide provides instructions for securing your application and user credentials when using the Google Ads API.\u003c/p\u003e\n"],["\u003cp\u003eSecure your application credentials, including OAuth 2.0 client ID and client secret, by treating them like passwords and utilizing secret management tools.\u003c/p\u003e\n"],["\u003cp\u003eProtect your developer token by storing it securely and resetting it if compromised, and consider transitioning to Cloud organizations for access management.\u003c/p\u003e\n"],["\u003cp\u003eSecure user tokens, especially refresh and access tokens, using secure storage and implement mechanisms for handling token revocation and expiration.\u003c/p\u003e\n"],["\u003cp\u003eIf requesting multiple OAuth 2.0 scopes, manage user consent effectively and gracefully handle scope denials by disabling relevant features or using incremental authorization.\u003c/p\u003e\n"]]],[],null,["# Secure your credentials\n\nThis guide shows how to make sure your application and user credentials are\nsecure.\n\nComplete the OAuth App verification\n-----------------------------------\n\nThe OAuth 2.0 scope for the Google Ads API is classified as a\n[restricted scope](/identity/protocols/oauth2/production-readiness/restricted-scope-verification), which means that you should complete the OAuth\napplication verification process before productionizing your application. See\nthe [Google Identity documentation](/identity/protocols/oauth2/production-readiness/restricted-scope-verification) and [Help Center article](//support.google.com/cloud/answer/9110914) to\nlearn more.\n\nSecure the application credentials\n----------------------------------\n\nYou should secure your application's OAuth 2.0 client ID, and client secret.\nThese credentials help your users and Google identify your application and thus\nthey should be handled carefully. You should treat these application credentials\nlike passwords. Don't share them using insecure mechanisms such as posting on\npublic forums, sending configuration files containing these credentials in email\nattachments, hard coding the credentials, or committing them to a code\nrepository. We recommend using a secret manager such as [Google Cloud Secret\nmanager](//cloud.google.com/secret-manager) or [AWS Secret Manager](//aws.amazon.com/secrets-manager/) when possible.\n\nIf your OAuth 2.0 client secrets are compromised, you can [reset them](//support.google.com/cloud/answer/6158849#rotate-client-secret). A\ndeveloper token can also be [reset](/google-ads/api/docs/productionize/secure-credentials#secure_the_developer_token).\n\nSecure the developer token\n--------------------------\n\n| **Note:** Google is accepting early sign-ups for a program that uses Cloud organizations instead of developer tokens to manage access levels. [Learn\n| more](//support.google.com/cloud/answer/6158849#rotate-client-secret).\n\nThe developer token lets you make API calls to an account, but has no\nrestrictions on which accounts it can be used with to make the calls. As a\nresult, a compromised developer token can be used by someone else to make calls\nthat are attributed to your application. To avoid this scenario, take these\npreventive measures:\n\n- Treat your developer token like a password. Don't share it using insecure\n mechanisms such as posting on public forums or sending configuration files\n containing the developer tokens as an email attachment. We recommend using a\n secret manager such as [Google Cloud Secret manager](//cloud.google.com/secret-manager) or [AWS Secret\n Manager](//aws.amazon.com/secrets-manager/) when possible.\n\n- If your developer token is compromised, you should reset it.\n\n - Sign in to the Google Ads manager account that you used when applying for Google Ads API.\n - Navigate to **Tools \\& Settings \\\u003e API Center**.\n - Click the drop-down arrow next to **Developer token**.\n - Click the **Reset token** link. Your old developer token should stop working immediately.\n - Update your application's production configuration to use the new developer token.\n\nSecure the service accounts\n---------------------------\n\nService accounts require domain-wide impersonation to work correctly with the\nGoogle Ads API, In addition, you should be a Google Workspace customer to set up\ndomain-wide impersonation. For these reasons, we recommend against using service\naccounts when making Google Ads API calls. However, if you decide to use service\naccounts, you should secure them as follows:\n\n- Treat your service account key and JSON file as passwords. Secure them using\n a secret manager such as [Google Cloud Secret manager](//cloud.google.com/secret-manager) or [AWS Secret\n Manager](//aws.amazon.com/secrets-manager/) when possible.\n\n- Follow the [additional best practices](//cloud.google.com/iam/docs/best-practices-service-accounts) from Google Cloud to secure\n and manage your service accounts.\n\nSecure the user tokens\n----------------------\n\nIf your app authorizes multiple users, you should take additional steps to\nprotect the users' refresh and access tokens. Store the tokens securely [at\nrest](//wikipedia.org/wiki/Data_at_rest) and never transmit them in plain text. Use a secure storage system\nappropriate for your platform.\n\nHandle refresh token revocation and expiration\n----------------------------------------------\n\nIf your app requests OAuth 2.0 refresh token as part of authorization, you must\nalso handle their invalidation or expiration. Refresh tokens could be\n[invalidated for various reasons](/identity/protocols/oauth2#expiration), and your application should respond\ngracefully either by reauthorizing the user during their next login session, or\ncleaning up their data as appropriate. Offline jobs, such as cron jobs, should\ndetect and record accounts whose refresh tokens have expired, instead of\ncontinuing to make failed requests. Google might throttle applications that\ngenerate high levels of errors over a sustained period of time to maintain the\nstability of the API servers.\n\nManage consent for multiple scopes\n----------------------------------\n\nIf your app requests authorization for multiple OAuth 2.0 scopes, the user might\nnot grant all the OAuth scopes you've requested. Your app should handle the\ndenial of scopes by disabling the relevant features. You can prompt the user\nagain only after they've clearly indicated an intent to use the specific feature\nthat requires the scope. Use [incremental authorization](/identity/protocols/oauth2/web-server#incrementalAuth) to request\nappropriate OAuth scopes in such cases.\n\nIf your app's basic features require multiple scopes, explain this requirement\nto the user before prompting for consent."]]
