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