طَبِّقْهاتعلّم المبدأ، وطبّقه بيدكمقرر 243 · أمن الويب
الدرس 19 · الوحدة 8: تقنية OpenID Connect

تسجيل الدخول بمزوّد هوية في تطبيقك

بعد أن أثبت المزوّد الهوية، كيف تربطها بمستخدم في نظامك بأمان؟ ⏱ نحو 40 دقيقة.

بعد هذا الدرس ستستطيع أن:
  • تصف خطوات دمج «الدخول بمزوّد» حتى جلسة التطبيق.
  • تربط هوية المزوّد بحساب محلي بـ sub.
  • توازن بين الدخول بمزوّد وكلمات المرور المحلية.
  • تحدّد ما يبقى على تطبيقك رغم المزوّد.

١من التحقق إلى جلسة تطبيقك

بعد أن تحقّقت من id_token (الدرسان 17 و18)، تبقى خطوة: ربطه بمستخدم في نظامك. المزوّد يثبت الهوية، لكن الجلسة داخل تطبيقك جلستك أنت:

زر «الدخول بـ Google»

توجيه إلى مزوّد الهوية مع PKCE و state و nonce

المستخدم يصادق عند المزوّد

رجوع برمز تفويض

تبديله بـ id_token والتحقق منه

ربط sub بحساب محلي أو إنشاؤه

إنشاء جلسة في تطبيقك

من زر الدخول إلى جلسة محلية في تطبيقك.

المفتاح هو مطالبة sub: معرّف ثابت فريد للمستخدم عند المزوّد. تربطه بحساب محلي، فتعرف أن «جوجل‑سارة» هي صاحبة الحساب 1 في متجرك.

٢ربط الحساب

أول دخول: أنشئ حسابًا محليًّا واربط sub به. الدخول التالي: اعثر على الحساب بـ sub. لا تربط بـالبريد وحده؛ قد يتغيّر أو يُعاد استخدامه:

const express = require('express');const app = express();app.use(express.json());app.use(express.urlencoded({ extended: false })); const users = [{ id: 1, sub: 'google|111', name: 'سارة' }]; // بعد التحقق من id_token: اربط sub بحساب محلي أو أنشئ واحدًاapp.post('/oidc/callback', (req, res) => {  const sub = req.body.sub;                 // (بعد التحقق من التوقيع في الواقع)  let user = users.find(u => u.sub === sub);  if (!user) { user = { id: users.length + 1, sub, name: req.body.name }; users.push(user); }  res.json({ session: 'sess-' + user.id, name: user.name });   // جلسة تطبيقك أنت}); app.listen(3000);

الأول وجد حساب سارة بـ sub فأعاد جلستها. والثاني sub جديد فأنشأ حسابًا. الربط بـ sub ثابت لا بالبريد.

قرارتوصية
مفتاح الربطsub الثابت، لا البريد
البريد غير مُتحقَّقلا تثق به لربط حساب قائم
عدة مزوّديناسمح بربط أكثر من هوية بحساب واحد
الجلسةجلسة تطبيقك بعد التحقق، لا تمرير id_token في كل طلب

٣«الدخول بـ…» أم كلمات مرور محلية؟

الدخول بمزوّد (OIDC)كلمات مرور محلية
كلمات المرورلا تديرها أنتتخزّنها (مجزّأة) وتحميها
أمان المصادقةبخبرة المزوّد (2FA، كشف تسريب)على عاتقك
الاعتمادعلى توفّر المزوّد وسياساتهمستقل
الخصوصيةالمزوّد يعرف أين تسجّل الدخوللا طرف ثالث

كثير من التطبيقات تتيح الاثنين. وأيًّا اخترت، التحقق من id_token وإدارة الجلسة بأمان مسؤوليتك. والمزوّد يبسّط المصادقة لكنه لا يعفيك من تأمين التفويض (من يحق له ماذا) داخل تطبيقك.

توقّع وتحقّق

مفتاح ربط هوية المزوّد بحساب محلي:

بعد التحقق من id_token ننشئ:

الدخول بمزوّد يعفيك من:

الربط بالبريد غير المُتحقَّق يخاطر بـ:

الخلاصة

تحدٍّ تصميمي: خطة دمج «الدخول بمزوّد»

متوسط

يريد متجر «رفيق» إضافة «الدخول بـ Google». اكتب خطة الدمج بملء الحقول، مراعيًا الأمان.

المطلوب:
  • خطوات التدفق من زر الدخول إلى جلسة التطبيق (ثلاث خطوات على الأقل، كل خطوة في سطر).
  • بأي مطالبة تربط هوية Google بحساب محلي ولماذا.
  • مسؤوليتان أمنيتان تبقيان على المتجر رغم استخدام المزوّد.
✓ التحقق الآلي: يفحص المختبر بنية مستندك وصياغته (لا يحكم على جودة الفكرة؛ هذا دور معلمك)
  • ثلاث خطوات للتدفق
  • التدفق يذكر التحقق من id_token
  • الربط بـ sub
  • مسؤوليتان
  • مسؤولية التحقق أو التفويض

💡 تلميح 1
التدفق: توجيه بـ PKCE/state، ثم تبديل الرمز والتحقق، ثم ربط sub وإنشاء جلسة.
💡 تلميح 2
اربط بـ sub الثابت لا بالبريد المتغيّر.
💡 تلميح 3
يبقى على المتجر: التحقق من id_token، وتأمين التفويض والجلسات.

نموذج واحد من إجابات كثيرة صحيحة.

خطوات التدفق (سطر لكل خطوة)
توجيه المستخدم إلى Google مع PKCE و state و nonce.
استلام رمز التفويض وتبديله بـ id_token والتحقق منه كاملًا.
ربط sub بحساب محلي أو إنشاؤه، ثم إنشاء جلسة في المتجر.
مفتاح ربط الحساب وسببه
نربط بـ sub لأنه معرّف ثابت فريد عند المزوّد، بخلاف البريد الذي قد يتغيّر أو يُعاد استخدامه.
مسؤوليتان على المتجر
التحقق الكامل من id_token (التوقيع و iss و aud و exp).
تأمين التفويض داخل المتجر: من يحق له ماذا بعد الدخول.
انتقل إلى تقييم الدرساختيار من متعدد، وصح وخطأ، وأكمل الفراغ، وتتبّع الناتج.ابدأ التقييم ←

📝 معلم؟ أرسل ملاحظة للمؤلف عن هذا الدرس