تتناول هذه الصفحة بعض أفضل الممارسات العامة للتكامل مع OAuth 2.0. ننصحك باتّباع أفضل الممارسات هذه بالإضافة إلى أي إرشادات محدّدة لنوع تطبيقك ومنصة التطوير التي تستخدمها. يُرجى أيضًا الاطّلاع على النصائح حول تجهيز تطبيقك للإصدار العلني وسياسات OAuth 2.0 من Google.
التعامل مع بيانات اعتماد العميل بأمان
تحدّد بيانات اعتماد عميل OAuth هوية تطبيقك ويجب التعامل معها بحذر. يجب تخزين بيانات الاعتماد هذه في مساحة تخزين آمنة فقط، على سبيل المثال باستخدام مدير مفاتيح سرية مثل Google Cloud Secret Manager. لا تضع بيانات الاعتماد في الرمز البرمجي أو تلتزم بها في مستودع الرموز البرمجية أو تنشرها بشكل علني.
التعامل مع الرموز المميّزة للمستخدمين بأمان
تشمل الرموز المميّزة للمستخدمين كلاً من الرموز المميّزة لإعادة التحميل والرموز المميّزة للوصول التي يستخدمها تطبيقك. يجب تخزين الرموز المميّزة بأمان في حالة عدم النشاط وعدم نقلها مطلقًا في نص عادي. استخدِم نظام تخزين آمنًا مناسبًا لنظامك الأساسي، مثل Keystore على Android أو Keychain Services على iOS وmacOS أو Credential Locker على Windows.
ألغِ الرموز المميّزة فور انتهاء الحاجة إليها واحذفها نهائيًا من أنظمتك.
بالإضافة إلى ذلك، ننصحك باتّباع أفضل الممارسات التالية لمنصتك:
- بالنسبة إلى التطبيقات من جهة الخادم التي تخزّن الرموز المميّزة لعدة مستخدمين، يجب تشفيرها في حالة عدم النشاط والتأكّد من أنّ مخزن البيانات غير متاح للجميع على الإنترنت.
- بالنسبة إلى التطبيقات المتوافقة مع الكمبيوتر المكتبي، ننصح بشدة باستخدام بروتوكول Proof Key for Code Exchange (PKCE) للحصول على رموز تفويض يمكن تبادلها برموز الدخول.
الرموز المميّزة المقيّدة للمُرسِل باستخدام DPoP
لحماية تطبيقك من سرقة الرموز المميّزة وهجمات إعادة التشغيل، ننصحك بتقييد الرموز المميّزة للمُرسِل باستخدام DPoP (إثبات الحيازة). في حين أنّ أي جهة تعترض رموز حامل مميز العادية يمكنها استخدامها، فإنّ رموز DPoP المميّزة تكون مرتبطة بشكل مشفّر بمفتاحَي تشفير فريدَين ينشئهما العميل ويحتفظ بهما.
عند استخدام DPoP، يقدّم العميل إثباتًا (رمز JSON مميّز للويب موقَّع) إلى نقطة نهاية الرمز المميّز عند طلب الرموز المميّزة أو إعادة تحميلها. ويثبت هذا الدليل أنّ العميل يمتلك المفتاح الخاص الذي يتطابق مع المفتاح العام المرتبط بالرمز المميّز. إذا تم تسريب رمز مميّز لإعادة التحميل مرتبط بـ DPoP، لا يمكن للمهاجم إعادة استخدامه بدون هذا المفتاح الخاص.
تعمل ميزة DPoP جنبًا إلى جنب مع PKCE لتوفير حماية شاملة:
- يحمي PKCE رمز التفويض أثناء عملية إعادة التوجيه الأولية.
- تحمي ميزة DPoP الرمز المميز لإعادة التحميل الطويل الأمد، ما يمنع هجمات إعادة التشغيل في حال اختراقه.
ننصح بشدة باستخدام DPoP إذا كان تطبيقك:
- يعمل كتطبيق مثبَّت أو تطبيق كمبيوتر مكتبي (أو تطبيق من صفحة واحدة مقترن بخادم Backend-for-Frontend) حيث قد تكون الرموز المميزة لإعادة التحميل أكثر عرضة للاستخراج.
- الوصول إلى بيانات حسّاسة للغاية أو واجهات برمجة تطبيقات عالية القيمة، حيث يكون تأثير تسرُّب الرموز المميّزة كبيرًا
- يجب أن يستوفي معايير الامتثال أو الأمان الصارمة التي تفرض استخدام رموز مميّزة مقيّدة بالمُرسِل.
للحصول على تعليمات مفصّلة حول إنشاء إثباتات DPoP وطلب رموز مميّزة مرتبطة بـ DPoP، يُرجى الرجوع إلى دليل استخدام DPoP.
استخدام مَعلمة الحالة
قبل معالجة استجابة OAuth 2.0، تأكَّد من أنّ state الذي تم تلقّيه من
Google يتطابق مع state الذي تم إرساله في طلب التفويض. يجب أن تكون المَعلمة state قيمة فريدة لا يمكن تخمينها، ويتم إنشاؤها بواسطة تطبيقك.
يساعد استخدام المَعلمة state في التأكّد من أنّ المستخدم هو من يرسل الطلب وليس نصًا برمجيًا ضارًا، كما يقلل من خطر هجمات تزوير الطلبات من مواقع إلكترونية مختلفة (CSRF).
التعامل مع إبطال الرمز المميّز لإعادة التحميل وانتهاء صلاحيته
إذا طلب تطبيقك رمزًا مميزًا لإعادة التحميل للتشغيل بلا إنترنت، عليك أيضًا التعامل مع حالات إبطال صلاحيته أو انتهائها. قد يتم إبطال الرموز المميزة لأسباب مختلفة، على سبيل المثال، قد تكون انتهت صلاحيتها أو قد يكون المستخدم أو عملية مبرمَجة قد ألغيا إمكانية وصول تطبيقاتك إلى البيانات. في هذه الحالة، عليك التفكير بعناية في كيفية استجابة تطبيقك، بما في ذلك مطالبة المستخدم عند تسجيل الدخول في المرة التالية أو تنظيف بياناته. لتلقّي إشعارات بشأن إبطال الرموز المميّزة، يمكنك التكامل مع خدمة الحماية العابرة للحساب.
استخدام التفويض المتزايد
استخدِم التفويض التدريجي لطلب نطاقات OAuth المناسبة عندما يحتاج تطبيقك إلى الوظيفة.
يجب عدم طلب الوصول إلى البيانات عندما تتم مصادقة المستخدم لأول مرة، إلا إذا كان ذلك ضروريًا للوظيفة الأساسية لتطبيقك. بدلاً من ذلك، اطلب فقط النطاقات المحددة اللازمة لمهمة ما، باتّباع مبدأ اختيار أصغر النطاقات وأكثرها محدودية قدر الإمكان.
اطلب دائمًا النطاقات في سياق استخدام التطبيق لمساعدة المستخدمين في فهم سبب طلب تطبيقك للوصول إلى البيانات وكيفية استخدامها.
على سبيل المثال، قد يتّبع تطبيقك هذا النموذج:
- يصادق المستخدم على تطبيقك
- لم يتم طلب أي نطاقات إضافية. يوفّر التطبيق وظائف أساسية تتيح للمستخدم استكشاف الميزات واستخدامها بدون الحاجة إلى أي بيانات أو أذونات وصول إضافية.
- يختار المستخدم ميزة تتطلّب الوصول إلى بيانات إضافية
- يُرسل تطبيقك طلب تفويض لنطاق OAuth المحدّد المطلوب لهذه الميزة. إذا كانت هذه الميزة تتطلّب نطاقات متعددة، اتّبِع أفضل الممارسات للنطاقات المتعددة.
- إذا رفض المستخدم الطلب، يوقف التطبيق الميزة ويمنح المستخدم سياقًا إضافيًا لطلب الوصول مرة أخرى.
التعامل مع الموافقة على نطاقات متعددة
عند طلب نطاقات متعددة في آنٍ واحد، قد لا يمنح المستخدمون جميع نطاقات OAuth التي طلبتها. يجب أن يتعامل تطبيقك مع رفض النطاقات من خلال إيقاف الوظائف ذات الصلة.
إذا كانت الوظائف الأساسية لتطبيقك تتطلّب نطاقات متعددة، عليك توضيح ذلك للمستخدم قبل طلب موافقته.
ولا يمكنك طلب ذلك من المستخدم مرة أخرى إلا بعد أن يشير بوضوح إلى نيته استخدام الميزة المحدّدة التي تتطلب النطاق. يجب أن يقدّم تطبيقك للمستخدم السياق والمبررات ذات الصلة قبل طلب نطاقات OAuth.
يجب تقليل عدد النطاقات التي يطلبها تطبيقك في المرة الواحدة. بدلاً من ذلك، استخدِم التفويض المتزايد لطلب النطاقات في سياق الميزات والوظائف.
استخدام متصفّحات آمنة
على الويب، يجب تقديم طلبات تفويض OAuth 2.0 من متصفّحات ويب كاملة الميزات فقط. على الأنظمة الأساسية الأخرى، تأكَّد من اختيار نوع عميل OAuth الصحيح ودمج OAuth بما يتناسب مع نظامك الأساسي. لا تُعِد توجيه الطلب من خلال بيئات التصفّح المضمّنة، بما في ذلك طرق عرض الويب على الأنظمة الأساسية للأجهزة الجوّالة، مثل WebView على Android أو WKWebView على iOS. بدلاً من ذلك، استخدِم مكتبات OAuth المقترَحة أو تسجيل الدخول باستخدام حساب Google لنظامك الأساسي.
إنشاء عملاء OAuth وإعدادهم يدويًا
لمنع إساءة الاستخدام، لا يمكن إنشاء عملاء OAuth أو تعديلهم آليًا. يجب استخدام Google Cloud Console للموافقة صراحةً على بنود الخدمة وضبط عميل OAuth والاستعداد لإجراء عملية التحقّق من OAuth.
بالنسبة إلى مهام سير العمل المبرمَجة، ننصحك باستخدام حسابات الخدمة بدلاً من ذلك.
إزالة عملاء OAuth غير المستخدَمين
راجِع عملاء OAuth 2.0 بانتظام واحذف بشكل استباقي أي عملاء لم يعُد تطبيقك بحاجة إليهم أو أصبحوا قديمين. إنّ ترك برامج غير مستخدَمة تم ضبطها يمثّل خطرًا أمنيًا محتملاً، إذ يمكن إساءة استخدام البرنامج في حال اختراق بيانات اعتماد البرنامج.
للحدّ من المخاطر الناتجة عن العملاء غير النشطين، يتم حذف عملاء OAuth 2.0 تلقائيًا إذا ظلّوا غير نشطين لمدة ستة أشهر.
أفضل الممارسات المقترَحة هي عدم انتظار الحذف التلقائي، بل إزالة العملاء غير المستخدَمين بشكل استباقي. تساعد هذه الممارسة في تقليل فرص الاختراق في تطبيقك وضمان مستوى جيد من الأمان.