با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
این راهنما نشان می دهد که چگونه می توانید از ایمن بودن برنامه و اعتبار کاربری خود مطمئن شوید.
تأیید برنامه OAuth را تکمیل کنید
محدوده OAuth 2.0 برای Google Ads API به عنوان یک محدوده محدود طبقه بندی می شود، به این معنی که باید قبل از تولید برنامه خود، فرآیند تأیید برنامه OAuth را تکمیل کنید. برای کسب اطلاعات بیشتر به مقاله مستندات هویت Google و مرکز راهنمایی مراجعه کنید.
اعتبارنامه برنامه را ایمن کنید
شما باید شناسه مشتری OAuth 2.0 و راز سرویس گیرنده برنامه خود را ایمن کنید. این اعتبارنامه ها به کاربران شما و گوگل کمک می کند تا برنامه شما را شناسایی کنند و بنابراین باید با دقت به آنها رسیدگی شود. شما باید با این اعتبار برنامه ها مانند رمز عبور رفتار کنید. آنها را با استفاده از مکانیسم‌های ناامن مانند ارسال در انجمن‌های عمومی، ارسال فایل‌های پیکربندی حاوی این اعتبارنامه‌ها در پیوست‌های ایمیل، کدگذاری سخت اعتبارنامه‌ها یا تعهد آنها به مخزن کد، به اشتراک نگذارید. توصیه می‌کنیم در صورت امکان از یک مدیر مخفی مانند Google Cloud Secret یا AWS Secret Manager استفاده کنید.
اگر اسرار سرویس گیرنده OAuth 2.0 شما به خطر افتاده است، می توانید آنها را بازنشانی کنید . یک توکن توسعه دهنده نیز می تواند بازنشانی شود.
توکن توسعه دهنده را ایمن کنید
توکن توسعه‌دهنده به شما امکان می‌دهد با یک حساب API تماس برقرار کنید، اما هیچ محدودیتی در مورد استفاده از آن برای برقراری تماس‌ها ندارد. در نتیجه، یک توکن توسعه‌دهنده به خطر افتاده می‌تواند توسط شخص دیگری برای برقراری تماس‌هایی که به برنامه شما نسبت داده می‌شوند استفاده شود. برای جلوگیری از این سناریو، اقدامات پیشگیرانه زیر را انجام دهید:
با توکن توسعه دهنده خود مانند یک رمز عبور رفتار کنید. با استفاده از مکانیسم‌های ناامن مانند ارسال در انجمن‌های عمومی یا ارسال فایل‌های پیکربندی حاوی نشانه‌های توسعه‌دهنده به‌عنوان پیوست ایمیل، آن را به اشتراک نگذارید. توصیه می‌کنیم در صورت امکان از یک مدیر مخفی مانند Google Cloud Secret یا AWS Secret Manager استفاده کنید.
اگر توکن توسعه دهنده شما به خطر افتاده است، باید آن را بازنشانی کنید.
وارد حساب مدیر Google Ads شوید که هنگام درخواست برای Google Ads API از آن استفاده کردید.
به Tools & Settings > API Center بروید.
روی پیکان کشویی کنار نشانه برنامه‌نویس کلیک کنید.
روی پیوند Reset Token کلیک کنید. توکن توسعه دهنده قدیمی شما باید فوراً از کار بیفتد.
پیکربندی تولید برنامه خود را برای استفاده از توکن توسعه دهنده جدید به روز کنید.
حساب های سرویس را ایمن کنید
حساب‌های سرویس برای کارکرد صحیح با Google Ads API به جعل هویت در سراسر دامنه نیاز دارند، علاوه بر این، برای راه‌اندازی جعل هویت در سراسر دامنه، باید مشتری Google Workspace باشید. به این دلایل، توصیه می‌کنیم هنگام برقراری تماس‌های Google Ads API از حساب‌های سرویس استفاده نکنید. با این حال، اگر تصمیم به استفاده از حساب های خدماتی دارید، باید آنها را به شرح زیر ایمن کنید:
کلید حساب سرویس و فایل JSON خود را به عنوان رمز عبور در نظر بگیرید. در صورت امکان با استفاده از یک مدیر مخفی مانند Google Cloud Secret یا AWS Secret Manager آنها را ایمن کنید.
برای ایمن سازی و مدیریت حساب های خدمات خود ، بهترین روش های اضافی Google Cloud را دنبال کنید.
توکن های کاربر را ایمن کنید
اگر برنامه شما به چندین کاربر مجوز می دهد، باید اقدامات بیشتری را برای محافظت از نشانه های تازه سازی و دسترسی کاربران انجام دهید. توکن ها را به صورت ایمن در حالت استراحت ذخیره کنید و هرگز آنها را به صورت متن ساده ارسال نکنید. از یک سیستم ذخیره سازی ایمن مناسب برای پلتفرم خود استفاده کنید.
ابطال و انقضای نشانه رفرش را مدیریت کنید
اگر برنامه شما کد بازخوانی OAuth 2.0 را به عنوان بخشی از مجوز درخواست می‌کند، باید ابطال یا انقضای آن را نیز رسیدگی کنید. نشانه‌های Refresh ممکن است به دلایل مختلف باطل شوند، و برنامه شما باید با احراز مجوز مجدد کاربر در جلسه بعدی ورود به سیستم، یا پاک کردن داده‌های او در صورت لزوم، به خوبی پاسخ دهد. کارهای آفلاین، مانند cron jobs، به جای ادامه دادن درخواست های ناموفق، باید حساب هایی را شناسایی و ثبت کنند که توکن های تازه سازی آنها منقضی شده است. Google ممکن است برنامه‌هایی را که سطوح بالایی از خطا ایجاد می‌کنند را در یک دوره زمانی طولانی متوقف کند تا پایداری سرورهای API را حفظ کند.
رضایت را برای حوزه های متعدد مدیریت کنید
اگر برنامه شما برای چندین حوزه OAuth 2.0 مجوز درخواست می‌کند، ممکن است کاربر تمام محدوده‌های OAuth را که درخواست کرده‌اید اعطا نکند. برنامه شما باید با غیرفعال کردن ویژگی‌های مربوطه، انکار دامنه‌ها را کنترل کند. فقط پس از اینکه کاربر به وضوح قصد استفاده از ویژگی خاصی را که به محدوده نیاز دارد، اشاره کرد، می‌توانید دوباره از او درخواست کنید. از مجوز افزایشی برای درخواست دامنه های OAuth مناسب در چنین مواردی استفاده کنید.
اگر ویژگی‌های اساسی برنامه شما به چندین حوزه نیاز دارد، قبل از درخواست رضایت، این الزام را برای کاربر توضیح دهید.
تاریخ آخرین بهروزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی."],[[["\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."]]
