يوضّح هذا الدليل كيفية التأكّد من أمان تطبيقك وبيانات اعتماد المستخدمين.
إكمال عملية التحقّق من تطبيق OAuth
يتم تصنيف نطاق OAuth 2.0 لواجهة Google Ads API على أنّه نطاق محظور، ما يعني أنّه عليك إكمال عملية إثبات ملكية تطبيق OAuth قبل طرح تطبيقك في مرحلة الإنتاج. لمزيد من المعلومات، يُرجى الاطّلاع على مستندات Google Identity ومقالة مركز المساعدة حول التطبيقات التي لم يتم التحقّق منها والمستندات حول إعداد شاشة طلب الموافقة على OAuth.
تأمين بيانات اعتماد التطبيق
عليك تأمين معرّف عميل OAuth 2.0 وسر العميل الخاصين بتطبيقك. تساعد بيانات الاعتماد هذه المستخدمين وGoogle في التعرّف على تطبيقك، لذا يجب التعامل معها بعناية. يجب التعامل مع بيانات اعتماد التطبيق هذه كما لو كانت كلمات مرور. ويجب عدم مشاركتها باستخدام آليات غير آمنة، مثل نشرها في المنتديات العامة أو إرسال ملفات الإعداد التي تحتوي على بيانات الاعتماد هذه في مرفقات البريد الإلكتروني أو ترميز بيانات الاعتماد بشكل ثابت أو إرسالها إلى مستودع الرموز البرمجية. ننصحك باستخدام خدمة إدارة المفاتيح السرية، مثل Google Cloud Secret Manager أو AWS Secret Manager، عند الإمكان.
في حال تم اختراق أسرار عميل OAuth 2.0، يمكنك إعادة ضبطها. يمكن أيضًا إعادة ضبط الرمز المميز للمطوّر.
تأمين الرمز المميز للمطوِّر
يتيح لك الرمز المميز للمطوّر إجراء طلبات بيانات من واجهة برمجة التطبيقات إلى حساب، ولكن لا توجد قيود على الحسابات التي يمكن استخدامه معها لإجراء الطلبات. نتيجةً لذلك، يمكن لشخص آخر استخدام الرمز المميز للمطوِّر الذي تم اختراقه لإجراء مكالمات يتم نسبها إلى تطبيقك. لتجنُّب هذا السيناريو، اتّخِذ الإجراءات الوقائية التالية:
تعامَل مع الرمز المميز للمطوّر كما تتعامل مع كلمة المرور. ويجب عدم مشاركتها باستخدام آليات غير آمنة، مثل نشرها في المنتديات العامة أو إرسال ملفات الإعدادات التي تحتوي على الرموز المميزة للمطوّرين كمرفق في رسالة إلكترونية. ننصحك باستخدام خدمة إدارة المفاتيح السرية، مثل Google Cloud Secret Manager أو AWS Secret Manager، متى أمكن ذلك.
إذا تم اختراق الرمز المميّز للمطوّر، عليك إعادة ضبطه.
- سجِّل الدخول إلى حسابك الإداري على "إعلانات Google" الذي استخدمته عند تقديم طلب للحصول على واجهة برمجة التطبيقات Google Ads API.
- انتقِل إلى الأدوات والإعدادات > مركز واجهة برمجة التطبيقات.
- انقر على السهم المنسدل بجانب الرمز المميز للمطوّر.
- انقر على الرابط إعادة ضبط الرمز المميز. يجب أن يتوقف الرمز المميّز القديم للمطوّر عن العمل على الفور.
- عدِّل إعدادات الإنتاج في تطبيقك لاستخدام الرمز المميز للمطوِّر الجديد.
تأمين حسابات الخدمة
إذا كنت تستخدم حسابات الخدمة، عليك تأمينها باتّباع الخطوات التالية:
- تعامَل مع مفتاح حساب الخدمة وملف JSON على أنّهما كلمات مرور. يمكنك تأمينها باستخدام خدمة إدارة المفاتيح السرية، مثل Google Cloud Secret Manager أو AWS Secret Manager، عند الإمكان.
- اتّبِع أفضل الممارسات الإضافية من Google Cloud لتأمين حسابات الخدمة وإدارتها.
تأمين الرموز المميزة للمستخدمين
إذا كان تطبيقك يمنح الإذن لعدة مستخدمين، عليك اتّخاذ خطوات إضافية لحماية رموز التحديث ورموز الدخول الخاصة بالمستخدمين. يجب تخزين الرموز المميّزة بشكل آمن في حالة عدم الاستخدام وعدم إرسالها مطلقًا كنص عادي. استخدِم نظام تخزين آمنًا مناسبًا لمنصتك.
التعامل مع إبطال الرمز المميز لإعادة التحميل وانتهاء صلاحيته
إذا كان تطبيقك يطلب رمز OAuth 2.0 المميز لإعادة التحميل كجزء من عملية التفويض، عليك أيضًا التعامل مع إبطاله أو انتهاء صلاحيته. يمكن إبطال رموز التحديث لأسباب مختلفة، ويجب أن يستجيب تطبيقك بشكل سليم إما عن طريق إعادة تفويض المستخدم أثناء جلسة تسجيل الدخول التالية، أو عن طريق تنظيف بياناته حسب الاقتضاء. يجب أن ترصد المهام غير المتصلة بالإنترنت، مثل مهام cron، الحسابات التي انتهت صلاحية رموز التحديث الخاصة بها وتسجّلها، بدلاً من مواصلة تقديم طلبات غير ناجحة. قد تحدّ Google من التطبيقات التي تُصدر عددًا كبيرًا من الأخطاء على مدار فترة زمنية طويلة للحفاظ على استقرار خوادم واجهة برمجة التطبيقات.
إدارة الموافقة لنطاقات متعددة
إذا كان تطبيقك يطلب الحصول على إذن بالوصول إلى نطاقات متعدّدة من OAuth 2.0، قد لا يمنح المستخدم جميع نطاقات OAuth التي طلبتها. يجب أن يتعامل تطبيقك مع رفض النطاقات من خلال إيقاف الميزات ذات الصلة. لا يمكنك أن تطلب من المستخدم الموافقة مرة أخرى إلا بعد أن يوضّح نيته استخدام الميزة المحدّدة التي تتطلّب النطاق. استخدِم المصادقة المتزايدة لطلب نطاقات OAuth المناسبة في مثل هذه الحالات.
إذا كانت الميزات الأساسية لتطبيقك تتطلّب نطاقات متعددة، عليك توضيح هذا الشرط للمستخدم قبل طلب الموافقة.