أفضل الممارسات

التعامل مع بيانات اعتماد العميل بأمان

تحدِّد بيانات اعتماد عميل OAuth هوية تطبيقك، ويجب التعامل معها بعناية. تخزين بيانات الاعتماد هذه في مساحة تخزين آمنة فقط، على سبيل المثال باستخدام أداة إدارة الأسرار مثل Google Cloud Secret Manager لا تُدرج بيانات الاعتماد في الرمز البرمجي ولا تُرسِلها إلى مستودع رموز أو تنشرها علنًا.

التعامل مع الرموز المميّزة للمستخدمين بأمان

تشمل الرموز المميّزة للمستخدمين كلّ من الرموز المميّزة لإعادة التحميل والرموز المميّزة للوصول التي يستخدمها تطبيقك. تخزين الرموز المميّزة بأمان في وضع عدم الاتّصال بالإنترنت وعدم إرسالها مطلقًا كنص عادي استخدِم نظام تخزين آمنًا مناسبًا للنظام الأساسي، مثل Keystore على Android، أو Keychain Services على iOS وmacOS، أو Credential Locker على Windows.

إبطال الرموز المميّزة فور عدم الحاجة إليها وحذفها نهائيًا من أنظمتك

بالإضافة إلى ذلك، ننصحك باتّباع أفضل الممارسات التالية في منصتك:

• بالنسبة إلى التطبيقات التي تعمل من جهة الخادم وتخزِّن الرموز المميّزة للعديد من المستخدمين، يجب تشفيرها في وضع عدم الاتّصال بالإنترنت والتأكّد من أنّه لا يمكن للجميع الوصول إلى قاعدة بياناتك.
• بالنسبة إلى تطبيقات سطح المكتب الأصلية، ننصح بشدة باستخدام بروتوكول مفتاح الحماية لتبادل الرموز (PKCE) للحصول على رموز التفويض التي يمكن تبديلها برموز الوصول.

التعامل مع إبطال الرمز المميّز لإعادة التحميل وانتهاء صلاحيته

إذا طلب تطبيقك رمزًا مميزًا لإعادة التحديث للوصول بلا إنترنت، عليك أيضًا معالجة حالات إبطاله أو انتهاء صلاحيته. يمكن أن يتم إبطال صحة الرموز المميّزة لأسباب مختلفة، مثلاً بسبب انتهاء صلاحيتها أو إذا أبطل المستخدم أو عملية مبرمَجة إذن وصول تطبيقاتك إليها. في هذه الحالة، يجب التفكير بعناية في كيفية استجابة تطبيقك، بما في ذلك مطالبة المستخدم بتنظيف بياناته عند تسجيل الدخول التالي. لتلقّي إشعارات بشأن إبطال الرمز المميّز، يمكنك الدمج مع خدمة الحماية العابرة للحساب.

استخدام التفويض المتزايد

استخدِم التفويض المتصاعدلطلب نطاقات OAuth المناسبة عندما يحتاج تطبيقك إلى الوظيفة.

يجب عدم طلب الوصول إلى البيانات عند مصادقة المستخدم لأول مرة، ما لم يكن ذلك ضروريًا للوظائف الأساسية لتطبيقك. بدلاً من ذلك، اطلب النطاقات المحدّدة فقط التي تحتاج إليها لمهمة معيّنة، مع اتّباع مبدأ اختيار النطاقات الأصغر حجمًا والأكثر تقييدًا.

اطلب النطاقات دائمًا في سياق استخدامها لمساعدة المستخدمين في فهم سبب طلب تطبيقك للوصول إلى البيانات وكيفية استخدامها.

على سبيل المثال، قد يتّبع تطبيقك النموذج التالي:

1. يُثبِّت المستخدم هويته باستخدام تطبيقك
   1. ولا يُطلب أيّ نطاقات إضافية. يقدّم التطبيق وظائف أساسية للسماح للمستخدم باستكشاف الميزات واستخدامها التي لا تتطلّب أي بيانات أو أذونات إضافية.
