اختيار نموذج تفويض المستخدم

يساعدك هذا الدليل في الاختيار بين استخدام مكتبة Google Identity Services لتفويض المستخدم أو تنفيذ مكتبة JavaScript الخاصة بك. ويساعدك في تحديد مسار تفويض OAuth 2.0 الأفضل لتطبيق الويب.

يُفترض أنّك على دراية بالمصطلحات والمفاهيم الموضّحة في الدليلَين نظرة عامة على تفويض المستخدم و كيفية عمله قبل قراءة هذا الدليل.

تعمل مكتبة GIS في متصفّحات الويب المتوافقة هذه على جهاز المستخدم. Node.js

لا يغطّي هذا الدليل سوى مواضيع التفويض ومشاركة البيانات. ولا يراجع مصادقة المستخدم، بل يمكنك الاطّلاع على مقالتَي تسجيل الدخول باستخدام حساب Google والترحيل من Google Sign-In لتسجيل المستخدمين وتسجيل دخولهم.

تحديد ما إذا كانت مكتبة GIS مناسبة لك

عليك اختيار ما إذا كان استخدام مكتبة Google أو إنشاء مكتبتك الخاصة هو الأنسب لاحتياجاتك. في ما يلي نظرة عامة على الميزات والوظائف:

  • تنفّذ مكتبة JavaScript الخاصة بخدمات Google Identity ما يلي:
    • مسارات الموافقة المستندة إلى مربّعات الحوار لتقليل عمليات إعادة التوجيه، ما يتيح للمستخدمين البقاء على موقعك الإلكتروني طوال عملية التفويض.
    • ميزات الأمان، مثل تزوير الطلبات من مواقع إلكترونية مختلفة (CRSF).
    • طُرق مساعِدة لطلب نطاقات فردية وتأكيد موافقة المستخدم.
    • معالجة الأخطاء بطريقة سهلة الاستخدام وروابط المستندات التي يمكن للمهندسين استخدامها أثناء التطوير ولاحقًا لزوّار موقعك الإلكتروني.
  • عند التنفيذ بدون مكتبة Identity Services، تكون مسؤولاً عن:
    • إدارة الطلبات والردود باستخدام نقاط نهاية OAuth 2.0 من Google، بما في ذلك عمليات إعادة التوجيه.
    • تحسين تجربة المستخدم.
    • تنفيذ ميزات الأمان للتحقّق من صحة الطلبات والردود ومنع تزوير الطلبات من مواقع إلكترونية مختلفة.
    • طُرق لتأكيد موافقة المستخدم على أي نطاقات مطلوبة.
    • إدارة رموز خطأ OAuth 2.0، وإنشاء رسائل سهلة القراءة، وروابط لمساعدة المستخدم.

باختصار، تقدّم Google مكتبة GIS لمساعدتك في تنفيذ عميل OAuth 2.0 بسرعة وأمان وتحسين تجربة تفويض المستخدم.

اختيار مسار تفويض

عليك اختيار أحد مسارَي تفويض OAuth 2.0: ضمني أو رمز التفويض، بغض النظر عمّا إذا قرّرت استخدام مكتبة JavaScript الخاصة بخدمات Google Identity أو إنشاء مكتبتك الخاصة.

يؤدي كلا المسارَين إلى الحصول على رمز دخول يمكن استخدامه لاستدعاء واجهات برمجة تطبيقات Google.

في ما يلي الاختلافات الرئيسية بين المسارَين:

  • عدد إجراءات المستخدم،
  • ما إذا كان تطبيقك سيستدعي واجهات برمجة تطبيقات Google بدون حضور المستخدم،
  • ما إذا كانت هناك حاجة إلى منصة خلفية لاستضافة نقطة نهاية وتخزين رموز إعادة التحميل لكل مستخدم لحسابات المستخدمين الفردية، و
  • مستويات أمان المستخدم الأعلى أو الأدنى.

عند مقارنة المسارات وتقييم متطلبات الأمان، يجب مراعاة أنّ مستوى أمان المستخدم يختلف حسب النطاقات التي تختارها. على سبيل المثال، قد يكون عرض الدعوات إلى التقويم كقراءة فقط أقل خطورة من استخدام نطاق القراءة والكتابة لتعديل الملفات في Drive.

مقارنة مسار OAuth 2.0

التدفّق الضمني مسار رمز التفويض
موافقة المستخدم مطلوبة لكل طلب رمز، بما في ذلك استبدال الرموز المنتهية الصلاحية. لأول طلب رمز فقط.
يجب أن يكون المستخدم حاضرًا نعم لا، يتيح استخدام التطبيق بلا إنترنت.
أمان المستخدم الأقل تكرارًا الأكثر، يتضمّن مصادقة العميل ويتجنّب مخاطر معالجة الرموز في المتصفّح.
رمز الدخول الصادر نعم نعم
الرمز المميّز لإعادة التحميل الصادر لا نعم
المتصفّح المتوافق مطلوب نعم نعم
رمز الدخول المستخدَم لاستدعاء واجهات برمجة تطبيقات Google فقط من تطبيق ويب يعمل في متصفّح المستخدم. إما من خادم يعمل على منصة خلفية أو من تطبيق ويب يعمل في متصفّح المستخدم.
المنصة الخلفية مطلوبة لا نعم، لاستضافة نقطة النهاية والتخزين.
مساحة تخزين آمنة مطلوبة لا نعم، لتخزين الرمز المميّز لإعادة التحميل.
استضافة نقطة نهاية لرمز التفويض مطلوبة لا نعم، لتلقّي رموز التفويض من Google.
سلوك انتهاء صلاحية رمز الدخول يجب أن يتخذ المستخدم إجراءً تفاعليًا، مثل الضغط على زر أو النقر على رابط، لطلب رمز دخول جديد وصالح والحصول عليه. بعد طلب المستخدم الأولي، تستبدل منصتك الرمز المميّز لإعادة التحميل المخزَّن للحصول على رمز دخول جديد وصالح ضروري لاستدعاء Google APIs.