تتناول هذه الصفحة بعض أفضل الممارسات العامة للتكامل مع OAuth 2.0. ننصحك باتّباع أفضل الممارسات هذه بالإضافة إلى أي إرشادات خاصة بنوع منصة التطبيقات والتطوير التي تستخدمها. يمكنك أيضًا الاطّلاع على نصائح تجهيز تطبيقك للإصدار العلني وسياسات OAuth 2.0 من Google.
التعامل مع بيانات اعتماد العميل بأمان
تحدِّد بيانات اعتماد عميل OAuth هوية تطبيقك ويجب التعامل معها بعناية. ولا تخزِّن سوى بيانات الاعتماد هذه في مساحة تخزين آمنة، مثلاً باستخدام مدير سري مثل Google Cloud Secret Manager. تجنَّب استخدام ترميز ثابت لبيانات الاعتماد أو إدخالها في مستودع رموز أو نشرها علنًا.
التعامل مع الرموز المميّزة للمستخدم بأمان
تشمل الرموز المميّزة للمستخدم كلاً من الرموز المميّزة لإعادة التحميل ورموز الدخول التي يستخدمها تطبيقك. تخزين الرموز المميّزة بشكل آمن عندما يكون الجهاز غير نشِط وعدم إرسالها مطلقًا في نص عادي استخدام نظام تخزين آمن مناسب للنظام الأساسي، مثل مخزن المفاتيح على نظام التشغيل Android أو "خدمات سلسلة المفاتيح" على نظامَي التشغيل iOS وmacOS أو "مخزن بيانات الاعتماد" على نظام التشغيل Windows
أبطِل الرموز المميّزة في حال لم تعُد بحاجة إليها، واحذفها نهائيًا من أنظمتك.
بالإضافة إلى ذلك، ننصحك بأن تأخذ في الاعتبار أفضل الممارسات التالية في منصتك:
- بالنسبة إلى التطبيقات من جهة الخادم التي تخزّن الرموز المميّزة للعديد من المستخدمين، يمكنك تشفير هذه التطبيقات في حال عدم النشاط والتأكّد من عدم إمكانية الوصول إلى تخزين البيانات بشكل علني على الإنترنت.
- في التطبيقات الأصلية المتوافقة مع أجهزة الكمبيوتر المكتبي، يُنصَح بشدة باستخدام بروتوكول إثبات مفتاح تبادل الرموز (PKCE) للحصول على رموز التفويض التي يمكن استبدالها برموز الدخول.
التعامل مع إبطال الرمز المميّز لإعادة التحميل وانتهاء صلاحيته
إذا طلب تطبيقك رمزًا مميّزًا للتحديث من أجل الوصول بلا اتصال بالإنترنت، عليك أيضًا معالجة إبطال صلاحية هذا الرمز أو تاريخ انتهاء صلاحيته. قد يتم إبطال صلاحية الرموز المميّزة لأسباب مختلفة، مثل انتهاء صلاحيتها أو إبطال إمكانية وصول المستخدم إلى تطبيقاتك أو إكمال عملية مبرمَجة لها. وفي هذه الحالة، يجب التفكير في كيفية استجابة التطبيق بعناية، بما في ذلك مطالبة المستخدم عند تسجيل الدخول في المرة التالية أو تنظيم بياناته. ليتم إشعارك بإبطال الرمز المميّز، يُرجى الدمج مع خدمة الحماية العابرة للحساب.
استخدام التفويض المتزايد
استخدِم التفويض التزايدي لطلب نطاقات OAuth المناسبة عندما يكون التطبيق مطلوبًا.
يجب عدم طلب الوصول إلى البيانات في المرة الأولى التي يجري المستخدم فيها مصادقة، إلا إذا كان ذلك ضروريًا للوظيفة الأساسية لتطبيقك. بدلاً من ذلك، اطلب فقط النطاقات المحددة اللازمة لمهمة ما، مع اتّباع المبدأ اختيار النطاقات الأصغر والأكثر تقييدًا.
اطلُب النطاقات دائمًا في سياقها المناسب لمساعدة المستخدمين في فهم سبب طلب تطبيقك للوصول إلى البيانات وكيفية استخدام البيانات.
على سبيل المثال، قد يتبع تطبيقك النموذج التالي:
- يُجري المستخدم مصادقة باستخدام تطبيقك
- لا يلزم أي نطاقات إضافية. يوفّر التطبيق وظائف أساسية تتيح للمستخدم استكشاف واستخدام الميزات التي لا تتطلب أي بيانات إضافية أو إمكانية الوصول.
- يختار المستخدم ميزة تتطلّب الوصول إلى بيانات إضافية.
- يطلب تطبيقك طلب تفويض لنطاق OAuth المحدد هذا المطلوب لهذه الميزة. إذا كانت هذه الميزة تتطلّب نطاقات متعدّدة، يُرجى اتّباع أفضل الممارسات أدناه.
- وإذا رفض المستخدم الطلب، يوقف التطبيق الميزة ويقدّم للمستخدم سياقًا إضافيًا لطلب الوصول مرة أخرى.
التعامل مع الموافقة لنطاقات متعددة
عند طلب نطاقات متعددة في الوقت نفسه، قد لا يمنح المستخدمون جميع نطاقات OAuth التي طلبتها. يجب أن يتعامل تطبيقك مع رفض النطاقات من خلال إيقاف الوظائف ذات الصلة.
إذا كانت الوظائف الأساسية لتطبيقك تتطلّب نطاقات متعدّدة، يُرجى شرح ذلك للمستخدم قبل طلب الموافقة.
لا يمكنك إرسال طلب إلى المستخدم مرة أخرى إلا بعد أن يشير بوضوح إلى رغبته في استخدام الميزة المحدّدة التي تتطلب النطاق. يجب أن يزود تطبيقك المستخدم بالسياق والسياق ذي الصلة قبل طلب نطاقات OAuth.
يجب تقليل عدد النطاقات التي يطلبها تطبيقك في آن واحد. بدلاً من ذلك، استخدِم التفويض المتزايد لطلب النطاقات في سياق الميزات والوظائف.
استخدام متصفّحات آمنة
على الويب، يجب تقديم طلبات تفويض OAuth 2.0 من متصفحات ويب كاملة الميزات فقط. على الأنظمة الأساسية الأخرى، احرص على اختيار نوع عميل OAuth الصحيح ودمج OAuth بالشكل المناسب للنظام الأساسي الذي تستخدمه. لا تعيد توجيه الطلب من خلال بيئات تصفّح مضمّنة، بما في ذلك مكوّنات WebView على الأنظمة الأساسية للأجهزة الجوّالة، مثل WebView على Android أو WKWebView على أجهزة iOS. بدلاً من ذلك، يمكنك استخدام مكتبات OAuth الأصلية أو تسجيل الدخول بحساب Google على منصتك.
إنشاء عملاء OAuth وإعدادهم يدويًا
لمنع إساءة الاستخدام، لا يمكن إنشاء برامج OAuth أو تعديلها آليًا. يجب استخدام Google Developers Console للإقرار صراحةً ببنود الخدمة وإعداد عميل OAuth والاستعداد لإثبات الملكية من خلال بروتوكول OAuth.
بالنسبة إلى عمليات سير العمل المبرمَجة، يمكنك استخدام حسابات الخدمة بدلاً من ذلك.