ما هي المصادقة (Authentication)؟ تسجيل الدخول والجلسات وOAuth بشرح مبسط
المصادقة (Authentication) هي الطريقة التي يتأكد بها التطبيق من هوية المستخدم، وعادةً عبر التحقق من شيء يعرفه المستخدم (كلمة مرور)، أو شيء يملكه (رمز يُرسل إلى هاتفه أو بريده)، أو هوية من خدمة موثوقة أخرى (مثل «تسجيل الدخول باستخدام Google»). بعد أن يتحقق التطبيق من المستخدم، يتذكره عبر جلسة (session) أو رمز (token)، فلا يحتاج إلى تسجيل الدخول في كل صفحة. أما تحديد ما يحق لهذا المستخدم المعروف فعله، فهذه خطوة منفصلة تسمى التفويض (Authorization).
لماذا تهم المصادقة عند البناء بالذكاء الاصطناعي؟
إضافة تسجيل الدخول من أكثر الطلبات شيوعاً من أدوات البناء بالذكاء الاصطناعي، ومن أسهلها أن تُنفَّذ بشكل خاطئ بخفاء. صفحة تسجيل الدخول سهلة التوليد. الجزء الصعب هو كل ما حولها:
- هل كلمات المرور مخزّنة بأمان؟
- هل تتحقق كل صفحة خاصة وكل نقطة API من هوية الطالب فعلاً؟
- هل يستطيع عميل مسجل دخوله رؤية بيانات عميل آخر بتغيير رقم في الرابط؟
- ماذا يحدث عندما ينسى أحدهم كلمة المرور؟
يمكن أن يبدو التطبيق آمناً تماماً بينما يفشل في كل واحدة من هذه النقاط. فهم الأجزاء المتحركة يساعدك على طرح الأسئلة الصحيحة واختبار الأشياء الصحيحة.
تشبيه من الحياة اليومية
فكّر في تسجيل الوصول في فندق.
عند مكتب الاستقبال تُبرز هويتك. هذه المصادقة: إثبات من أنت. ثم يعطيك موظف الاستقبال بطاقة مفتاح. هذه البطاقة هي جلستك: طوال إقامتك لا تُبرز هويتك مجدداً، بل تستخدم البطاقة.
تفتح البطاقة غرفتك والنادي الرياضي والمصعد إلى طابقك، لكنها لا تفتح غرف النزلاء الآخرين ولا مكتب الإدارة. هذا هو التفويض: ما تسمح به هويتك من الوصول. إذا فقدت البطاقة يمكن للفندق تعطيلها عند المكتب (إلغاء الجلسة). وعند المغادرة تتوقف عن العمل (تسجيل الخروج أو انتهاء الصلاحية).
«تسجيل الدخول باستخدام Google» مثل فندق يقبل خطاباً من شريك موثوق يقول «هذا هو صاحب البطاقة»، بدلاً من أن يتحقق من هويتك بنفسه.
طرق تسجيل الدخول الرئيسية
| الطريقة | كيف تعمل | المزايا | العيوب |
|---|---|---|---|
| البريد وكلمة المرور | يختار المستخدم كلمة مرور، ويخزّن التطبيق تجزئتها | مألوفة، ولا تعتمد على جهة خارجية | يجب تخزين التجزئات بأمان والتعامل مع إعادة التعيين |
| رابط سحري / رمز لمرة واحدة | يرسل التطبيق رابطاً أو رمزاً عبر البريد يسجل الدخول | لا كلمات مرور تُسرق أو تُنسى | يعتمد على وصول البريد، وتسجيل الدخول أبطأ |
| تسجيل دخول اجتماعي (OAuth / OpenID Connect) | تسجيل الدخول بحساب Google أو Apple أو GitHub وغيرها | سريع للمستخدمين، ولا تخزّن كلمة مرور | إعداد لكل مزود، والمستخدمون بلا تلك الحسابات |
| مزود مصادقة مستضاف | خدمة مثل Clerk أو Auth0 أو Supabase Auth تتولى التسجيل والدخول وإعادة التعيين | عمل أمني أقل عليك | تكلفة شهرية مع النمو، واعتماد إضافي |
| المصادقة متعددة العوامل (MFA / 2FA) | تحقق ثانٍ بعد الأول، مثل رمز من تطبيق المصادقة | يصعب اختراقه كثيراً | احتكاك أكبر قليلاً |
كيف يجب تخزين كلمات المرور
التطبيق الآمن لا يخزّن كلمة مرورك الفعلية، بل يخزّن تجزئة (hash): ناتج دالة أحادية الاتجاه تحوّل كلمة المرور إلى سلسلة ثابتة الطول. عند تسجيل الدخول يجزّئ التطبيق ما كتبته ويقارن النتيجة بالتجزئة المخزنة.
هناك تفصيلان يجعلان هذا آمناً:
- الملح (Salt): قيمة عشوائية تُضاف إلى كل كلمة مرور قبل التجزئة، فيحصل شخصان بالكلمة نفسها على تجزئتين مختلفتين، ولا تنفع جداول البحث المحسوبة مسبقاً.
- خوارزمية بطيئة مصممة لكلمات المرور، مثل Argon2 أو bcrypt أو scrypt. التجزئات العامة مثل MD5 أو SHA-256 سريعة جداً وحدها؛ إذ يستطيع المهاجم تجربة مليارات التخمينات.
التجزئة ليست تشفيراً. البيانات المشفّرة يمكن فكّها بمفتاح، أما تجزئة كلمة المرور فمصممة لألا تكون قابلة للعكس أصلاً.
الجلسات مقابل الرموز
بعد تسجيل الدخول يحتاج التطبيق إلى التعرف عليك في كل طلب. هناك نهجان شائعان.
| الجلسة (ملف تعريف ارتباط) | الرمز (مثل JWT) | |
|---|---|---|
| ما يحمله المتصفح | معرّف جلسة عشوائي في ملف تعريف ارتباط | رمز موقّع يحتوي معلومات المستخدم وتاريخ انتهاء |
| أين توجد حالة الدخول | على الخادم، في قاعدة بيانات أو مخزن | داخل الرمز نفسه |
| تسجيل خروج شخص من كل الأجهزة | سهل: احذف الجلسة من الخادم | أصعب: يبقى الرمز صالحاً حتى ينتهي إلا إذا احتفظت بقائمة حظر |
| الاستخدام المعتاد | تطبيقات الويب التقليدية | واجهات API وتطبيقات الجوال والخدمات المتصلة ببعضها |
بالنسبة لملفات تعريف الارتباط، هناك ثلاثة إعدادات مهمة: HttpOnly (لا يستطيع JavaScript في الصفحة قراءة الملف)، وSecure (يُرسل عبر HTTPS فقط)، وSameSite (يحد من إرساله في الطلبات القادمة من مواقع أخرى). تخزين الرموز في localStorage للمتصفح شائع، لكنه يعرّضها لأي سكربت يعمل في الصفحة.
OAuth و«تسجيل الدخول باستخدام Google»
OAuth 2.0 معيار للتفويض المفوَّض (delegated authorization): يسمح لتطبيق بالحصول على صلاحية محدودة لحسابك في خدمة أخرى، كقراءة تقويم Google مثلاً، دون أن يرى كلمة مرور Google الخاصة بك أبداً. تُحوَّل إلى Google، فتوافق على صلاحيات محددة (تسمى النطاقات / scopes)، ويعطي Google التطبيق رمزاً لتلك الصلاحيات وحدها.
صُمم OAuth في الأصل لمنح الوصول، لا لتحديد من أنت. أما OpenID Connect (OIDC) فهو طبقة فوق OAuth 2.0 تضيف الهوية، وهي ما يستخدمه «تسجيل الدخول باستخدام Google» أو «تسجيل الدخول باستخدام Apple». للإعداد تسجّل تطبيقك لدى المزود وتحصل على معرّف العميل (client ID) والسر (client secret)، ويبقى السر على خادمك.
مثال عملي: تسجيل الدخول لبوابة عملاء
لنفترض أنك تبني بوابة تعرض فيها شركة تصميم لعملائها مشاريعهم وفواتيرهم.
- المصادقة: يسجل العملاء الدخول بالبريد عبر رابط سحري، فلا توجد كلمات مرور تُدار. يسجل موظفو الوكالة الدخول بحسابات Google Workspace.
- الأدوار: لكل مستخدم دور، إما
clientأوstaff. - قواعد التفويض:
| الإجراء | العميل | الموظف |
|---|---|---|
| رؤية مشاريع شركته | نعم | نعم |
| رؤية مشاريع شركات أخرى | لا | نعم |
| رفع ملف إلى مشروع | لمشاريعه فقط | نعم |
| تحديد فاتورة كمدفوعة | لا | نعم |
- مكان التطبيق: على الخادم، في كل طلب. يبحث الخادم عن المستخدم المسجل دخوله، ثم يعيد المشاريع التي يطابق فيها
project.company_idشركة المستخدم فقط. إخفاء زر «تحديد كمدفوعة» لا يكفي، فنقطة النهاية نفسها يجب أن ترفض الطلب.
شرح المصطلحات الشائعة
| المصطلح | المعنى |
|---|---|
| Authentication / AuthN (المصادقة) | التحقق من هوية الشخص. |
| Authorization / AuthZ (التفويض) | تحديد ما يحق له فعله. |
| Session (الجلسة) | تذكّر التطبيق أنك مسجل دخولك بين الطلبات. |
| Cookie (ملف تعريف الارتباط) | قطعة صغيرة من البيانات يرسلها المتصفح للموقع مع كل طلب. |
| JWT | JSON Web Token: رمز مضغوط وموقّع يحمل معلومات مثل معرّف المستخدم وتاريخ الانتهاء. |
| Role / permission (الدور / الصلاحية) | تسميات مثل admin أو member تحدد الوصول. |
| MFA / 2FA | اشتراط إثبات ثانٍ، كرمز من تطبيق مصادقة. |
| SSO | تسجيل الدخول الموحد: دخول واحد (غالباً بحساب الشركة) لتطبيقات كثيرة. |
| 401 مقابل 403 | «من أنت؟» (غير مصادق) مقابل «لا يحق لك ذلك» (غير مفوّض). |
أخطاء ومفاهيم خاطئة شائعة
- التحقق من الصلاحيات في الصفحة فقط. إذا أخفى المتصفح زراً لكن الـ API لا يتحقق، يستطيع أي شخص استدعاء الـ API مباشرة.
- الثقة بالمعرّفات القادمة من الرابط. يجب أن يتحقق
/invoices/1042من أن الفاتورة 1042 تنتمي للمستخدم المسجل دخوله. - اختراع التشفير بنفسك. استخدم مكتبات معروفة أو مزودين موثوقين، ولا تترك الذكاء الاصطناعي يخترع مخطط تجزئة خاصاً.
- إعادة تعيين كلمة مرور ضعيفة. يجب أن تكون روابط إعادة التعيين لمرة واحدة، وتنتهي بسرعة، ولا تكشف إن كان البريد مسجلاً.
- الخلط بين تسجيل دخولك وتسجيل دخول أداة البناء. مستخدمو تطبيقك منفصلون عن حسابك في الأداة التي تبني بها.
- عدم تحديد عدد محاولات تسجيل الدخول. بدون ذلك يستطيع المهاجمون تجربة كلمات المرور بلا حدود.
ماذا تطلب من أداة البناء بالذكاء الاصطناعي؟
- «أضف التسجيل وتسجيل الدخول باستخدام [مكتبة أو مزود معروف]. لا تكتب تجزئة كلمات مرور مخصصة.»
- «خزّن كلمات المرور مجزّأة باستخدام bcrypt أو Argon2.»
- «استخدم ملف تعريف ارتباط HttpOnly وSecure للجلسة.»
- «أضف الأدوار: admin وmember. اعرض كل نقطة API والأدوار المسموح لها باستدعائها.»
- «تأكد على الخادم من أن المستخدمين يقرؤون ويعدّلون سجلاتهم فقط. ثم أرني كيف تحققت من ذلك.»
- «أضف إعادة تعيين كلمة المرور بروابط لمرة واحدة تنتهي خلال ساعة.»
- «حدّد عدد محاولات تسجيل الدخول.»
ثم اختبر بنفسك: أنشئ حسابين وحاول الوصول إلى بيانات أحدهما وأنت مسجل بالآخر. يتناول دليل إضافة تسجيل الدخول إلى تطبيقك وقائمة فحص الأمان المزيد.
المصادقة في Mythex
لا يوفر Mythex منتجاً مدمجاً للمصادقة لمستخدمي تطبيقك؛ بل تختار أسلوباً، مثل البريد وكلمة المرور المخزنة في قاعدة بيانات مشروعك، أو SDK لمزود مستضاف، وتطلب من الوكيل إضافته. مفاتيح المزودين تُوضع في أسرار المشروع، لا في المحادثة. هذا منفصل عن طريقة تسجيل دخولك إلى Mythex نفسه. توفر وصفة التوثيق إضافة تسجيل الدخول إلى تطبيقك طلباً جاهزاً تستطيع تكييفه، ويشرح ما هي واجهة API مكان هذه الفحوصات على الخادم.
الأسئلة
ما الفرق بين المصادقة (Authentication) والتفويض (Authorization)؟
المصادقة تتحقق من هويتك، مثلاً بالتحقق من كلمة المرور. أما التفويض فيحدد ما يحق لك فعله بعد معرفة هويتك، مثل هل يمكنك رؤية صفحة الإدارة أو تعديل حجز شخص آخر. التطبيقات تحتاج إلى الاثنين.
ما هو OAuth؟
OAuth 2.0 معيار يسمح لتطبيق بالحصول على صلاحية محدودة لحسابك في خدمة أخرى دون أن يرى كلمة مرورك. تستخدم خاصية «تسجيل الدخول باستخدام Google» بروتوكول OpenID Connect، وهو طبقة هوية مبنية فوق OAuth 2.0، فيتعرف التطبيق على هويتك من Google.
هل يجب أن يخزّن تطبيقي كلمات المرور؟
لا، ليس بصيغة قابلة للقراءة أبداً. إذا استخدمت تسجيل الدخول بالبريد وكلمة المرور، فيجب تخزين كلمات المرور كتجزئات (hashes) مملّحة (salted) باستخدام خوارزمية بطيئة مصممة لكلمات المرور، مثل Argon2 أو bcrypt. وكثير من التطبيقات تتجنب المشكلة كلياً باستخدام مزود مصادقة مستضاف، أو تسجيل دخول عبر حسابات التواصل، أو روابط سحرية (magic links) عبر البريد.
الجلسات أم الرموز (Tokens)، أيهما يستخدم تطبيقي؟
كلاهما يعمل. الجلسة تخزن حالة تسجيل الدخول على الخادم، وتعطي المتصفح معرّفاً عشوائياً في ملف تعريف ارتباط (cookie)، وهي سهلة الإلغاء. أما الرمز مثل JWT فيحمل المعلومات الموقّعة بداخله، وهو مناسب لواجهات API وتطبيقات الجوال، لكن إلغاءه قبل انتهاء صلاحيته أصعب. في تطبيق ويب تقليدي، تكون الجلسات المعتمدة على ملفات تعريف الارتباط خياراً افتراضياً سليماً.