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