تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يوضّح هذا الدليل كيفية التأكّد من أمان تطبيقك وبيانات اعتماد المستخدمين.
إكمال عملية التحقّق من تطبيق OAuth
يتم تصنيف نطاق OAuth 2.0 لواجهة برمجة التطبيقات "إعلانات Google" على أنّه نطاق محظور، ما يعني أنّه عليك إكمال عملية إثبات ملكية تطبيق OAuth قبل طرح تطبيقك للجمهور. يُرجى الاطّلاع على مستندات "هوية Google" ومقالة مركز المساعدة لمزيد من المعلومات.
تأمين بيانات اعتماد التطبيق
عليك تأمين معرّف عميل OAuth 2.0 وسر العميل لتطبيقك. تساعد بيانات الاعتماد هذه المستخدمين وGoogle في التعرّف على تطبيقك، وبالتالي يجب التعامل معها بحرص. يجب التعامل مع بيانات اعتماد التطبيق هذه مثل كلمات المرور. لا تشاركها باستخدام آليات غير آمنة، مثل نشرها على forums علني أو إرسال ملفات الضبط التي تحتوي على بيانات الاعتماد هذه في مرفقات البريد الإلكتروني أو الترميز الثابت لبيانات الاعتماد أو إرسالها إلى مستودع رمز برمجي. ننصحك باستخدام أداة إدارة مفاتيح المرور، مثل أداة إدارة مفاتيح المرور في Google Cloud أو AWS Secret Manager كلما أمكن ذلك.
إذا تم اختراق أسرار عملاء بروتوكول OAuth 2.0، يمكنك إعادة ضبطها. يمكن أيضًا إعادة ضبط رمز المطوّر.
تأمين الرمز المميّز للمطوّر
يتيح لك رمز المطوّر طلب بيانات من واجهة برمجة التطبيقات للوصول إلى حساب، ولكن ليس له قيود على الحسابات التي يمكن استخدامه معها لإجراء عمليات الطلب. نتيجةً لذلك، يمكن لشخص آخر استخدام رمز مطوِّر تم اختراقه لإجراء مكالمات تُنسب إلى تطبيقك. لتجنُّب هذا السيناريو، اتّبِع الخطوات التالية:
تعامل مع الرمز المميّز للمطوّر كما تتعامل مع كلمة المرور. لا تشاركها باستخدام أنظمة غير آمنة، مثل نشرها على المنتديات العامة أو إرسال ملفات الضبط التي تحتوي على الرموز المميّزة للمطوّرين كمرفق في رسالة إلكترونية. ننصحك باستخدام أداة إدارة السِرّ مثل أداة إدارة السِرّ في Google Cloud أو أداة إدارة السِرّ في AWS كلما أمكن ذلك.
إذا تعرّض رمز المطوِّر المميّز للاختراق، عليك إعادة ضبطه.
سجِّل الدخول إلى الحساب الإداري على "إعلانات Google" الذي استخدمته عند التقدّم بطلب للحصول على إذن بالوصول إلى واجهة برمجة التطبيقات Google Ads API.
انتقِل إلى الأدوات والإعدادات > مركز واجهة برمجة التطبيقات.
انقر على السهم المنسدل بجانب رمز المطوِّر.
انقر على الرابط إعادة ضبط الرمز المميّز. من المفترض أن يتوقف رمز المطوِّر القديم عن العمل على الفور.
عدِّل إعدادات الإصدار العلني لتطبيقك لاستخدام رمز مطوّر التطبيقات الجديد.
تأمين حسابات الخدمة
تتطلّب حسابات الخدمة انتحال الهوية على مستوى النطاق لكي تعمل بشكل صحيح مع واجهة برمجة التطبيقات Google Ads API. بالإضافة إلى ذلك، يجب أن تكون عميلًا في Google Workspace لإعداد انتحال الهوية على مستوى النطاق. لهذه الأسباب، لا ننصحك باستخدام حسابات الخدمة عند إجراء طلبات إلى Google Ads API. ومع ذلك، إذا قرّرت استخدام حسابات الخدمة، عليك تأمينها على النحو التالي:
إذا كان تطبيقك يمنح أذونات لمستخدمين متعدّدين، عليك اتّخاذ خطوات إضافية ل حماية رموز إعادة التحميل ووصول المستخدمين. تخزِّن الرموز المميّزة بأمان في حالة عدم استخدامها ولا ترسلها مطلقًا كنص عادي. استخدِم نظام تخزين آمنًا مناسبًا لمنصتك.
التعامل مع إبطال الرمز المميّز لإعادة التحميل وانتهاء صلاحيته
إذا كان تطبيقك يطلب رمز إعادة تحميل OAuth 2.0 كجزء من التفويض، يجب أيضًا التعامل مع إبطاله أو انتهاء صلاحيته. يمكن أن يتم إبطال صحة علامات إعادة التنشيط لأسباب مختلفة، ويجب أن يستجيب تطبيقك بطريقة سلسة إما من خلال إعادة تفويض المستخدم خلال جلسة تسجيل الدخول التالية أو محو بياناته حسب الاقتضاء. يجب أن ترصد المهام بلا إنترنت، مثل مهام cron، وتسجيل الحسابات التي انتهت صلاحية رموزها المميزة للتحديث، بدلاً من مواصلة إرسال طلبات تعذّر إكمالها. قد تفرض Google قيودًا على التطبيقات التي تؤدي إلى توليد مستويات عالية من الأخطاء على مدار فترة زمنية متواصلة للحفاظ على استقرار خوادم واجهة برمجة التطبيقات.
إدارة الموافقة على نطاقات متعددة
إذا طلب تطبيقك تفويضًا لنطاقات متعددة في OAuth 2.0، قد يرفض المستخدم منح كل نطاقات OAuth التي طلبتها. يجب أن يتعامل تطبيقك مع رفض النطاقات من خلال إيقاف الميزات ذات الصلة. لا يمكنك مطالبة المستخدم مجددًا بالموافقة إلا بعد أن يشير بوضوح إلى رغبته في استخدام الميزة المحدّدة التي تتطلّب النطاق. استخدِم المصادقة المتزايدة لطلب نطاقات OAuth المناسبة في هذه الحالات.
إذا كانت الميزات الأساسية لتطبيقك تتطلّب نطاقات متعددة، يجب شرح هذا الشرط للمستخدم قبل طلب الموافقة.
تاريخ التعديل الأخير: 2025-08-21 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-08-21 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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,["This guide shows how to make sure your application and user credentials are\nsecure.\n\nComplete the OAuth App verification\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\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 **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\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\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\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\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."]]
