مناقشة الجلسة مقابل الرمز المميز

مصادقة الجلسة (الكلاسيكية):

يقوم المستخدم بتسجيل الدخول.
يقوم الخادم بإنشاء معرف الجلسة (sess_123). يخزنه في الذاكرة/Redis.
يرسل الخادم المعرف إلى ملف تعريف ارتباط العميل.
يرسل العميل ملف تعريف الارتباط.
يبحث الخادم عن sess_123 في Redis. يجد “المستخدم هو بوب”. الإيجابيات: قابل للإلغاء (الحذف من Redis = قام المستخدم بتسجيل الخروج). ** سلبيات **: Statefull. أنت بحاجة إلى ريديس. من الصعب التوسع عبر المناطق.

** مصادقة JWT (الحديثة) **:

يقوم المستخدم بتسجيل الدخول.
يقوم الخادم بإنشاء رمز ويب JSON. يحتوي على { المعرف: 1، الاسم: "بوب" }. يوقعها بالمفتاح السري.
يرسل الخادم JWT إلى العميل.
يرسل العميل JWT.
يتحقق الخادم من التوقيع. يجد “المستخدم هو بوب”. الإيجابيات: عديم الجنسية. لا حاجة للبحث في قاعدة البيانات. “الرمز المميز هو الجلسة”. السلبيات: لا رجعة فيه. إذا سرقت، صالحة حتى انتهاء الصلاحية.

لماذا يناقش Maison Code هذا الأمر

في Maison Code، نقوم ببناء الخدمات المصغرة وتطبيقات الهاتف المحمول. تعتبر الجلسات فظيعة بالنسبة لتطبيقات الهاتف المحمول (ملفات تعريف الارتباط صعبة). تعتبر الجلسات فظيعة بالنسبة للخدمات الصغيرة (إن مشاركة مثيل Redis عبر 10 خدمات يعد اقترانًا). JWT هو جواز السفر العالمي. يمكن للخدمة “أ” التحقق من الرمز المميز الصادر عن خدمة المصادقة فقط من خلال معرفة المفتاح العام. نحن ننفذ تدفقات JWT صارمة لتمكين بنياتنا بدون رأس.

تشريح JWT

ثلاثة أجزاء، مفصولة بالنقاط. “الرأس. الحمولة. التوقيع”.

الرأس: الخوارزمية (HS256).
الحمولة: البيانات (sub: 123، exp: 17000000).
التوقيع: التجزئة (الرأس + الحمولة + السر).

