إذا كنت مستخدمًا جديدًا أو غير معتاد على خدمات Google Identity أو تفويضًا، ابدأ بقراءة نظرة عامة.
تقدّم 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 API.
يُنصَح باستخدام مسار رمز التفويض لأنه يوفِّر أمانًا محسَّنًا للمستخدم. تعرض هذه العملية أيضًا رمزًا مميزًا لإعادة التحميل يمكن استخدامه للحصول على رموز دخول بدون مستخدم، ما يتيح لنظامك الأساسي تنفيذ الإجراءات غير المتزامنة بسهولة أكبر، مثل إرسال تذكير عبر الرسائل القصيرة (SMS) لاجتماع قادم تم تحديد موعده في الدقيقة الأخيرة. ويفسّر اختيار نموذج تفويض الاختلافات بين المسارين بمزيد من التفاصيل.
تتّبع مكتبة JavaScript في خدمات Google Identity معيار OAuth 2.0 لإجراء ما يلي:
- إدارة المسار implicit لتمكين تطبيق الويب في المتصفح من الحصول على رمز الدخول من Google اللازم لاستدعاء واجهات Google API بسرعة.
- ابدأ تدفق رمز التفويض من متصفّح المستخدم.
الخطوات الشائعة
يبدأ تدفق كل من التدفّق الضمني ورمز التفويض بالطريقة نفسها:
- يطلب تطبيقك الوصول إلى نطاق واحد أو أكثر.
- يعرض محرّك بحث 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.