العمارة عديمة الجنسية والدولة

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

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

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

مصادقة عديمي الجنسية

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

هذا الرمز المميز هو مخزن من جانب العميل (المتصفح)، وبالتالي فإن الخادم لديه القدرة فقط على التحقق من صلاحية الرمز المميز من خلال التأكد من تطابق الحمولة والتوقيع.

مصادقة عديمي الجنسية JWT

JSON Web Token (JWT) هي مفاتيح ذات معايير محددة في RFC-7519، تحتوي على كيان في شكل إعلانات، وهي مستقلة، دون الحاجة إلى استدعاء الخادم لإعادة التحقق من صحة الرمز المميز.

هل يتم ترميز السلاسل في معيار base64 باستخدام مفتاح سري، كما في المثال:

المزايا والعيوب

المزايا:

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

العيوب:

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

مصادقة الدولة

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

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

مثال للرمز المميز: 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

يجب تخزين هذا المعرف في قاعدة بيانات مع المستخدم الذي يملك الرمز المميز.

المزايا والعيوب

المزايا:

• منطق التنفيذ المركزي.
• إدارة الوصول والتحكم المبسط.
• ممتاز للوحدات المتراصة وتطبيقات MVC والعمليات الداخلية.
• أكثر أمانًا ضد الأطراف الثالثة الضارة.

العيوب:

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

متى تستخدم كل نهج؟

متى يتم استخدام رمز JWT والمصادقة عديمة الحالة

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

متى يتم استخدام رمز غير شفاف ومصادقة الحالة

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

الاعتبارات النهائية:

• في بعض الأماكن، مثل "ضغط API"، قد يتم استبدال المصطلح بـ "API overhead" للتوضيح.
• يمكن أن يتضمن القسم الخاص بـ "JWT Token" شرحًا أكثر تفصيلاً لماهية "التصريحات" المذكورة في RFC-7519، إذا كان الجمهور المستهدف يحتاج إلى مزيد من السياق.
• في القسم الخاص بالمصادقة ذات الحالة، يمكن توضيح العبارة "سيقوم جزء واحد من التطبيق بإنشاء الرمز المميز" من خلال توضيح الجزء المحدد من التطبيق المسؤول عن ذلك.