يلخّص الجدول التالي بيانات الاعتماد التي يجب أن يديرها التطبيق. لمزيد من المعلومات عن أنواع التطبيقات، يُرجى الاطّلاع على مستندات بروتوكول OAuth 2.0 من Google Identity.
| سير عمل المصادقة | بيانات الاعتماد | نوع بيانات الاعتماد | الغرض |
|---|---|---|---|
|
تطبيقات الويب المستندة إلى JavaScript تطبيقات Android |
معرِّف عميل OAuth | بيانات اعتماد التطبيق | يحدّد التطبيق بشكلٍ فريد أثناء مسار OAuth. |
| رمز الدخول والرمز المميز لإعادة التحميل | بيانات اعتماد المستخدم | تمثّل إذن المستخدم للسماح للتطبيق بالوصول إلى حسابه على "إعلانات Google" نيابةً عنه. | |
|
تطبيقات الويب من جهة الخادم تطبيقات أجهزة الكمبيوتر وتطبيقات iOS تطبيقات أجهزة التلفزيون والأجهزة الأخرى |
معرِّف عميل OAuth وسرّ العميل | بيانات اعتماد التطبيق | يحدّد التطبيق بشكلٍ فريد أثناء مسار OAuth. |
| رمز الدخول والرمز المميز لإعادة التحميل | بيانات اعتماد المستخدم | تمثّل إذن المستخدم للسماح للتطبيق بالوصول إلى حسابه على "إعلانات Google" نيابةً عنه. | |
| حسابات الخدمة | مفتاح حساب خدمة OAuth | بيانات اعتماد التطبيق | يُستخدَم لتوقيع طلب OAuth. |
| رمز الدخول لحساب الخدمة | بيانات اعتماد المستخدم | تمثّل إذن حساب الخدمة عندما يشارك المستخدم حسابه على "إعلانات Google" مع حساب الخدمة. |
هناك عدة نقاط يجب أخذها في الاعتبار عند إدارة بيانات اعتماد تطبيق Google Ads API.
التعامل مع بيانات اعتماد التطبيق بأمان
تشير بيانات اعتماد التطبيق إلى الإعدادات الخاصة بتطبيقك والتي لا تختلف من مستخدم إلى آخر. يجب التعامل مع بيانات اعتماد تطبيق OAuth بعناية فائقة، لأنّها تسمح لأي شخص يملكها باستخدام هوية تطبيقك للوصول إلى معلومات المستخدم. يجب تخزين بيانات اعتماد تطبيق OAuth في مكان آمن وحمايتها، تمامًا كما تفعل مع كلمة المرور. يُرجى استخدام مدير كلمات المرور، مثل Google Cloud Secret Manager، لتخزين بيانات اعتماد التطبيق حيثما أمكن ذلك. يجب عدم تضمين بيانات اعتماد العميل في مستودعات الرموز البرمجية المتاحة للجميع. ننصحك بشدة بتجنُّب تضمينها في أي مستودع للرموز البرمجية.
التعامل مع بيانات اعتماد المستخدم بأمان
تشير بيانات اعتماد المستخدم إلى رموز OAuth المميزة التي تمثّل إذن المستخدم. يمنحك المستخدمون هذه البيانات عندما يمنحونك الإذن بالتصرّف والوصول إلى البيانات نيابةً عنهم، إما مباشرةً من خلال المصادقة على تطبيقك، أو بشكلٍ غير مباشر من خلال مشاركة حسابهم على "إعلانات Google" مع حساب الخدمة. يجب عدم نقل الرموز المميزة بنص عادي، وتخزين الرموز المميزة المشفرة دائمًا في حالة عدم النشاط لتوفير طبقة حماية إضافية في حال حدوث خرق للبيانات. يجب إبطال الرموز المميزة أو أذونات حساب الخدمة عندما لا يعود الوصول إلى حساب المستخدم ضروريًا. بعد إبطال الرموز المميزة، يجب حذفها نهائيًا من تطبيقك أو نظامك.
التعامل مع إبطال الرموز المميزة لإعادة التحميل وانتهاء صلاحيتها
إذا كنت تستخدم سير عمل لمصادقة المستخدم، يُرجى العِلم أنّه يمكن إبطال الرموز المميزة لإعادة التحميل في أي وقت. على سبيل المثال، إذا كنت تستخدم سير عمل للمصادقة المتعددة المستخدمين، يمكن للمستخدم اختيار إبطال إذن الوصول إلى تطبيقك. على الرغم من أنّ التطبيق الذي يستخدم سير عمل للمصادقة لمستخدم واحد أقل عرضةً للتأثّر بهذه الطريقة، يمكن أن يؤدي إجراء يدوي أو آلي مصمّم لحماية المستخدمين إلى الإزالة نهائيًّا الرمز المميز لإعادة التحميل أو انتهاء صلاحيته. إذا كان تطبيقك يتطلّب إشعارًا بإبطال الرمز المميز لتقديم تجربة جيدة للمستخدمين، يجب إجراء التكامل مع خدمة حماية عابرة للحساب.
إعادة استخدام بيانات اعتماد المستخدم في طلبات بيانات من واجهة برمجة التطبيقات
تكون رموز الدخول عبر OAuth قصيرة الأجل وتنتهي صلاحيتها بعد ساعة واحدة. إذا كنت تستخدم مكتبة برامج عميل Google Ads API، تتولّى المكتبة التعامل مع انتهاء صلاحية رموز الدخول وإعادة تحميلها بطريقة آمنة في سلاسل المحادثات. يجب إنشاء عنصر عميل Google Ads API باستخدام بيانات اعتماد OAuth المناسبة وإعادة استخدامه طوال مدة صلاحيته.
إذا كنت تنشئ استراتيجية خاصة بك لإعادة تحميل رموز الدخول وإدارتها، يجب تتبُّع انتهاء صلاحية رموز الدخول وإعادة استخدامها طالما أنّها لا تزال صالحة. عند طلب إعادة تحميل رمز مميز، يعرض خادم التفويض رمز دخول جديدًا
بالإضافة إلى مدة الصلاحية المتبقية بالثواني
(expires_in). ننصحك بإعادة تحميل رمز الدخول بشكل استباقي إذا كانت المدة المتبقية قبل انتهاء الصلاحية أقل من 5 دقائق.