Learn-json-web-tokens: لماذا "الاستخدام الفردي" يمكن أن يحل مشكلة MITM؟

@ NE - SmallTown سؤال جيد.
يعد استخدام الرموز المميزة أحادية الاستخدام ممارسة جيدة لأمان التطبيق.
إذا كنت تريد استخدام هذا النمط ، فيمكنك إعداد خطاف onPreResponse تلقائيًا بتحديث JWT لكل استجابة.

السؤال الذي يجب أن تجيب عليه هو: كيف تخطط لضمان عدم إعادة استخدام الرمز المميز؟
ستحتاج إلى تخزين المعرف في نوع من قواعد البيانات (_ عادةً ما نستخدم redis لهذا في تطبيقاتنا_) والتحقق مما إذا كان الرمز المميز قد تم استخدامه بالفعل.

nelsonic شكرا لردكم ، أنا مرتبك قليلا.

هناك سؤال.

كما تقول ، فإن العملية هي:

يدخل المستخدم إلى الصفحة الرئيسية ويرسل الرمز المميز في الرأس (على افتراض أنه قد قام بتسجيل الدخول)

                                       |
                                       |
                                       ↓

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

هناك سؤال ، نحن نستخدم عامل التشغيل == للتحقق ، لكننا نعلم أن الرمز المميز نفسه لديه آلية Vertify ، فنحن لا نستخدمها ؟ على سبيل المثال:

JWT.require(Algorithm.RSA256((RSAKey) publicKey))
                .withIssuer("auth")
                .withSubject("ne-smalltown")
                .withAudience(userId)
                .withArrayClaim("jwt-role", userRole)
                .build()

إذا كنت مخطئًا ، فهل يمكن أن تخبرني كيف وأين أستخدم الرمز المميز نفسه آلية الرأسية مثل أعلاه؟

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

                                        |
                                        |
                                        ↓

يستلم العميل الرمز الجديد ويدفعه إلى localstorage ليحل محل الرمز القديم ، وفي الطلب التالي سيستخدمه.

nelsonic مرحبا؟

@ NE-SmallTown اعتذاري لعدم الرد على الفور.
لا تحتوي مواصفات JWT على مطالبة / آلية لإبطال الاستخدام الفردي
انظر: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#RegisteredClaimName

لدى jbspeakr منشور حول كيفية استخدام JWTs ذات الاستخدام الفردي ،
انظر: https://www.jbspeakr.cc/howto-single-use-jwt/

nelsonic شكرا لك على نشر هذا المنصب.

يقول المنشور:

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

أوافق على أن هذه الحالات تناسب الاستخدام الفردي jwt ، لكن حالتي هي أن تتضمن jwt معلومات دور المستخدم والدور ثابت ، فهي لا تحب إعادة تعيين كلمة المرور ، وتفعيل البريد الإلكتروني ، وتأكيد الحساب ، وما إلى ذلك.

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