تتناول هذه الصفحة بعض أفضل الممارسات العامة للتكامل مع OAuth 2.0. ننصحك باتّباع أفضل الممارسات التالية بالإضافة إلى أي إرشادات محدّدة لنوع تطبيقك ومنصة التطوير التي تستخدمها. يُرجى أيضًا الرجوع إلى النصائح حول إعداد تطبيقك للإصدار العلني وسياسات بروتوكول OAuth 2.0 من Google.
التعامل مع بيانات اعتماد العميل بأمان
تحدّد بيانات اعتماد عميل OAuth هوية تطبيقك ويجب التعامل معها بعناية. يجب تخزين بيانات الاعتماد هذه في مساحة تخزين آمنة فقط، مثلاً باستخدام مدير مفاتيح سرية مثل Google Cloud Secret Manager. لا تبرمج بيانات الاعتماد بشكل ثابت أو تدرجها في مستودع رموز برمجية أو تنشرها بشكل علني.
التعامل مع رموز المستخدمين المميزة بشكل آمن
تتضمّن رموز المستخدمين المميزة كلاً من رموز إعادة التحميل ورموز الدخول التي يستخدمها تطبيقك. تخزين الرموز المميزة بشكل آمن أثناء الراحة وعدم إرسالها مطلقًا كنص عادي استخدِم نظام تخزين آمنًا مناسبًا للنظام الأساسي، مثل Keystore على Android أو Keychain Services على iOS وmacOS أو Credential Locker على Windows.
إبطال الرموز المميزة فور الاستغناء عنها وحذفها نهائيًا من أنظمتك
بالإضافة إلى ذلك، ننصحك باتّباع أفضل الممارسات التالية لمنصتك:
- بالنسبة إلى التطبيقات التي تعمل على جهة الخادم وتخزّن الرموز المميّزة لعدة مستخدمين، يجب تشفيرها أثناء عدم الاستخدام والتأكّد من أنّ مخزن البيانات غير متاح للجميع على الإنترنت.
- بالنسبة إلى تطبيقات سطح المكتب، يُنصح بشدة باستخدام بروتوكول مفتاح الحماية لتبادل الرموز (PKCE) للحصول على رموز تفويض يمكن استبدالها برموز دخول.
الرموز المميزة المقيدة بالمرسل باستخدام بروتوكول DPoP
لحماية تطبيقك من سرقة الرموز المميزة وهجمات إعادة الإرسال، ننصحك بفرض قيود على المرسل في الرموز المميزة باستخدام DPoP (إثبات الحيازة). في حين يمكن لأي جهة تعترض رموز Bearer المميزة استخدامها، تكون رموز DPoP المميزة مرتبطة بشكل مشفّر بزوج مفاتيح فريد ينشئه العميل ويحتفظ به.
عند استخدام DPoP، يقدّم العميل دليلاً (رمز JSON مميّز للويب موقّع) إلى نقطة نهاية الرمز المميّز عند طلب الرموز المميزة أو إعادة تحميلها. تثبت هذه الشهادة أنّ العميل لديه المفتاح الخاص الذي يتوافق مع المفتاح العام المرتبط بالرمز المميّز. في حال تسرُّب رمز مميز لإعادة التحميل مرتبط بإثبات الحيازة، لا يمكن للمهاجم إعادة استخدامه بدون المفتاح الخاص.
تعمل DPoP جنبًا إلى جنب مع PKCE لتوفير حماية شاملة:
- توفّر PKCE الحماية لرمز التفويض أثناء عملية إعادة التوجيه الأولية.
- تحمي DPoP الرمز المميز لإعادة التحميل طويل الأمد، ما يمنع هجمات إعادة التشغيل في حال اختراقه.
ننصح بشدة باستخدام DPoP إذا كان تطبيقك:
- تعمل كبرنامج عميل عام (مثل تطبيق صفحة واحدة أو تطبيق مثبَّت) حيث تكون رموز التحديث أكثر عرضة للاختراق.
- الوصول إلى بيانات حساسة للغاية أو واجهات برمجة تطبيقات عالية القيمة، حيث يكون تأثير تسريب الرمز المميز كبيرًا
- يجب أن يستوفي معايير صارمة متعلقة بالامتثال أو الأمان تتطلّب استخدام رموز مميّزة محدودة من قِبل المرسل.
للحصول على تعليمات تفصيلية حول إنشاء مستندات إثبات 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 الذين لم يتم استخدامهم لمدة ستة أشهر.
تتمثّل أفضل الممارسات المقترَحة في عدم انتظار الحذف التلقائي، بل إزالة العملاء غير المستخدَمين بشكل استباقي. تساهم هذه الممارسة في تقليل مساحة الهجوم في تطبيقك وتضمن مستوى جيدًا من الأمان.