تسجيل الدخول بمزوّد هوية في تطبيقك
بعد أن أثبت المزوّد الهوية، كيف تربطها بمستخدم في نظامك بأمان؟ ⏱ نحو 40 دقيقة.
- تصف خطوات دمج «الدخول بمزوّد» حتى جلسة التطبيق.
- تربط هوية المزوّد بحساب محلي بـ
sub. - توازن بين الدخول بمزوّد وكلمات المرور المحلية.
- تحدّد ما يبقى على تطبيقك رغم المزوّد.
١من التحقق إلى جلسة تطبيقك
بعد أن تحقّقت من id_token (الدرسان 17 و18)، تبقى خطوة: ربطه بمستخدم في نظامك. المزوّد يثبت الهوية، لكن الجلسة داخل تطبيقك جلستك أنت:
المفتاح هو مطالبة 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 ننشئ:
الدخول بمزوّد يعفيك من:
الربط بالبريد غير المُتحقَّق يخاطر بـ:
الخلاصة
- بعد التحقق من
id_token، أنشئ جلسة في تطبيقك واربطsubبحساب محلي. - اربط بـ
subالثابت لا بالبريد المتغيّر؛ وإلا خطر الاستيلاء على الحساب. - الدخول بمزوّد يعفيك من كلمات المرور، لا من التحقق والتفويض والجلسات.
- كثير من التطبيقات يتيح الدخول بمزوّد وكلمات محلية معًا.
تحدٍّ تصميمي: خطة دمج «الدخول بمزوّد»
متوسطيريد متجر «رفيق» إضافة «الدخول بـ Google». اكتب خطة الدمج بملء الحقول، مراعيًا الأمان.
- خطوات التدفق من زر الدخول إلى جلسة التطبيق (ثلاث خطوات على الأقل، كل خطوة في سطر).
- بأي مطالبة تربط هوية Google بحساب محلي ولماذا.
- مسؤوليتان أمنيتان تبقيان على المتجر رغم استخدام المزوّد.
- ثلاث خطوات للتدفق
- التدفق يذكر التحقق من id_token
- الربط بـ sub
- مسؤوليتان
- مسؤولية التحقق أو التفويض
💡 تلميح 1
PKCE/state، ثم تبديل الرمز والتحقق، ثم ربط sub وإنشاء جلسة.💡 تلميح 2
💡 تلميح 3
نموذج واحد من إجابات كثيرة صحيحة.
- خطوات التدفق (سطر لكل خطوة)
- توجيه المستخدم إلى Google مع PKCE و state و nonce.
استلام رمز التفويض وتبديله بـ id_token والتحقق منه كاملًا.
ربط sub بحساب محلي أو إنشاؤه، ثم إنشاء جلسة في المتجر. - مفتاح ربط الحساب وسببه
- نربط بـ sub لأنه معرّف ثابت فريد عند المزوّد، بخلاف البريد الذي قد يتغيّر أو يُعاد استخدامه.
- مسؤوليتان على المتجر
- التحقق الكامل من id_token (التوقيع و iss و aud و exp).
تأمين التفويض داخل المتجر: من يحق له ماذا بعد الدخول.