سلسلة المصادقة (الجزء الأول): ممارسات هندسة التطبيقات

مقدمة

تلعب المصادقة على الهوية دورًا حاسمًا في حماية وصول البيانات وخصوصية المستخدم في تطبيقات الإنترنت، خاصة بالنسبة للتطبيقات الداخلية للشركات. في هذه السلسلة من المقالات، سنستكشف المصادقة على الهوية من وجهات نظر مختلفة، مع التركيز بشكل خاص على ممارسات المصادقة على الهوية في هندسة التطبيقات في هذه المقالة.

في التطبيقات المختلفة، تستخدم المصادقة على الهوية عادةً التقنيتين التاليتين:

1. الكوكيز والجلسات (Cookie & Session): هذه الآلية التقليدية للمصادقة تُستخدم على نطاق واسع في تطبيقات الويب، بشكل أساسي داخل المتصفحات. تقوم بتحقق هوية المستخدم والحفاظ على حالة الجلسة باستخدام الكوكيز والجلسات.

2. رمز الحامل (Bearer Token): هذه آلية مصادقة أكثر حداثة تزيل الاعتماد على كوكيز المتصفحات وتستخدم بروتوكول HTTP للمصادقة. وهي مناسبة بشكل خاص لسيناريوهات API ويمكن استخدامها في تطبيقات الهواتف المحمولة.

بغض النظر عن الطريقة المختارة، يحتاج المطورون إلى اختيار نهج المصادقة المناسب لمنتجاتهم لضمان أمان البيانات وخصوصية المستخدم وتجربة مستخدم سلسة.

تطبيقات الويب التقليدية

في الماضي، كنا نستخدم Java JSP لبناء تطبيقات الويب مباشرة، مع تحديد المستخدمين باستخدام JSESSIONID، وهو معرف الجلسة المخزن في كوكي على متصفح العميل ويتم نقله مع كل طلب.

ومع ذلك، كانت لهذه الطريقة بعض المشكلات. نظرًا لأن الكوكيز يتم إدارتها وتخزينها على جهاز العميل بواسطة المتصفح، يمكن للمهاجمين الخبثاء سرقة معرف الجلسة المخزن وانتحال هوية المستخدم، مما يشكل خطرًا أمنيًا. بالإضافة إلى ذلك، كان المطورون أحيانًا يواجهون صعوبة في تحديد فترات انتهاء الصلاحية المناسبة ومتطلبات الأمان للكوكيز والجلسات.

عند تطوير هذه التطبيقات، كان على المطورين غالبًا تنفيذ المصادقة بشكل منفصل لكل نظام، مما كان مستقلًا ويستخدم أنظمة هوية مختلفة. هذا تطلب عملًا متكررًا. في مثل هذه الحالات، يمكن لـ المصادقة الموحدة (Single Sign-On - SSO) معالجة هذه التحديات باستخدام نظام مصادقة موحد، مما يتطلب الحد الأدنى من العمل التكاملي في كل تطبيق ويب فردي لتحقيق وظيفة المصادقة.

في السنوات الأخيرة، شهدت تقنيات الواجهة الأمامية والخلفية تقدمًا سريعًا. بدأ المطورون في الانتقال إلى تقنيات أكثر حداثة، تاركين التطبيقات التي تعمل بتقنيات قديمة كمنصات قديمة. ومع ذلك، هناك حالات تظهر فيها متطلبات أمنية جديدة للهوية، ولكن تعديل الكود القديم غير ممكن. في مثل هذه الحالات، يمكن استخدام نهج بديل يتمثل في استخدام وسيط يعمل كخادم وكيل عكسي لإجراء المصادقة. قبل وصول العميل إلى التطبيق، يقوم الوسيط بإعادة توجيه المستخدم إلى واجهة مصادقة خارجية، حيث يقوم المستخدم بتسجيل الدخول. ثم يحصل الوسيط على معلومات هوية المستخدم ويربطها بالطلب قبل تمريرها إلى التطبيق القديم. هذا يمكّن المطورين من إضافة آليات مصادقة جديدة إلى التطبيقات القديمة دون تعديل الكود الحالي.

