يساعدك هذا الدليل في الاختيار بين استخدام مكتبة Google Identity Services لتفويض المستخدم أو تنفيذ مكتبة JavaScript الخاصة بك. كما يساعدك على تحديد تدفق تفويض OAuth 2.0 الأنسب لتطبيق الويب لديك.
قبل قراءة هذا الدليل، من المفترض أنّك على دراية بالمصطلحات والمفاهيم الموضحة في دليل نظرة عامة ودليل آلية عمل تفويض المستخدم.
تعمل مكتبة GIS في هذه المتصفحات المتوافقة على جهاز المستخدم. وليس مخصصًا للاستخدام مع إطارات عمل JavaScript من جهة الخادم مثل Node.js، بدلاً من ذلك استخدم مكتبة عملاء Node.js من Google.
يتناول هذا الدليل مواضيع التفويض ومشاركة البيانات فقط. لا يراجِع النظام مصادقة المستخدم، بل يقدّم بدلاً من ذلك معلومات إلى تسجيل الدخول باستخدام حساب Google ودليل نقل البيانات من خلال تسجيل الدخول بحساب Google لتسجيل دخول المستخدمين وتسجيل الدخول.
تحديد ما إذا كانت مكتبة GIS مناسبة لك
يجب عليك اختيار ما إذا كنت تستخدم مكتبة Google، أو إنشاء مكتبة خاصة بك يناسب احتياجاتك. نظرة عامة على الميزات والوظائف:
- تنفّذ مكتبة JavaScript لخدمات الهوية في Google ما يلي:
- عمليات الموافقة المستندة إلى النوافذ المنبثقة لتقليل عمليات إعادة التوجيه، ما يتيح للمستخدمين البقاء على موقعك الإلكتروني طوال عملية منح الإذن
- ميزات الأمان مثل تزوير الطلبات من مواقع إلكترونية متعددة (CRSF)
- طرق مساعدة لطلب نطاقات فردية وتأكيد موافقة المستخدم
- التعامل مع الأخطاء الصديقة للبشر وروابط التوثيق ليستخدمها المهندسون أثناء التطوير أو لاحقًا لزائري موقعك.
- عند التنفيذ بدون مكتبة "خدمات الهوية"، تكون مسؤولاً عن
ما يلي:
- إدارة الطلبات والاستجابات باستخدام نقاط نهاية OAuth 2.0 من Google، بما في ذلك عمليات إعادة التوجيه.
- تحسين تجربة المستخدم.
- تطبيق ميزات الأمان للتحقق من صحة الطلبات والاستجابات ولمنع CSRF.
- طرق التأكّد من أنّ المستخدم قد منح موافقته على أيّ نطاقات مطلوبة.
- إدارة رموز خطأ OAuth 2.0، وإنشاء رسائل يمكن للإنسان فهمها، وروابط لمساعدة المستخدم.
باختصار، تقدم Google مكتبة GIS لمساعدتك في تنفيذ عميل OAuth 2.0 بسرعة وأمان وتحسين تجربة تفويض المستخدم.
اختيار مسار التفويض
سيكون عليك اختيار أحد مسارَي تفويض OAuth 2.0 وهما: رمز التفويض الضمني أو رمز التفويض، بغض النظر عما إذا قررت استخدام مكتبة JavaScript لخدمات Google Identity أو إنشاء مكتبتك الخاصة.
ينتج عن كلا المسارين رمز دخول يمكن استخدامه لاستدعاء واجهات Google APIs.
في ما يلي الاختلافات الأساسية بين التدفقين:
- وعدد إجراءات المستخدم،
- ما إذا كان تطبيقك سيستدعي واجهات Google APIs بدون حضور المستخدِم،
- إذا كانت هناك حاجة إلى نظام أساسي خلفية لاستضافة نقطة نهاية وتخزين الرموز المميزة للتحديث لكل مستخدم لحسابات المستخدمين الفردية،
- مستويات أعلى أو أقل من أمان المستخدم.
عند مقارنة التدفقات وتقييم متطلبات الأمان، يجب مراعاة أن مستوى أمان المستخدم يختلف باختلاف النطاقات التي تختارها. على سبيل المثال، قد يعتبر عرض دعوات التقويم للقراءة فقط أقل خطورة من استخدام نطاق القراءة/الكتابة لتعديل الملفات في Drive.
مقارنة تدفق OAuth 2.0
| التدفق الضمني | مسار رمز التفويض | |
| موافقة المستخدم مطلوبة | لكل طلب رمز مميّز، بما في ذلك استبدال الرموز المميّزة المنتهية الصلاحية. | ينطبق هذا الإجراء على طلب الرمز المميّز الأول فقط. |
| يجب أن يكون المستخدم حاضرًا | نعم | لا، هذه الميزة متاحة للاستخدام بلا إنترنت. |
| أمان المستخدم | الأقل | وتتضمن معظمها مصادقة العميل وتتجنب مخاطر التعامل مع الرمز المميز في المتصفح. |
| تم إصدار رمز الدخول | نعم | نعم |
| تم إصدار الرمز المميّز لإعادة التحميل | لا | نعم |
| يجب استخدام متصفّح متوافق | نعم | نعم |
| رمز الدخول المستخدم لطلب البيانات من Google APIs | فقط من تطبيق ويب يعمل في متصفح المستخدم. | إمّا من خادم يعمل على نظام أساسي خلفية أو من تطبيق ويب يتم تشغيله في متصفّح المستخدم. |
| يتطلّب النظام الأساسي للخلفية | لا | نعم، لاستضافة نقاط النهاية وتخزينها. |
| مساحة تخزين آمنة مطلوبة | لا | نعم، لتخزين الرمز المميّز لإعادة التحميل. |
| يتطلب استضافة نقطة نهاية رمز التفويض | لا | نعم، للحصول على رموز تفويض من Google. |
| سلوك انتهاء صلاحية رمز الوصول المميّز | يجب استخدام إيماءة المستخدم، مثل الضغط على زر أو النقر على رابط، لطلب رمز دخول صالح جديد والحصول عليه. | بعد طلب أولي من المستخدم، تتبادل المنصّة الرمز المميّز لإعادة التحميل المخزَّن للحصول على رمز دخول جديد وصالح وضروري للاتصال بواجهات برمجة تطبيقات Google. |