إذا لم تكن معتادًا على استخدام خدمات هوية Google أو تفويضها، فابدأ بقراءة النظرة العامة.
تقدّم Google مكتبة JavaScript تتضمن ميزات تفويض لمساعدتك على إدارة النطاقات والحصول على موافقة المستخدم والعمل بسهولة أكبر مع مسارات OAuth 2.0 العادية. يستخدم تطبيق الويب، الذي يعمل في متصفّح المستخدم، هذه المكتبة لإدارة تدفق OAuth 2.0 الضمني، أو لبدء مسار رمز التفويض الذي ينتهي على النظام الأساسي للخلفية.
نطاقات المصادقة فقط
ويتم استخدام عدة نطاقات لمصادقة المستخدم فقط: email وprofile وopenid. إذا كان تطبيقك يستخدم هذه النطاقات فقط، يجب مراعاة ما إذا كان الرمز المميّز لرقم تعريف JWT وميزة تسجيل الدخول باستخدام حساب Google لتلبية احتياجاتك. في معظم الحالات، تكون هذه هي الطريقة الأكثر وضوحًا وبساطة المتاحة لمصادقة المستخدم.
المصطلحات والمفاهيم الرئيسية
تفترض هذه الأدلة أنك على دراية أساسية بمفاهيم OAuth 2.0 ومعايير مجموعة مهندسي شبكة الإنترنت (IETF) مثل RFC6749. تُستخدم العبارات التالية في أدلة التفويض:
- رمز الدخول هو رمز قصير الأمد تصدره Google لبيانات اعتماد كل مستخدم ويُستخدَم للاتصال بواجهات Google API والوصول إلى بيانات المستخدمين بأمان.
- رمز التفويض هو رمز مؤقت تصدره Google لتحديد هوية المستخدمين الفرديين الذين يسجّلون الدخول إلى حساباتهم على Google من أحد المتصفحات بشكل آمن. يتبادل النظام الأساسي للخلفية هذا الرمز للوصول إلى الرموز المميزة وإعادة التحميل.
- الرمز المميّز لإعادة التحميل هو رمز بيانات اعتماد طويل الأمد تصدره Google ويتم تخزينه بأمان على منصّتك ويمكن استخدامه للحصول على رمز دخول جديد وصالح حتى في حال عدم توفّر المستخدم.
- يحصر النطاق الرموز المميّزة في مقدار محدّد ومحدود من بيانات المستخدم. يُرجى الاطّلاع على نطاقات OAuth 2.0 لواجهات Google APIs لمعرفة المزيد.
- وضع النافذة المنبثقة هو رمز تفويض يستند إلى استدعاء JavaScript يتم تشغيله في متصفّح المستخدم. تستدعي Google معالج معاودة الاتصال الذي يكون مسؤولاً عندها عن إرسال رمز المصادقة إلى نظامك الأساسي، فكيف يتم ذلك بنفسك.
- وضع إعادة التوجيه هو تدفق رمز تفويض يستند إلى عمليات إعادة توجيه HTTP. تتم إعادة توجيه وكيل المستخدم إلى Google أولاً، ثم إعادة التوجيه الثانية من Google إلى نقطة نهاية رمز التفويض في نظامك الأساسي تشتمل على الرمز.
وتحدّد Google، بصفتها جهة إصدار الرموز المميّزة، مدة بقاء الرموز المميّزة. قد تختلف المدة الدقيقة بسبب عوامل مختلفة.
تدفقات OAuth 2.0
تتم مناقشة تدفقين، وهما ضمني ورمز التفويض. يعرض كلاهما رمز دخول مناسبًا للاستخدام مع Google APIs.
يُنصَح باستخدام تدفق رمز التفويض لأنه يوفر مستوى مُحسَّنًا من الأمان للمستخدم. يعرض هذا المسار أيضًا رمز تحديث يمكن استخدامه للحصول على رموز الدخول بدون حضور المستخدم، ما يتيح لنظامك الأساسي تنفيذ إجراءات غير متزامنة بسهولة أكبر، مثل إرسال تذكير عبر رسالة قصيرة SMS باجتماع مقبل تم تحديد موعده في اللحظة الأخيرة. يشرح اختيار نموذج تفويض الاختلافات بين التدفقين بمزيد من التفصيل.
تتّبع مكتبة JavaScript لخدمات Google Identity معيار OAuth 2.0 لتنفيذ ما يلي:
- إدارة التدفق الضمني لتمكين تطبيق الويب الموجود في المتصفح من الحصول بسرعة وسهولة على رمز دخول من Google لازم لاستدعاء Google APIs.
- لبدء تدفق رمز التفويض من متصفح المستخدم.
الخطوات الشائعة
يبدأ كل من مسار رمز التفويض الضمني وخطوات رمز التفويض بالطريقة نفسها:
- يطلب تطبيقك الوصول إلى نطاق واحد أو أكثر.
- تعرض Google مربّع إفادة الموافقة للمستخدم، ويتم تسجيل دخول المستخدم أولاً إلى حسابه على Google إذا لزم الأمر.
- يوافق المستخدم بشكل فردي على كل نطاق مطلوب.
ينتهي كل تدفق بعد ذلك بخطوات مختلفة.
عند استخدام التدفق الضمني
- تستخدم Google معالج استدعاء لإشعار تطبيقك بنتيجة الموافقة وعرض رمز دخول لأي نطاقات موافَق عليها.
عند استخدام مسار رمز المصادقة
- تردّ Google باستخدام رمز تفويض لكل مستخدم:
- في وضع إعادة التوجيه، يتمّ إرجاع الرمز إلى نقطة نهاية رمز التفويض الخاص بالنظام الأساسي.
- في الوضع المنبثق، يتم عرض الرمز إلى معالج معاودة الاتصال في تطبيقك عبر المتصفح، بدون أن يحتاج المستخدمون إلى مغادرة موقعك الإلكتروني.
- بدءًا من الخطوة الرابعة: التعامل مع استجابة خادم OAuth 2.0 تُكمل النظام الأساسي الخلفية عملية تبادل من خادم إلى خادم مع Google، ما يؤدي في النهاية إلى إرجاع رمز مميز لإعادة التحميل ورمز دخول مميز إلى نظامك الأساسي.
موافقة المستخدم
قبل الحصول على رمز الدخول، على المستخدمين الفرديين منح الموافقة على وصول تطبيقك إلى النطاقات المطلوبة. لإجراء ذلك، تعرِض Google مربّع إفادة الموافقة خلال الخطوة 2 أعلاه وتسجِّل النتيجة في myaccount.google.com/permissions.
يتم عرض اسم التطبيق وشعاره وسياسة الخصوصية وبنود الخدمة والنطاقات المطلوبة، بالإضافة إلى خيار الموافقة على الطلب أو إلغائه.
في الشكل 1، يظهر مربّع إفادة الموافقة لنطاق واحد. عند طلب نطاق واحد، لا يلزم وجود مربعات اختيار للموافقة على النطاق أو رفضه.
الشكل 1: مربّع إفادة موافقة المستخدِم بنطاق واحد.
في الشكل 2، يظهر مربّع إفادة الموافقة لنطاقات متعددة. عندما يتم طلب أكثر من نطاق واحد، تكون مربعات الاختيار الفردية ضرورية للسماح للمستخدم بالموافقة على كل نطاق أو رفضه.
الشكل 2: مربّع إفادة موافقة المستخدِم مع نطاقات متعددة.
حسابات المستخدمين
يجب توفّر حساب Google لتسجيل الموافقة وإصدار رمز الدخول. قبل ذلك، يجب أن يكون كلٌّ من المستخدمين قد صادقوا على أنفسهم أمام Google من خلال تسجيل الدخول إلى حساب Google.
ننصحك باستخدام ميزة "تسجيل الدخول باستخدام حساب Google" للاشتراك في تطبيق الويب أو النظام الأساسي للخلفية، علمًا أنّ هذا الإجراء ليس مطلبًا أساسيًا. يؤدي ذلك إلى الحد من الصعوبة التي يواجهها المستخدم من خلال تقليل عدد الخطوات المطلوبة ويتيح لك اختياريًا ربط رموز الدخول بسهولة بالحسابات الفردية على منصتك.
على سبيل المثال، يؤدي استخدام ميزة "تسجيل الدخول باستخدام حساب Google" إلى إنشاء جلسة نشطة في حساب Google، وبالتالي تجنُّب الحاجة إلى مطالبة المستخدم لاحقًا بتسجيل الدخول إلى حساب Google عند تقديم طلب تفويض. إذا اخترت مصادقة المستخدمين إلى تطبيقك بوسائل أخرى مثل اسم المستخدم وكلمة المرور أو غيرهم من موفِّري الهوية، سيُطلب منهم تسجيل الدخول أولاً إلى حساب Google للحصول على موافقتهم.
تؤدي إضافة تلميح تسجيل الدخول أثناء تهيئة التفويض--عادةً عنوان البريد الإلكتروني لحساب المستخدم في Google- إلى تمكين Google من تخطي عرض محدد الحساب، ما يوفر خطوةً للمستخدمين. تحتوي بيانات اعتماد الرمز المميّز لرقم التعريف التي تعرضها ميزة "تسجيل الدخول باستخدام حساب Google" على عنوان البريد الإلكتروني للمستخدم.
أمّا تطبيقات الويب التي لا تعمل إلا في المتصفِّح، فقد تعتمد فقط على Google في المصادقة على المستخدم، وتختار عدم تطبيق نظام إدارة حسابات المستخدمين. في هذا السيناريو، المعروف باسم التدفق الضمني، لا حاجة إلى ربط رمز مميّز للتحديث بحساب المستخدم ومساحة التخزين الآمنة للإدارة.
بدلاً من ذلك، يتطلب تدفق رمز التفويض نظام حساب مستخدم. يجب ربط الرموز المميزة لإعادة التحميل لكل مستخدم بحساب فردي على النظام الأساسي للخلفية وتخزينها للاستخدام لاحقًا. إنّ كيفية تنفيذ نظام حسابات المستخدمين والعمل معه وإدارته هو أمر فريد بالنسبة إلى نظامك الأساسي ولا تتم مناقشته بمزيد من التفصيل.
عرض الموافقة وإبطالها
يجوز للمستخدمين الاطّلاع على الموافقة أو إبطالها في أي وقت من إعدادات حساباتهم على Google.
اختياريًا، يمكن لتطبيق الويب أو منصتك طلب استدعاء الإجراء
google.accounts.oauth2.revoke لإبطال الرموز المميّزة وإزالة موافقة المستخدم.
ويُعد هذا الإجراء مفيدًا عندما يحذف المستخدم حسابه من منصتك.
خيارات التفويض الأخرى
وبدلاً من ذلك، يمكن أن تحصل المتصفحات على رموز الدخول باستخدام التدفق الضمني من خلال استدعاء نقاط نهاية OAuth 2.0 من Google مباشرةً كما هو موضَّح في OAuth 2.0 لتطبيقات الويب من جهة العميل.
وبالمثل، بالنسبة إلى مسار رمز التفويض، يمكنك اختيار تنفيذ طرقك الخاصة واتّباع الخطوات الموضّحة في استخدام OAuth 2.0 لتطبيقات خادم الويب.
في كلتا الحالتين، ننصح بشدة باستخدام مكتبة خدمات الهوية في Google لتقليل وقت وجهد التطوير وتقليل المخاطر الأمنية مثل تلك الموضحة في مقالة أفضل ممارسات الأمان الحالية لبروتوكول OAuth 2.0.