تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يوضّح هذا الدليل كيفية التأكّد من أنّ تطبيقك وبيانات اعتماد المستخدمين آمنة.
إكمال عملية التحقّق من تطبيق OAuth
يتم تصنيف نطاق OAuth 2.0 لواجهة برمجة التطبيقات Google Ads API على أنّه نطاق محدود، ما يعني أنّه عليك إكمال عملية إثبات ملكية تطبيق OAuth قبل طرح تطبيقك في مرحلة الإنتاج. يمكنك الاطّلاع على مستندات "هوية Google" ومقالة "مركز المساعدة" لمعرفة المزيد.
تأمين بيانات اعتماد التطبيق
عليك تأمين معرّف عميل OAuth 2.0 وسر العميل الخاصين بتطبيقك.
تساعد بيانات الاعتماد هذه المستخدمين وGoogle في التعرّف على تطبيقك، لذا يجب التعامل معها بعناية. يجب التعامل مع بيانات اعتماد التطبيق هذه
مثل كلمات المرور. لا تشاركها باستخدام آليات غير آمنة، مثل نشرها في منتديات عامة أو إرسال ملفات الإعداد التي تحتوي على بيانات الاعتماد هذه في مرفقات البريد الإلكتروني أو ترميز بيانات الاعتماد بشكل ثابت أو إرسالها إلى مستودع رموز برمجية. ننصحك باستخدام خدمة إدارة الأسرار، مثل Google Cloud Secret Manager أو AWS Secret Manager، عند الإمكان.
في حال تعرُّض أسرار عميل OAuth 2.0 للاختراق، يمكنك إعادة ضبطها. يمكن أيضًا إعادة ضبط الرمز المميز للمطوّر.
تأمين الرمز المميز للمطوِّر
يتيح رمز المطوّر إجراء طلبات إلى واجهة برمجة التطبيقات للوصول إلى حساب، ولكن لا توجد قيود على الحسابات التي يمكن استخدامه معها لإجراء الطلبات. نتيجةً لذلك، يمكن لشخص آخر استخدام رمز مطوّر تم اختراقه لإجراء طلبات منسوبة إلى تطبيقك. لتجنُّب هذا السيناريو، اتّخِذ الإجراءات الوقائية التالية:
تعامَل مع الرمز المميز للمطوّر كما تتعامل مع كلمة المرور. يجب عدم مشاركتها باستخدام آليات غير آمنة، مثل نشرها في المنتديات العامة أو إرسال ملفات الإعدادات التي تحتوي على الرموز المميزة للمطوّرين كمرفق في رسالة إلكترونية. ننصحك باستخدام خدمة إدارة أسرار، مثل Google Cloud Secret Manager أو AWS Secret Manager، متى أمكن ذلك.
إذا تم اختراق الرمز المميّز للمطوّر، عليك إعادة ضبطه.
سجِّل الدخول إلى حسابك الإداري على "إعلانات Google" الذي استخدمته عند تقديم طلب للحصول على واجهة برمجة التطبيقات الخاصة بـ "إعلانات Google".
انتقِل إلى الأدوات والإعدادات > مركز واجهة برمجة التطبيقات.
انقر على السهم المنسدل بجانب الرمز المميز للمطوّر.
انقر على الرابط إعادة ضبط الرمز المميز. يجب أن يتوقف الرمز المميز القديم للمطوّر عن العمل فورًا.
عدِّل إعدادات الإنتاج في تطبيقك لاستخدام رمز المطوّر الجديد.
تأمين حسابات الخدمة
تتطلّب حسابات الخدمة انتحال هوية على مستوى النطاق لتعمل بشكل صحيح مع واجهة برمجة التطبيقات Google Ads API. بالإضافة إلى ذلك، يجب أن تكون عميلاً في Google Workspace لإعداد انتحال الهوية على مستوى النطاق. لهذه الأسباب، ننصح بعدم استخدام حسابات الخدمة عند إجراء طلبات إلى Google Ads API. ومع ذلك، إذا قررت استخدام حسابات الخدمة، عليك تأمينها باتّباع الخطوات التالية:
إذا كان تطبيقك يمنح الإذن لعدة مستخدمين، عليك اتّخاذ خطوات إضافية لحماية رموز التحديث والوصول الخاصة بالمستخدمين. يجب تخزين الرموز المميزة بشكل آمن في حالة عدم الاستخدام وعدم إرسالها مطلقًا كنص عادي. استخدِم نظام تخزين آمنًا
مناسبًا لمنصتك.
التعامل مع إبطال الرمز المميز لإعادة التحميل وانتهاء صلاحيته
إذا كان تطبيقك يطلب رمزًا مميزًا لإعادة تحميل OAuth 2.0 كجزء من عملية التفويض، عليك أيضًا التعامل مع حالات إبطاله أو انتهاء صلاحيته. يمكن إبطال رموز التحديث لأسباب مختلفة، ويجب أن يستجيب تطبيقك بشكل سليم إما عن طريق إعادة تفويض المستخدم أثناء جلسة تسجيل الدخول التالية، أو عن طريق تنظيف بياناته حسب الاقتضاء. يجب أن ترصد الوظائف غير المتصلة بالإنترنت، مثل وظائف cron، الحسابات التي انتهت صلاحية رموز التحديث الخاصة بها وتسجّلها، بدلاً من مواصلة تقديم طلبات غير ناجحة. قد تحدّ Google من سرعة التطبيقات التي تسجّل معدلات مرتفعة من الأخطاء على مدار فترة زمنية متواصلة للحفاظ على استقرار خوادم واجهة برمجة التطبيقات.
إدارة الموافقة لنطاقات متعدّدة
إذا كان تطبيقك يطلب الحصول على إذن بالوصول إلى نطاقات متعدّدة من OAuth 2.0، قد لا يمنح المستخدم جميع نطاقات OAuth التي طلبتها. يجب أن يتعامل تطبيقك مع رفض النطاقات من خلال إيقاف الميزات ذات الصلة. يمكنك أن تطلب من المستخدم
الموافقة مرة أخرى فقط بعد أن يوضّح نيته استخدام الميزة المحدّدة
التي تتطلّب النطاق. استخدِم المصادقة المتزايدة لطلب نطاقات OAuth المناسبة في مثل هذه الحالات.
إذا كانت الميزات الأساسية لتطبيقك تتطلّب نطاقات متعدّدة، عليك توضيح هذا الشرط للمستخدم قبل طلب الموافقة.
تاريخ التعديل الأخير: 2025-08-31 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-31 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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."]]
