كيف يعمل توقيع JWT: HS256 مقابل HS384 مقابل HS512

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

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

ليرة تركية؛DR: يقوم مولد JWT بتحويل حمولة JSON بالإضافة إلى سر إلى رمز مميز موقع. الصق مطالباتك، واختر HS256 أو HS384 أو HS512، وأدخل السر، وانسخ الرمز المميز. ال مولد جي دبليو تي قم بالتوقيع باستخدام واجهة برمجة تطبيقات Web Crypto للمتصفح، حتى لا تغادر الحمولة والسرية جهازك أبدًا. استخدمه لإنشاء رموز اختبار مع معروف sub، انتهاء محدد، أو منتهية الصلاحية عمدا exp لممارسة مسارات الخطأ API&#39؛s. لقراءة الرمز المميز مرة أخرى، قم بإقرانه مع JWT فك التشفير.

ما هو JWT وما الذي ينتجه المولد؟

رمز ويب JSON هو طريقة مدمجة وآمنة لعنوان URL لتمثيل مجموعة من المطالبات. يتم تعريف البنية بواسطة RFC 7519، والنموذج الموقع، وهو ما يعنيه الجميع تقريبًا بـ &quot؛a JWT،&quot؛ هو توقيع ويب JSON كما هو محدد بواسطة RFC 7515. يتكون الرمز المميز الموقع من ثلاثة أجزاء متصلة بالنقاط header.payload.signature.

الرأس عبارة عن كائن JSON صغير يسمي خوارزمية التوقيع ونوع الرمز المميز، شيء من هذا القبيل { "alg": "HS256", "typ": "JWT" }. الحمولة هي كائن JSON للمطالبات: من هو الرمز المميز، ومتى تنتهي صلاحيته، وأيًا كانت الحقول المخصصة التي يضيفها تطبيقك. كل من الرأس والحمولة مشفرة بـ Base64url، وهي قاعدة عادية 64 مع استبدالين للأحرف وبدون حشوة، تمامًا كما يحدد RFC 7515. التوقيع عبارة عن تجزئة ذات مفاتيح محسوبة على الجزأين الأولين.

يقوم المولد بتجميع الثلاثة. تقوم بتزويد الحمولة والسر، ويقوم ببناء الرأس، وتشفير كلا الجزأين، وحساب التوقيع، وضمهما. الإخراج عبارة عن سلسلة يمكنك إسقاطها مباشرة في ملف Authorization: Bearer رأس، أو أداة اختبار، أو curl يأمر.

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

كيف يعمل التوقيع؟

بالنسبة لعائلة HMAC، وهو ما توقع به هذه الأداة، فإن التوقيع هو HMAC(secret, header + "." + payload). HMAC عبارة عن بناء تجزئة ذو مفاتيح محدد بواسطة RFC 2104، وتقوم مواصفات JWA، RFC 7518، بتعيين أسماء خوارزمية JWT الثلاثة عليها: يستخدم HS256 HMAC مع SHA-256، ويستخدم HS384 SHA-384، ويستخدم HS512 SHA-512.

الخاصية المهمة هي التماثل. نفس السر يقوم بإنشاء التوقيع والتحقق منه. عندما يتلقى الخادم الخاص بك رمزًا مميزًا، فإنه يعيد الحساب HMAC(secret, header + "." + payload) على المقطعين الأولين المستلمين والتحقق من أن النتيجة تساوي مقطع التوقيع. إذا تم تغيير بايت واحد من الحمولة، فلن تتطابق التجزئة المعاد حسابها وسيفشل التحقق. هذا هو ضمان السلامة بالكامل.

لأنه متماثل، السر هو اللعبة بأكملها. يمكن لأي شخص لديه السر أن ينشر رموزًا صالحة لنظامك، ولهذا السبب يقوم المولد بتشغيل التوقيع في متصفحك من خلال Web Crypto API ولا ينقل السر أبدًا في أي مكان. يمكنك تأكيد ذلك عن طريق فتح علامة التبويب "الشبكة" &#39؛s أثناء إنشاء رمز مميز: لا يوجد طلب. وهذا يهم أكثر مما يبدو، لأن لصق سر توقيع الإنتاج المباشر في أداة ويب عشوائية تقوم هواتف المنزل بتسليم مفاتيح المصادقة الخاصة بك.

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

كيفية استخدام مولد JWT

الخطوة 1: اكتب الحمولة

