مقدمة
تحدثنا في المقالين السابقين من سلسلة المصادقة والتخويل عن مفهوم المصادقة (authentication)، التخويل (authorisation). تعلّمنا في المقالة الأولى ماهي مصادقة المستخدمين (user authentication)، وكيف تتم في الويب، واستعرضنا طريقتين لتطبيق المصادقة: باستخدام الجلسة (session)، وباستخدام الرموز (tokens).
قمنا في المقالة الثانية بالحديث بتفصيل أكبر عن المصادقة باستخدام الجلسة (Session-based authentication) وملفات تعريف الارتباط (Cookies). أما من خلال هذه المقالة، فسنوف نقوم بالتركيز على المصادقة باستخدام الرموز المهيكلة، وسنتطرق إلى رموز الويب المهيكلة (JSON Web Tokens) نظراً لشعبيتها وكفاءتها.
المصادقة "عديمة الحالة" (Stateless authentication)
يمكننا وصف المصادقة باستخدام الجلسة (Session-based authentication) بأنها متّسمة بالحالة (Stateful)، وذلك لأن المُخدّم يقوم بتخزين حالة (state) أو سياق (context) للمستخدم، تتضمن أنشطته السابقة في الموقع ضمن هذه الجلسة، مما يؤثر على كيفية استجابة المخدم للطلبات، وهذا يجعل طلبات الـ HTTP المتلاحقة مترابطة مع بعضها وتؤثر في بعضها (ولو أنها Stateless).
خلافا لذلك، تُوصَفُ المصادقة (والتخويل) باستخدام الرموز المهيكلة (token-based authentication) بأنها بدون حالة (stateless)، لأنه وعند استخدام هذا النوع من المصادقة والتخويل (authentication and authorisation)، ليس على المخدم أن يقوم بتخزين أو تتبع أي حالة أو سياق بخصوص المستخدم. هذا ولأن رمز المصادقة (authentication token) يتضمن عادة جميع المعلومات التي يتحاج المخدم إلى معرفتها، مرمّزة (encoded) بطريقة ما.
دعنا نفهم هذه الفكرة بشكل أكبر من خلال الحديث عن رموز الويب المهيكلة (JSON Web Tokens - JWTs) كمثال عن الرموز (tokens) المستخدمة في المصادقة والتخويل.
رموز الويب المهيكلة (JSON Web Tokens)
تعد المصادقة (والتخويل) باستخدام رموز الويب المهيكلة أو (JSON Web Tokens) - كما أحب أن أترجمها - من الأشكال الخاصة والمشوقة في مجال المصادقة، فهي تختلف تماما عن المصادقة باستخدام الجلسات، وقد ازداد استخدام هذه الطريقة مؤخراً في مجال الويب بشكل كبير.
مفاهيم أساسية
دعنا نطّلع أولا على ما تعنيه كلمة رموز الويب المهيكلة، ونتعرف على بعض المفاهيم الضرورية، ثم نرى كيف يتم استخدام هذه الرموز في المصادقة.
المصادقة باستخدام الرموز (token-based authentication)
المصادقة بستخدام الرموز هي بروتوكول يمكن المستخدمين من تأكيد هويتهم لدى المخدّم، واستلام رمز وصول فريد مقابل ذلك (unique access token). خلال فترة حياة هذا الرمز، يقوم المستخدمون باستخدام هذا الرمز للوصول إلى الموقع أو التطبيق الذي تم منح الرمز من أجله، بدلا من إعادة إرسال معلومات تسجيل الدخول مع كل طلب.
يلعب رمز المصادقة دور جواز سفر مختوم، يستطيع المستخدم الوصول إلى الموارد مازال هذا الرمز صالحاً. حالما يقوم المستخدم بتسجيل الخروج يتم إلغاء صلاحية هذا الرمز.
رموز الويب المهيكلة (JSON Web Tokens)
هي عبارة عن معيار مفتوح يٌقدّم طريقة فعالة، وقائمة بذاتها لنقل المعلومات بشكل آمن بصيغة JSON (كائنات الجافا سكربت). يمكن لمستقبل هذه المعلومات التحقق من صحتها والوثوق بها لأنه قد تم توقيعها رقميا. يمكن توقيع رموز الويب المهيكلة إما باستخدام تقنية مصادقة الرسائل باستخدام كود التجزئة (HMAC - Hash-based Message Authentication Code) ، أو باستخدام خوارزمية تشفير غير متناظر، مع مفتاحي تشفير عام وخاص (RSA أو ECDSA)
كائنات الجافا سكربت (JavaScript Object Notation - JSON)
هي صيغة معيارية تستخدم لنقل وتخزين البيانات، قابلة للقرءة من قبل الآلة والبشر. مثلا، الشكل التالي يمثل بيانات مُمَثّلة بصيغة JSON، حيث يمكن التعبير بسهولة عن البيانات الفردية (scalar items) مثل الأرقام والنصوص، المصفوفات أو القوائم، وكذلك البيانات المتداخلة (الكائنات objects).
تجزئة البيانات (Hashing)
تعني تطبيق خوارزمية حسابية معينة على البيانات لتحويلها من شكل إلى شكل آخر، عادة بشكل غير قابل للعكس. ينتج عن تطبيق خوارزمية التجزئة (Hashing) رمز (Hash Code) عادة ما يكون قصير أو محدد الطول (مهما كان حجم البيانات)، يتغير محتوى هذا الرمز بشكل جذري بمجرد إجراء أي تعديل طفيف على البيانات (في حال اختيار خوارزمية تجزئة جيدة). يعد التحقق من صحة البيانات من أهم تطبيقات خوارزميات التجزئة، بحيث يتم إرسال كود التجزئة (Hash code) مع البيانات. يقوم مستقبلو البيانات بتطبيق نفس خوارزمية التجزئة على البيانات المستلمة والتأكد من تطابق الرمز الناتج مع الرمز المستلم. اقرا المزيد عن تجزئة البيانات.
التوقيع الرقمي للبيانات - في علم تشفير - (Cryptography Digital signatures)
في العالم الحقيقي، يتم استخدام توقيع خط اليد لإثبات مصدر الرسالة، أو تبعيتها لموقّعها. وفي عالم التشفير الرقمي، يتم استخدام تقنيات التوقيع الرقمي أيضا لإثبات صحة البيانات، وملكيتها أو ارتباطها بالجهة الموقِّعة.
والتوقيع الرقمي بحد ذاته هو عبارة عن شيفرة يتم الحصول عليها بالاعتماد على محتوى البيانات المراد توقيعها، ومفتاح سري لا يملكه أحد سوى من يقوم بتوقيع البيانات، ويتم إرسال هذا التوقيع مع البيانات.
كما في العالم الحقيقي، حيث يتم استخدام التوقيع كي يستطيع مستقبل الرسالة التأكد من أن الشخص الموقع هو من قام بإرسال الرسالة، بحيث لا يمكن للمرسل إنكار قيامه بهذا الفعل، يتم استخدام التوقيع الرقمي لتأكيد هوية الجهة المرسلة للرسالة (أو البيانات)، بالإضافة الى ذلك، يستخدم للتأكد من سلامة البيانات: أي أنه وبعد أن قام المرسل بكتابة البيانات وتوقيعها، لم يتم إجراء أي تعديل على هذه البيانات (خلال التخزين أو الإرسال).
لتطبق هذه الآلية، وللتأكد من عدم قدرة أي جهة ما عدا المرسل من توقيع البيانات، مع تمكين مستلمي البيانات من التحقق من صحة التوقيع، يتم عادة استخدام خوارزميات التشفير غير المتناظر (تحتاج الى فهم المبادئ الأساسية فيها) حيث يحتاج مٌرسل (أو مٌوَقّع) البيانات في هذه الحالة إلى امتلاك مفتاح خاص يستخدمه للتوقيع، بحيث يكون هو فقط من يستطيع توقيع البيانات بهذا المفتاح، ويحتاج المستقبلون إلى امتلاك المفتاح العام المناظر له، والذي يُستخدم للتحقق من التوقيع، وفق خطوات معينة
كيف يتم ذلك؟ عادة يتم انشاء 'تجزئة' أو (Hash code) للبيانات المُراد توقيعها، ويتم تشفير النتيجة بمفتاح التشفير (أو مفتاح التوقيع) الخاص بالمرسل، ويتم إرفاق هذا التوقيع الناتج بالبيانات قبل إرسالها.
يقوم مستقبل البيانات باستخلاص البيانات المدعاة، والتوقيع المرفق. يقوم المستقبل باستخدام مفتاح التحقق (المفتاح العام أو مفتاح فك التشفير المنشور من قبل المرسل) لفك تشفير التوقيع المرسل، كما ويقوم بتطبيق خوارزمية التجزئة (Hashing) على البيانات المستلمة ويقارن رمز التجزئة (Hash code) الناتج بما حصل عليه من فك تشفير التوقيع. اذا تطابقت النتائج، بإمكان المستلم التأكد بأن البيانات الواصلة إليه قد تم فعلا إرسالها من قبل مالك المفتاح العام (المرسل)، وأنه هذه البيانات صحيحة كما أرسلت، ولم يتم إجراء أي تعديل عليها بعد توقيعها.
حسنا، سأكتفي هنا بالمفاهيم ودعنا ننتقل إلى شرح معيار رموز الويب المهيكلة (JSON Web Tokens - JWTs)
ماهي رموز الويب المهيكلة وكيف تعمل؟
تكلمنا في الأعلى عن المصادقة باستخدام الرموز بشكل عام. على الرغم من وجود بعض الرموز "المبهمة" (opaue tokens)، والمكونة من سلاسل نصية عشوائية بدون معنى، تبنى رموز الويب المهيكلة (JWTs) وفق هيكليه معينة، مكونة من ثلاث أقسام، تخزن وترسل كسلسلة نصية مفصولة بنقاط (من الشكل xxxx.yyyy.zzzz). هذه الأقسام تمثل:
- ترويسة (header): تضم عادة معلومتين، نوع الرمز (وهو JWT) وخوارزمية التوقيع المستخدمة (مثل HMAC SHA256 or RSA) توضعان ضمن هيكلية JSON ويتم ترميزها بصيغة Base64Url، مثال:
- الحمولة الفعلية (payload): وتمثل الإدعاءات التي يدعيها المرسل (عادة، المستخدم)، وأحيانا بيانات إضافية، مكتوبة بصيغة JSON. قد تحتوي هذه الإدعاءات على أشياء مثل معلومات المستخدم المرسل، الصلاحيات التي يتمتع بها، وغير ذلك. كذلك يتم ترميز هذه البيانات في الرمز الناتج بصيغة Base64Url. مثال عن البيانات قبل ترميزها:
هنا يدعي المرسل موضوعاً معيناً، اسماً معيناً وكذلك يدعي امتلاكه لصلاحية مدير.
- والتوقيع الرقمي (signature): لإنشاء التوقيع، يتم استخدام الترويسة المرمزة + الحمولة المرمزة، ويتم تطبيق خوارزمية التوقيع المذكورة، ومن ثم توقيعها باستخدام مفتاح خاص لا يمتلكه أحد باستثناء الجهة المانحة للتوقيع (عادة، المرسل).
يمكنك استكشاف هيكلية هذه الرموز، وتجربتها من خلال هذا الموقع.
كيف تستخدم رموز الويب المهيكلة في المصادقة والتخويل؟
١) يقوم المستخدم بتسجيل الدخول كالمعتاد، ويقوم المخدم بالتحقق من معلومات المستخدم السرية ومقارنتها مع قاعدة بياناته.
٢) حالما يتم التحقق، يستطيع المخدم التأكد من صلاحيات المستخدم، ويقوم بعدها بتوليد الرمز (بالصيغة الموصوفة سابقا) باستخدام رمز سري لا يملكه أحد باستثناء هذا المخدم. هذا الرمز يتضمن معلومات موقعة تحتوي على معلومات المستخدم (مثلا معرفه الشخصي، اسمه..)، صلاحيات المستخدم (permissions)، كما وتتضمن تاريخ انتهاء صلاحية الرمز، وغير ذلك.
توليد رمز المصادقة يتضمن أيضا توقيع هذا الرمز، بحيث يستطيع الآخرون لاحقا التأكد من أن المعلومات فيه أصلية وتم اقرارها من قبل المخدم.
لاحظ أنه لا يجب على المخدم تخزين رمز المصادقة الذي تم توليده، فلن يحتاج لذلك، بل يكتفي بإرساله الى المستخدم الذي طلب المصادقة.
٣) بعد أن حصل المستخدم (أو جهاز المستخدم) على رمز المصادقة، يقوم بإرسال هذا الرمز مرفقا بكل الطلبات اللاحقة المرسلة إلى الـ APIs في هذا المخدم أو المخدمات الأخرى التي تعتمد على خدمة المصادقة هذه (عادة باستخدام ترويسات الطلب HTTP Headers).
٤) تقوم المخدمات التي استقبلت الطلبات التي تحتاج إلى مصادقة بالتحقق من توقيع رمز المصادقة (بالتالي صحة الادعاءات في هذا الرمز) باستخدام المفتاح المخصص (عادة المفتاح العام)، بدون الحاجة إلى البحث عنها في قاعدة بياناتها.
كما رأينا، يحتوي هذا الرمز معلومات بصيغة JSON عادة ما تحوي معلومات المستخدم مثل معرفه الشخصي ID وأحيانا الصلاحيات المرفقة، مما يمكن المخدم في كثير من الأحيان من معالجة الطلبات بدون إجراء اتصالات اضافية إلى قاعدة البيانات لجلب بيانات المستخدم وصلاحياته. عملية التحقق من التوقيع هنا كافية للتأكيد أن هذا الرمز قد تم منحه من قبل خدمة المصادقة الموثوقة لدينا، وأنه لم يتم تعديله بعد ذلك، فيمكن للمخدم الوثوق بكامل محتوياته.
ملاحظة: بما أن رموز المصادقة هذه كافية لمصادقة المستخدم، فإنها أيضا معلومات سرية لا يجب على المستخدم مشاركتها مع أحد، وكما هو الحال مع باقي الرموز، يتم منح JWTs فترة صلاحية معينة، بعد انتهاءها يقوم السرفر برفض الرمز ويطلب من العميل (المستعرض، أو تطبيق الموبايل) تجديد الرمز (أي توليد رمز جديد)، عادة ما يتم ذلك بشكل اوتوماتيكي أو شفاف بالنسبة للمستخدم، باستخدام ما يسمى (refresh token).
مزايا رموز الويب المهيكلة، وحالات استخدامها
قابلية التوسع (scalability)
استخدام JWTs يوصف بأنه أكثر قابلية للتوسع (scalable)، أي مناسب في حال التطبيقات الكبيرة ذات الحمل العالي، لأنه لا يتطلب إجراء أي اتصالات إضافية الى قواعد البيانات للتحقق من المستخدم، على اعتبار أن الرمز قائم بذاته (self-contained). كما وأنه لا يتطلب تخزين جلسات المستخدم ولا حتى الرموز التي قام المخدم بتوليدها، كما هو الحال عند استخدام الرموز العادية، أو الجلسات المعتمدة على ملفات تعريف الارتباط.
القدرة على المصادقة والتخويل بشكل غير مركزي (Decentralised authentication / authorisation)
كما أحب أن أدعوها، ويمكن تحقيق ذلك من خلال استخدام التشفير غير المتناظر لتوقيع الرموز والتحقق منها.
هذا يعني أنه من الممكن الفصل ما بين خدمة المصادقة وباقي الخدمات التي تستخدم هذه المصادقة، بحيث تتم المصادقة من قبل خدمة منفصلة (داخلية أو خارجية) تتولى التحقق من بيانات المستخدمين السرية وأذوناتهم (permissions) قبل منحهم رموز المصادقة (authentication tokens).
يمكن بعدها للعميل (client) استخدام رموز المصادقة هذه للاتصال مع باقي الخدمات، والتي تستطيع بدورها التحقق من صحة الرموز ومصداقية محتوياتها (ادعاءاتها) باستخدام المفتاح العام لخدمة المصادقة المستخدمة.
مصادقة تطبيقات الهاتف المحمول، واتصالات خدمة لخدمة (service-to-service)
كما رأينا في مقالاتنا السابقة، لا تستطيع تطبيقات الهاتف المحمول استخدام ملفات تعريف الارتباط، كما وأن التطبيق يستطيع تخزين بعض معلومات الحالة محلياً، بالتالي جل ما يحتاج اليه هو خدمات (HTTP Services) وآلية آمنه للمصادقة، يمكن تحقيق ذلك بسهولة باستخدام رموز الويب المهيكلة (JWTs).
كما ويمكن استخدام هذه التقنية لمصادقة اتصالات الخدمات (backend services) بين بعضها البعض، بحيث يحمل الرمز معلومات الزبون طالب الخدمة (وهو هنا خدمة أخرى)، بالاضافة الى صلاحياته (والتي تم تحديدها وتصديقها من قبل خدمة مصادقة مركزية).
عيوب رموز الويب المهيكلة (JSON Web Tokens)، وحالات عدم الاستخدام
صعوبة سحب الرموز أو ابطال صلاحيتها (Revokable tokens)
كما رأيت، لا تقوم خدمة المصادقة عموماً بتخزين رموز المصادقة لديها، بل أن الرمز قائم بحد ذاته، وبعد توليده، يتم فقط إرساله الى المستخدم، بحيث يبقى صالحاً للاستخدام حتى انتهاء فترة صلاحيته (المحددة من قبل المخدم).
تعد القدرة على إبطال صلاحية الرموز مهمة في العديد من الحالات، مثلا: عند تسجيل المستخدم خروجه من النظام، أو عندما تتغير الصلاحيات المتاحة لهذا المستخدم، وغير ذلك. إذا كنت تستخدم JWTs وتعتمد على البيانات المخزنة ضمن هذه الرموز لإجراء المصادقة والتخويل، سيكون من الأصعب بقليل إلغاء صلاحية الرموز الممنوحة قبل انتهاء فترة صلاحيتها. على الرغم من ذلك، يبقى ذلك ممكنا، مثلا من خلال تخزين الرموز التي تم إلغاء صلاحيتها في نظام تخزين موزع مؤقت وسريع (مثل Redis)، ريثما تنتهي صلاحيتها الممنوحة.
إرسال البيانات الحساسة (Sensitive information)
بنيت رموز الويب المهيكلة لتجعل من إرسال البيانات المهيكلة (غير الحساسة) والتحقق من مصدرها، صحتها وسلامتها أمراً سهلاً. هذا يعني أنه يمكن لأي طرف قراءة هذه الرموز وفهم محتوياتها (بشكل عام). بالتالي لا يمكنك إرسال معلومات حساسة مثل كلمات المرور أو بيانات المستخدمين السرية ضمن JWTs (إلا في حال استخدام نوع خاص من رموز الويب، وهو رموز الويب المشفرة).
اقرأ أكثر
أنصحك بمواصلة القراءة والبحث كي تتعلم أكثر عن أي من المفاهيم غير المشروحة في هذه المقالة، إليك بعض الموارد التي يمكنك الاطلاع عليها
- تعلم أساسيات التشفير (فيديو بالعربية)
- تطبيق عملي لاستخدام رموز الويب المهيكلة (JWTs) في المصادقة، باستخدام NodeJS (مقال بالانكليزية)
في الختام
تعلمنا من خلال هذه المقالة كيف تعمل رموز الويب المهيكلة (JSON Web tokens)، وتطرقنا بشكل سريع إلى بعض المفاهيم المرتبطة في علم التشفير لفهم آلية عمل هذه الرموز. كما ورأينا متى يمكن استخدام رموز الويب المهيكلة، ومتى يفضل الابتعاد عنها.
سأواصل نشر المزيد من المقالات في هذا السياق، وسأحاول تقديم بعض الأمثلة التطبيقية لاحقا لوضع هذه المفاهيم في حيز التطبيق. تابعني على افق كي تتلقي الاشعارات بجميع المقالات اللاحقة.
صورة الغلاف من مدونة www.n-able.com
شكرا استاذ دريد على هالسلسلة من المقالات...كانت حلوة ومفيدة