إذا كنت مستخدمًا جديدًا أو غير معتاد على خدمات الهوية أو التفويض في Google، ابدأ بقراءة نظرة عامة.
وتقدّم Google مكتبة JavaScript تتضمّن ميزات التفويض لمساعدتك في إدارة النطاقات والحصول على موافقة المستخدم والعمل بسهولة أكبر مع مسارات OAuth 2.0 العادية. يستخدم تطبيق الويب الخاص بك الذي يعمل في متصفح المستخدم هذه المكتبة لإدارة تدفق الهدف الضمني لبروتوكول OAuth 2.0 أو لبدء تدفق رمز التفويض الذي ينتهي على النظام الأساسي الخلفي.
نطاقات المصادقة فقط
يتم استخدام نطاقات متعددة في مصادقة المستخدم فقط: email وprofile
وopenid. إذا كان تطبيقك يستخدم هذه النطاقات فقط، يجب مراعاة ما إذا كان الرمز المميز لـ JWT وتسجيل الدخول باستخدام Google لتسجيل دخول المستخدم وتسجيل الدخول يلبي احتياجاتك. في معظم الحالات، هذه هي الطريقة الأكثر بساطة وبساطة
لمصادقة المستخدم.
المصطلحات والمفاهيم الرئيسية
تفترض هذه الأدلة أن لديك فهمًا أساسيًا لمفاهيم OAuth 2.0 ومعايير IETF، مثل RFC6749. تُستخدم العبارات التالية في جميع أدلة التفويض:
- رمز الدخول هو بيانات اعتماد قصيرة المدى لكل مستخدم صادرة عن Google، حيث يتم استخدامها لاستدعاء واجهات برمجة تطبيقات Google والوصول إلى بيانات المستخدم بشكل آمن.
- رمز التفويض هو رمز مؤقت تصدره Google لتعريف المستخدمين الفرديين الذين يسجلون الدخول إلى حساباتهم على Google من متصفح بشكل آمن. تستبدل منصةك الخلفية هذا الرمز للوصول إلى الرموز المميّزة والتحديث.
- الرمز المميز لإعادة التحميل هو بيانات اعتماد طويلة الأمد لكل مستخدم تصدرها Google ويتم تخزينها بأمان على نظامك الأساسي ويمكن استخدامها للحصول على رمز دخول جديد وصالح حتى إذا لم يكن المستخدم حاضرًا.
- يعمل النطاق على قصر الرموز المميزة على مقدار محدّد ومحدود من بيانات المستخدم، والاطّلاع على نطاقات OAuth 2.0 لواجهات Google APIs للاطّلاع على مزيد من المعلومات.
- وضع النافذة المنبثقة عبارة عن تدفق لرمز التفويض يستند إلى استدعاء JavaScript الذي يتم تشغيله في متصفّح المستخدم. يستدعي محرّك البحث Google معالج الاتصال، وهو المسؤول عن إرسال رمز المصادقة إلى منصّتك.
- وضع إعادة التوجيه عبارة عن تدفق لرمز التفويض يستند إلى عمليات إعادة توجيه HTTP. تتم إعادة توجيه وكيل المستخدم إلى Google، وهي عملية إعادة توجيه ثانية من Google إلى نقطة نهاية رمز التفويض لنظامك الأساسي.
تحدِّد Google القيمة الدائمة منذ إنشاء البطاقة. ونظرًا لعوامل متعددة، قد تختلف المدة الدقيقة.
مسارات OAuth 2.0
تتم مناقشة مسارين، أحدهما ضمنيًا ورمز تفويض. يعرض كلا النوعين من هذين التطبيقين رمز دخول مناسبًا للاستخدام مع Google APIs.
ويُوصى بتدفق رمز التفويض لأنه يوفر أمانًا أفضل للمستخدم. وتعرض هذه العملية أيضًا رمزًا مميزًا لإعادة التحميل يمكن استخدامه للحصول على رموز الدخول بدون وجود المستخدم، ما يمكِّن نظامك الأساسي من تنفيذ إجراءات غير متزامنة بسهولة أكبر، مثل إرسال تذكير عبر الرسائل القصيرة لاجتماع قادم تم تحديد موعده في الدقيقة الأخيرة. اختيار نموذج التفويض يوضّح الاختلافات بين المسارين بمزيد من التفاصيل.
تتّبع مكتبة JavaScript لخدمات Google Identity معيار OAuth 2.0 من أجل:
- إدارة المسار الضمني لتفعيل تطبيق الويب داخل المتصفح من أجل الحصول بسرعة وسهولة على رمز الدخول من Google والذي يستدعي الاتصال بواجهات برمجة تطبيقات Google.
- ابدأ تدفق رمز التفويض من متصفح المستخدم.
الخطوات الشائعة
يبدأ تدفق كلٍّ من الرمز الضمني والتفويض بالطريقة نفسها:
- يطلب تطبيقك الوصول إلى نطاق واحد أو أكثر.
- يعرض محرّك البحث Google مربّع إفادة الموافقة على المستخدم، وعندما يسجّل المستخدم الدخول إلى حسابه على Google أولاً إذا لزم الأمر.
- يوافق المستخدم بشكل فردي على كل نطاق مطلوب.
وتنتهي كل عملية بخطوات مختلفة.
عند استخدام المسار الضمني
- تستخدم Google معالج معاودة الاتصال لإعلام تطبيقك بنتيجة الموافقة وعرض رمز الدخول لأي نطاقات معتمدة.
عند استخدام مسار رمز المصادقة
- تستجيب Google برمز تفويض لكل مستخدم:
- في وضع إعادة التوجيه، يتم إرجاع الرمز إلى نقطة نهاية رمز التفويض لنظامك الأساسي.
- في الوضع المنبثق، يتم إرجاع الرمز إلى معالج استدعاء التطبيق داخل المتصفّح، بدون الحاجة إلى مغادرة المستخدمين للموقع الإلكتروني.
- بدءًا من الخطوة 4: معالجة استجابة خادم OAuth 2.0 يعمل النظام الأساسي الخلفي على إكمال تبادل خادم إلى خادم مع Google، مما ينتج عنه في النهاية رمز مميز لإعادة التحميل لكل مستخدم ورمز دخول مميز يتم عرضه على نظامك الأساسي.
موافقة المستخدم
قبل الحصول على رمز الدخول المميز، يجب على المستخدمين الفرديين الموافقة على وصول تطبيقك إلى النطاقات المطلوبة. ولإجراء ذلك، يعرض محرّك البحث Google مربّع إفادة الموافقة خلال الخطوة الثانية أعلاه ويسجِّل النتيجة في 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 Identity لتقليل وقت التطوير والجهد والحد من المخاطر الأمنية، مثل ما هو موضّح في أفضل ممارسات الأمان الحالية في OAuth 2.0.