أدخل مطالباتك ككائن JSON. الحد الأدنى من المثال هو { "sub": "1234567890", "role": "admin" }. ال sub المطالبة هي الموضوع، وعادة ما تكون معرف المستخدم. يمكنك إضافة أي حقول مخصصة يقرأها تطبيقك، مثل role، scope، tenant_id، أو email. تحتفظ الأداة بكل ما تضعه هنا كما هو مكتوب تمامًا.

الخطوة 2: أضف مطالبات الوقت

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

الخطوة 3: اختر الخوارزمية والسرية

اختر HS256 إلا إذا كان لديك سبب لاستخدام HS384 أو HS512. أدخل سر التوقيع في الحقل. ثم اختر كيفية تفسير السر: يستخدم النص العادي بايتات UTF-8 لما تكتبه، بينما يقوم base64url وhex بفك تشفير السلسلة أولاً إلى بايتات أولية. هذا الاختيار مهم لأن العديد من الأنظمة تخزن السر المشفر بالفعل بواسطة base64، وإذا قمت بتغذية السلسلة المشفرة كنص عادي فسوف تنتج توقيعًا غير متطابق.

الخطوة 4: انسخ الرمز المميز

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

لماذا إنشاء رمز مميز باليد؟

اختبار API الخاص بك و#39؛s المسار السعيد

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

اختبار مسارات الفشل

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

إعادة إنتاج خطأ من مستخدم معين

يقوم الدعم بالإبلاغ عن مشكلة تحدث فقط للحسابات ذات دور معين. إنشاء رمز مميز بهذا بالضبط role المطالبة والمستخدم المتأثر &#39؛s subويمكنك إعادة إنتاج الطلب محليًا دون لمس بيانات الإنتاج أو مطالبة المستخدم برمز حامله الحقيقي، وهو ما لا ينبغي عليك فعله أبدًا على أي حال.

بذر التنمية المحلية

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

HS256 vs HS384 vs HS512: ما الذي يجب عليك استخدامه؟

خوارزمية	التجزئة	حجم التوقيع	الحد الأدنى لطول المفتاح	متى تستخدم
HS256	شا-256	32 بايت	32 بايت	الافتراضي. سريع ومدعوم على نطاق واسع وآمن لجميع الاستخدامات تقريبًا
HS384	شا-384	48 بايت	48 بايت	عندما تتطلب السياسة أو المعيار SHA-384
HS512	شا-512	64 بايت	64 بايت	سياقات عالية الأمان، أو عندما تقوم بالفعل بالتوحيد القياسي على SHA-512

الإجابة العملية هي HS256 ما لم يتطلب شيء خارجي خلاف ذلك. يتطلب RFC 7518 أن يكون المفتاح على الأقل بنفس طول مخرج التجزئة، لذا 32 بايت لـ HS256، و48 لـ HS384، و64 لـ HS512. يحذر المولد عندما يكون سرك الذي تم فك تشفيره أقصر من الحد الأدنى، لأن المفتاح القصير يضعف التوقيع بغض النظر عن اسم الخوارزمية. الخوارزمية الأطول والأعلى رقمًا لا تصلح سرًا ضعيفًا؛ السر العشوائي ذو الطول المناسب هو ما يهم.

الأخطاء الشائعة وكيفية تجنبها

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

والثاني هو الثواني والميلي ثانية المربكة. يتم قياس جميع مطالبات الوقت المسجلة في RFC 7519 بالثواني منذ عصر Unix. جافا سكريبت &#39؛س Date.now() إرجاع مللي ثانية. إذا قمت بالحساب exp بنفسك، وننسى القسمة على 1000، يبدو أن الرمز المميز الخاص بك قد انتهى بعد خمسين ألف عام من الآن، وهو ما سيرفضه بعض المدققين الصارمين. إن السماح للمولد بحساب المطالبات يتجنب ذلك تمامًا.

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

حيث تتناسب JWTs مع الأدوات الأخرى