تطور تطبيقات الويب: فصل الواجهة الأمامية عن الخلفية

مع ظهور تقنيات واجهة أمامية جديدة مثل Vue وReact، تم إحداث ثورة في تفاعلات الويب. في الماضي، كان على المستخدمين ملء النماذج وإرسالها على صفحات الويب، والتفاعل مع الخلفية باستخدام نماذج HTML والأزرار، مما لم يوفر تجربة مستخدم سلسة. الآن، التفاعلات على الصفحة تكون في الوقت الفعلي، ويستخدم المطورون نصوص JavaScript للتفاعل مع واجهات برمجة التطبيقات (APIs) الخلفية، مما يوفر تجربة أكثر اتساقًا واستمرارية. تحولت تفاعلات المستخدمين من طلبات HTTP المباشرة إلى استدعاء واجهات برمجة التطبيقات المختلفة.

هناك بعض الاختلافات في آليات المصادقة على الهوية بين التطبيقات الموجهة لصفحات الويب والتطبيقات الموجهة لواجهات برمجة التطبيقات. بينما لا يزال يمكن استخدام الكوكيز القديمة، إلا أنها ليست مناسبة لتقنيات الواجهة الأمامية الحديثة. تمنح التقنيات الجديدة المطورين كودًا أكثر تعبيرًا، مما يسمح لهم بتنفيذ المزيد من العمليات، بما في ذلك السيناريوهات التي قد نحتاج فيها إلى تبديل حسابات المستخدمين على الواجهة الأمامية. ومع ذلك، فإن تنفيذ ذلك مباشرة على الواجهة الأمامية باستخدام الكوكيز يمثل تحديًا (لأسباب أمنية، غالبًا ما يتم تكوين الكوكيز المتعلقة بهوية المستخدم كـ httpOnly، مما يمنع نصوص JavaScript من قراءتها ومعالجتها).

عادةً ما تدير تطبيقات الواجهة الأمامية الحديثة جلسات المستخدمين بأنفسها. بمجرد تسجيل دخول المستخدم بنجاح، تدير الواجهة الأمامية الرمز المميز (token) الذي تم إنشاؤه بواسطة الخلفية وتضيفه إلى رأس الطلب عند استدعاء واجهات برمجة التطبيقات للخلفية لتحديد هوية المستخدم. تستخدم واجهات برمجة التطبيقات الرموز المميزة لتحديد معلومات المستخدم. هناك وسائل تقنية متعددة متاحة، مثل تنفيذ آليات الرموز المميزة يدويًا باستخدام JSON Web Tokens (JWT). يحمل JWT معلومات تعريفية مثل معرف المستخدم، ثم يتم توقيعه للسماح للخلفية بالتحقق من الرمز المميز واسترداد معلومات هوية المستخدم.

ومع ذلك، فإن JWT لديها أيضًا بعض العيوب، مثل:

• وقت انتهاء صلاحية JWT ثابت ولا يمكن تعديله بمجرد اكتمال التوقيع. نظرًا لأنه عادةً لا يتم تخزينه بواسطة الخلفية ويخضع فقط للتحقق من التوقيع، لا يمكن إلغاء الرمز المميز، مما يشكل خطر سرقة الرمز المميز.

• يتم تخزين بيانات الحمولة (payload) كنص عادي ويمكن للعميل تحليلها، مما يجعلها غير مناسبة لتخزين المعلومات السرية.

لحسن الحظ، هناك الآن مواصفات جديدة لـ JWT لمعالجة هذه العيوب. يمكن أن يتضمن JWT حقلًا يسمى "jti" لتخزين معرف فريد لـ JWT، والذي يمكن تخزينه في ذاكرة التخزين المؤقت للخلفية للتحكم في دورة حياة JWT. بالإضافة إلى ذلك، تحدد مواصفات JSON Web Encryption (JWE) امتدادًا مشفرًا لـ JWT يجمع بين مزايا التشفير غير المتماثل والمتماثل، مما يضمن نقل الحمولة بشكل مشفر لمنع التسريب.