2. يختار المستخدم ميزة تتطلّب الوصول إلى بيانات إضافية
   1. يقدّم تطبيقك طلب تفويض لنطاق OAuth المحدّد هذا المطلوب لهذه الميزة. إذا كانت هذه الميزة تتطلّب نطاقات متعددة، اتّبِع أفضل الممارسات أدناه.
   2. إذا رفض المستخدم الطلب، يوقف التطبيق الميزة ويقدّم للمستخدم سياقًا إضافيًا لطلب الوصول مرة أخرى.

معالجة الموافقة على نطاقات متعددة

عند طلب نطاقات متعددة في آنٍ واحد، قد لا يمنح المستخدمون جميع نطاقات OAuth التي طلبتها. يجب أن يتعامل تطبيقك مع رفض النطاقات من خلال إيقاف الوظائف ذات الصلة.

إذا كانت الوظيفة الأساسية لتطبيقك تتطلّب نطاقات متعددة، يجب توضيح ذلك للمستخدم قبل طلب موافقته.

لا يجوز لك مطالبة المستخدم مرة أخرى إلا بعد أن يشير بوضوح إلى رغبته في استخدام الميزة المحدّدة التي تتطلّب النطاق. يجب أن يقدّم تطبيقك للمستخدم سياقًا مناسبًا وسببًا وجيهًا قبل طلب نطاقات OAuth.

عليك تقليل عدد النطاقات التي يطلبها تطبيقك في آنٍ واحد. بدلاً من ذلك، استخدِم المصادقة المتزايدة لطلب النطاقات في سياق الميزات والوظائف.

استخدام متصفّحات آمنة

على الويب، يجب تقديم طلبات التفويض باستخدام بروتوكول OAuth 2.0 من متصفّحات الويب المزوّدة بميزات كاملة فقط. على المنصات الأخرى، احرص على اختيار نوع عميل OAuth الصحيح ودمج OAuth بما يناسب منصتك. لا تُعِد توجيه الطلب من خلال بيئات التصفّح المضمّنة، بما في ذلك WebView على الأنظمة الأساسية للأجهزة الجوّالة، مثل WebView على Android أو WKWebView على iOS. بدلاً من ذلك، استخدِم مكتبات OAuth الأصلية أو تسجيل الدخول باستخدام حساب Google لمنصتك.

الإنشاء اليدوي لعملاء OAuth وإعدادهم

لمنع إساءة الاستخدام، لا يمكن إنشاء برامج OAuth أو تعديلها آليًا. عليك استخدام "وحدة تحكّم مطوّري تطبيقات Google" للإقرار صراحةً ببنود الخدمة وضبط برنامج OAuth والاستعداد لإثبات ملكية حساب OAuth.

بالنسبة إلى سير العمل المبرمَج، ننصحك باستخدام حسابات الخدمة بدلاً من ذلك.

إزالة عملاء OAuth غير المستخدَمين

تحقَّق بانتظام من عملاء OAuth 2.0 واحذِف بشكل استباقي أي عملاء لم يعد تطبيقك يحتاجهم أو أصبحوا قديمًا. يشكّل ترك عملاء غير مستخدَمين مُعدَّين خطرًا محتمَلاً على الأمان، لأنّه يمكن إساءة استخدام العميل في حال تم اختراق بيانات اعتماد العميل.

للحدّ من المخاطر الناتجة عن العملاء غير المستخدَمين، يتم تلقائيًا حذف عملاء OAuth 2.0 الذين ظلّوا غير نشطين لمدة ستة أشهر.

أفضل الممارسات المقترَحة هي عدم الانتظار إلى أن يتم الحذف التلقائي، بل إزالة العملاء غير المستخدَمين بشكل استباقي. تقلِّل هذه الممارسة من مساحة الهجوم التي يتعرض لها تطبيقك وتؤمّن إجراءات أمان جيدة.