بمجرد إنشاء رمز مميز، فإن الخطوة الطبيعية التالية هي قراءته مرة أخرى. ال JWT فك التشفير يقسم أي رمز مميز إلى رأسه وحمولته ويضع علامة على انتهاء الصلاحية exp، وهذه هي الطريقة التي تؤكد بها أن المولد أنتج ما كنت تقصده. إذا كنت تقوم أيضًا بتوليد الأسرار، فإن مولد هاش يحسب تجزئة SHA من جانب العميل، و مولد كلمة السر ينتج نوع السلسلة العشوائية الطويلة التي تجعل سر HMAC جيدًا في المقام الأول. إذا كنت تريد فهم Base64url خطوة باليد، فإن التشفير BASE64 / وحدة فك التشفير يُظهر نفس التحويل القابل للعكس الذي يحول الرأس والحمولة إلى شكلهما المشفر. وعندما تحتاج إلى معرف عشوائي لإسقاطه في sub أو jti المطالبة، مولد يوويد يعطيك واحدة بالتنسيق الصحيح.

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

كيف يتحقق الخادم من الرمز المميز الذي تقوم بإنشائه؟

فهو يساعد على معرفة ما يحدث على الجانب الآخر، لأنه يفسر لماذا يجب أن يكون السر والمطالبات صحيحة تمامًا. عندما تتلقى واجهة برمجة التطبيقات الخاصة بك رمزًا مميزًا، تقوم مكتبة مثل jsonwebtoken أو jose أو PyJWT بثلاثة أشياء بالترتيب. يقوم بتقسيم الرمز المميز على النقاط ويقوم Base64url بفك تشفير الرأس لقراءة alg. يعيد حساب التوقيع header.payload استخدام السر الذي تم تكوينه ومقارنته، بايت ببايت، مع مقطع التوقيع. ويتحقق من المطالبات المسجلة: هو exp في الماضي، هو nbf في المستقبل، يفعل iss و aud تطابق ما تتوقعه واجهة برمجة التطبيقات.

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

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

كيف يجب أن تتعامل مع الأسرار وتخزين الرموز المميزة؟

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

من جانب العميل، حيث تقوم بتخزين الرمز المميز النهائي، يهم بقدر أهمية كيفية التوقيع عليه. رمز مميز في localStorage يمكن قراءته بواسطة أي JavaScript على الصفحة، لذا فإن عيبًا واحدًا في البرمجة النصية عبر المواقع يمنح المهاجم بيانات اعتماد صالحة. ان httpOnly، Secure، SameSite ملف تعريف الارتباط غير مرئي للبرامج النصية، مما يغلق هذا المسار على حساب الحاجة إلى حماية CSRF. النمط الشائع هو رمز وصول قصير العمر يتم الاحتفاظ به في الذاكرة ورمز تحديث أطول عمرًا في ملف httpOnly ملف تعريف الارتباط. لا يغير أي من هذا كيفية إنشاء رمز مميز، ولكن السياق هو الذي يجعل الرمز المميز الذي تم إنشاؤه آمنًا للاستخدام وليس مسؤولية.

أسئلة وأجوبة

كيف أقوم بإنشاء JWT؟

الصق مطالباتك ككائن JSON، واختر خوارزمية توقيع مثل HS256، وأدخل السر. تقوم الأداة base64url بتشفير الرأس والحمولة، وحساب توقيع HMAC، وإرجاع الرمز المميز النهائي لتتمكن من نسخه. كل شيء يعمل في متصفحك.

ما هي خوارزميات التوقيع المدعومة؟

HS256 وHS384 وHS512، عائلة HMAC، بالإضافة إلى &quot غير موقعة؛ لا شيء وحاصل؛ خيار للاختبار. لا يتم تقديم RS256 وES256 عمدًا لأنهما يوقعان بمفتاح خاص، ومن الأفضل تجنب لصق مفتاح خاص في صفحة ويب.

هل يتم إرسال سري إلى الخادم؟

لا. يتم تشغيل التوقيع بالكامل في متصفحك من خلال Web Crypto API، لذلك لا يغادر السر والحمولة جهازك أبدًا. يمكنك تأكيد ذلك في علامة التبويب DevTools Network، وتستمر الأداة في العمل دون اتصال بالإنترنت بمجرد تحميلها.

كيف أقوم بتعيين الرمز المميز على انتهاء الصلاحية؟

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

لماذا يجب أن يكون السر 32 بايت على الأقل؟

يتطلب RFC 7518 مفتاح HMAC على الأقل طالما أن مخرجات التجزئة، وهي 32 بايت لـ HS256، و48 لـ HS384، و64 لـ HS512. السر الأقصر يضعف التوقيع، لذلك تحذر الأداة عندما يكون السر الذي تم فك تشفيره قصيرًا جدًا.

هل يمكنني إنشاء رمز مميز غير موقع؟

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

هل تم إنشاء JWT مشفر؟

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

---