علاوة على ذلك، هناك تقنيات أخرى قائمة على JWT توفر حلولًا أكثر نضجًا، مثل OpenID Connect. من المهم ملاحظة أن OpenID Connect لا يعتمد على JWT، ولكن يمكن استخدامهما معًا. يقوم OpenID Connect بتوحيد آليات الرموز المميزة للوصول والرموز المميزة للتحديث، مما يسمح للمطورين باستخدام الرموز المميزة قصيرة الأجل لتخفيف خطر سرقة الرمز المميز. كما أن نظام OpenID Connect مزدهر أيضًا، مع توفر العديد من تطبيقات الخوادم والعملاء لمساعدة المطورين على بناء أنظمة مصادقة على الهوية بناءً على بروتوكول OpenID Connect. بالإضافة إلى ذلك، يمكن لحلول المصادقة على الهوية مفتوحة المصدر مثل Keycloak مساعدة المطورين في تنفيذ خدمات مصادقة على الهوية آمنة.

تقدم ممارسات تقنيات الواجهة الأمامية الجديدة، مثل Next.js، تقنيات عرض الخادم (server-side rendering) إلى مجال الواجهة الأمامية. يمثل هذا تطورًا جديدًا لنموذج تطوير الويب القديم، حيث يتم دمج React مع برامج الخلفية لتعزيز تجربة المستخدم بشكل أكبر. هناك الآن المزيد من المكتبات، مثل NextAuth، التي يمكن أن تساعد المطورين في تنفيذ المصادقة على الهوية باستخدام هذه الآلية، مما يجعل عملية المصادقة أكثر ملاءمة للمطورين.

بوابات API والمصادقة على الهوية

لنفكر في كيفية تفاعل تطبيقاتنا المحمولة مع البيانات. هل تستخدم أيضًا واجهات برمجة التطبيقات؟ في التطبيقات المحمولة، لا توجد آلية كوكيز مثل المتصفحات لتخزين جلسات المستخدم، لذا فهي تستخدم بشكل أساسي الرموز المميزة لنقل المعلومات من خلال رؤوس طلبات HTTP.

ماذا عن خدمات API؟ يتكون الخلفية الناجحة للتطبيق عادةً من العديد من أنظمة API المعقدة التي تتطلب آلية مصادقة موحدة على الهوية. وإلا، سيتعين على المطورين تنفيذ نفس آلية المصادقة لكل خدمة، مما سيكون مرهقًا.

يمكن أن تساعدنا بوابات API في حل هذه المشكلة من خلال التعامل مع مهام المصادقة والتحليل المشابهة للكوكيز أو الرموز المميزة، وتمرير معلومات الهوية المحللة مباشرة إلى خدمات الخلفية، مما يقلل من التكرار في العمل. تدعم Apache APISIX وAPI7 Enterprise أيضًا وظيفة المصادقة باستخدام OpenID Connect جاهزة للاستخدام، مما يساعد المستخدمين على دمج خدمات المصادقة على الهوية مباشرة. بالإضافة إلى ذلك، تدعم بوابات API تنفيذ أي آلية مصادقة من خلال البرمجة النصية، لذا حتى مع وجود آليات مصادقة مخصصة، يمكن دمجها على بوابة API، مما يبسط تطوير التطبيقات.

الخلاصة

دفع تطور طرق تفاعل المستخدمين إلى تقدم في المصادقة على الهوية. أصبح النهج المرتكز على واجهات برمجة التطبيقات اتجاهًا سائدًا، وقد يتم توفير واجهات برمجة التطبيقات بواسطة بنى الخدمات المصغرة، مما يتطلب آلية مصادقة موحدة على الهوية لتقليل التطوير الزائد. لذلك، يجب علينا اختيار آليات أكثر حداثة مثل OpenID Connect وJWT، واستخدام بوابة API يمكن أن يوفر وظائف إضافية لتطوير واجهات برمجة التطبيقات.