حرج: الحمولة ** مشفرة بـ Base64 ** وليست مشفرة. يمكن لأي شخص قراءتها (“atob(token)`). القاعدة: لا تضع أسرارًا في JWT أبدًا. لا توجد كلمات مرور. لا بطاقات الائتمان. معرفات وأدوار المستخدم العامة فقط.

أين يمكن تخزينه؟ (الحرب المقدسة)

الخيار 1: التخزين المحلي

سهل (localStorage.setItem('token', t)).
** عرضة لـ XSS **. إذا قام المهاجم بتشغيل JS، فسيقرأ الرمز المميز.

الخيار 2: ملف تعريف الارتباط HttpOnly

آمن. JS يحد من الوصول.
** عرضة لـ CSRF **.
يتطلب SameSite=Strict.

** حكم رمز الدار **: ** ملف تعريف الارتباط HttpOnly **. يعد CSRF أسهل في التخفيف (SameSite) من XSS. بالنسبة لتطبيقات الهاتف المحمول، استخدم التخزين الآمن (سلسلة المفاتيح).

رمز الوصول / نمط الرمز المميز للتحديث

لحل مشكلة “لا رجعة فيه”.

رمز الوصول: عمر قصير (5 دقائق). تستخدم للاتصال API.
رمز التحديث: عمر طويل (7 أيام). مخزنة بشكل آمن (HttpOnly/DB). يُستخدم فقط للحصول على رمز وصول جديد.

** التدفق **:

يقوم العميل بإجراء اتصال API باستخدام Access Token.
يقول الخادم “401 انتهت الصلاحية”.
يستدعي العميل /refresh-token باستخدام رمز التحديث.
يتحقق الخادم من قاعدة البيانات. “هل تم حظر رمز التحديث هذا؟ لا.”
يصدر الخادم رمز وصول جديد. الأمان: في حالة سرقة رمز الوصول، فإنه يعمل لمدة 5 دقائق. إذا قمت بحظر المستخدم، فإنك تقوم بحذف رمز التحديث من قاعدة البيانات. يتم إغلاقها لمدة 5 دقائق كحد أقصى.

الخوارزمية: HS256 مقابل RS256

HS256 (متماثل): يقوم الخادم بالتوقيع والتحقق بنفس السر. سريع. بسيطة بالنسبة للمونوليث.
RS256 (غير متماثل): علامات خدمة المصادقة باستخدام المفتاح الخاص. يتم التحقق من الخدمات الأخرى باستخدام المفتاح العام.
- هذا أمر بالغ الأهمية للخدمات الصغيرة. يمكن لـ “خدمة المنتج” التحقق من المستخدم دون معرفة سر خدمة المصادقة.

وجهة نظر المتشككين

“الجلسات أبسط.” نقطة مضادة: نعم، لمتراصة مع خادم واحد. حاول إجراء جلسات عندما يكون لديك واجهة Next.js الأمامية على Vercel Edge Network وواجهة Go الخلفية على AWS. زمن الوصول لـ “التحقق من Redis” يقتل أداء Edge. يسمح JWT بالتحقق من المصادقة * عند الحافة * (التحقق من التوقيع خلال 1 مللي ثانية) دون رحلة قاعدة البيانات.

الأسئلة الشائعة

س: هل يمكنني إبطال JWT يدويًا؟ ج: لا، هذه هي النقطة. يمكنك تنفيذ “القائمة السوداء” (تخزين معرفات JWT غير الصالحة في Redis)، ولكنك تعيد اختراع الجلسات بعد ذلك. استخدم أوقات انتهاء الصلاحية القصيرة بدلاً من ذلك.

س: ما مدى ضخامة JWT؟ ج: اجعلها صغيرة. يتم إرساله في كل رأس HTTP. إذا وضعت 50 إذنًا فيه، فإنك تبطئ كل طلب.

10. دوران الرمز المميز (سلسلة التحديث)

هناك عيب في رموز التحديث القياسية: في حالة سرقتها، يستطيع اللص الوصول لمدة 7 أيام. الحل: تحديث دوران الرمز المميز.

يرسل العميل رمز التحديث أ.
يقوم الخادم بإرجاع رمز الوصول B ورمز التحديث الجديد C.
يقوم الخادم بحذف رمز التحديث أ. إذا حاول اللص استخدام “رمز التحديث القديم A” مرة أخرى -> إنذار الأمان. يكتشف الخادم إعادة استخدام رمز مميز تم إبطاله. إنه يبطل على الفور “عائلة الرمز المميز” بأكملها (A وC وجميع المتحدرين). يتم إغلاق اللص على الفور. يطلب من المستخدم الحقيقي إعادة تسجيل الدخول.

11. JWKS (مجموعات مفاتيح الويب JSON)

كيف يمكنك تدوير مفاتيح التوقيع؟ لا يمكنك إعادة تجميع المفتاح العام في التطبيقات كل أسبوع. الحل: نقطة نهاية JWKS (/.well-known/jwks.json). ينشر خادم المصادقة مفاتيحه العامة على عنوان URL. يقوم خادم الموارد بجلبها ديناميكيًا (ويخزنها مؤقتًا). إذا كنت تشك في وجود حل وسط للمفتاح، فقم بتدوير المفتاح على خادم المصادقة، وقم بتحديث JWKS، وسيلتقط الجميع المفتاح الجديد خلال 5 دقائق.

12. OAuth 2.1 والمستقبل

JWT هو مجرد تنسيق الرمز المميز. OAuth 2.0 هو التدفق. تنتقل الصناعة إلى OAuth 2.1 (توحيد أفضل الممارسات).

لا مزيد من التدفق الضمني (رمز الوصول في تجزئة عنوان URL).
PKCE (مفتاح إثبات تبادل التعليمات البرمجية) إلزامي. نحن ننفذ PKCE حتى لتطبيقات الويب من جانب الخادم الآن. يمنع هجمات “حقن رمز التفويض”.

13. مصادقة آلة إلى آلة (بيانات اعتماد العميل)

ماذا لو احتاجت “Cron Job A” إلى الاتصال بـ “API B”؟ لا يوجد مستخدم. لا كلمة المرور. نحن نستخدم ** تدفق بيانات اعتماد العميل **. POST /token {client_id، client_secret }. إرجاع JWT. هذا توحيد المصادقة. سواء كان مستخدمًا (sub: user_1) أو جهازًا (sub:service_billing)، فإن واجهة برمجة التطبيقات (API) تتحقق فقط من صحة توقيع JWT. التوحيد هو الأمن.

14. الاستنتاج

JWT هي عملة الويب الحديثة. مثل النقود، يجب سكها بعناية (التوقيع)، وتخزينها بشكل آمن (آمن)، والتحقق من عدم وجود تزوير (التحقق). لا تقم بتدوير العملات المشفرة الخاصة بك. استخدم المكتبات (jsonwebtoken، jose).

مصادقة مكسورة؟

إذا تم تسجيل خروج المستخدمين بشكل عشوائي، أو كنت تقوم بتخزين الرموز المميزة في LocalStorage، فيمكن لـ Maison Code تأمين تدفق المصادقة الخاص بك. نحن ننفذ استراتيجيات التناوب OAuth2 وOIDC وJWT.

اتصل بنا لتأمين تسجيلات الدخول الخاصة بك.

هل تعاني من الصداع؟

نقوم بتأمين المصادقة عديمة الحالة باستخدام JWTs (نمط الوصول/التحديث) وملفات تعريف الارتباط HttpOnly لحماية الهويات عبر الخدمات الصغيرة. قم بتعيين مهندسينا المعماريين.