إنتقل إلى المحتوى الرئيسي

التحقق من JWT

بعد موافقة المستخدم على التحدي، يُصدر ZTXBAS رمز JWT موقّعًا بـES256 وقصير العمر ويعيده ضمن استجابة status. تشرح الصفحة محتواه وكيفية التحقق منه والفحوص اللازمة بعد صحة التوقيع.

شكل JWT​

الرأس:

{ "alg": "ES256", "typ": "JWT", "kid": "abc123..." }

الحمولة (المطالبات):

{
  "iss": "https://ztxbas.example.com",
  "sub": "alice@example.com",
  "aud": "https://app.example.com",
  "iat": 1704067200,
  "exp": 1704067500,
  "email": "alice@example.com",
  "origin": "https://app.example.com",
  "challenge_id": "c_abc123"
}
  • sub وemail — المستخدم الذي تمت مصادقته.
  • aud وorigin — الأصل الذي ارتبط به التحدي.
  • challenge_id — معرّف ربط مستخدم مرة واحدة مفيد للسجلات.
  • iat وexp — الإصدار والانتهاء (تفصل بينهما خمس دقائق).
  • iss — خادم ZTXBAS الذي أصدر الرمز.

كيف تتحقق SDK من الرمز؟​

تضم كل SDK مدققًا يقوم بالآتي بالترتيب:

  1. تحليل الأجزاء الثلاثة المشفرة بـbase64url.
  2. التأكد من alg == ES256، ورفض أي قيمة أخرى بما فيها none رفضًا قاطعًا لمنع استبدال الخوارزمية.
  3. البحث عن kid في ذاكرة JWKS المؤقتة، وإعادة جلب /.well-known/jwks.json إن كان غير معروف أو قديمًا (صلاحية التخزين 5 دقائق).
  4. التحقق من توقيع ES256 على header + "." + payload.
  5. التأكد من أن exp في المستقبل (مع تفاوت ساعة ±30 ثانية).
  6. التأكد من أن iat ليس بعيدًا في المستقبل (بالتفاوت نفسه).
  7. إذا ضُبط expected_issuer، التأكد من تطابق iss.

إذا فشلت أي خطوة، تعيد verify خطأً أو تثير استثناءً ويُرفض الرمز.

ما الذي ينبغي فحصه أيضًا؟​

تثبت صحة التوقيع والانتهاء والجهة المُصدِرة أن الرمز تأكيد حقيقي وحديث من خادم ZTXBAS. وعلى نظامك الخلفي أيضًا فحص:

تطابق origin مع الأصل المتوقع. قد يكون المستخدم قد وافق بصورة شرعية على الدخول إلى موقع آخر تملكه، لكنك لا تريد استخدام JWT نفسه في مكان غير مقصود.

if claims.Origin != expectedOrigin {
    return errors.New("token issued for a different origin")
}

عدم استخدام challenge_id مسبقًا. رموز JWT عديمة الحالة. إن شمل نموذج تهديدك سرقة JWT، فاحتفظ بذاكرة LRU صغيرة بمعرّفات التحديات المستخدمة حديثًا وارفض التكرار. قد لا يلزم ذلك في غالبية التكاملات عند إصدار ملف تعريف ارتباط جلسة حقيقي بعد التحقق مباشرةً والتخلص من JWT، لكن عمر الخمس دقائق يترك نافذة قصيرة للمهاجم.

التحقق دون SDK​

إذا استخدمت بيئة لا نوفر لها SDK، فاستعمل مكتبة JWT مطابقة تدعم ES256 وJWKS. يُنشر JWKS في /.well-known/jwks.json بالشكل التالي:

{
  "keys": [
    {
      "kty": "EC",
      "crv": "P-256",
      "alg": "ES256",
      "use": "sig",
      "kid": "abc123...",
      "x": "base64url...",
      "y": "base64url..."
    }
  ]
}

يبقى kid ثابتًا بعد إعادة التشغيل؛ فهو أول 16 حرفًا من SHA-256 المشفر بـbase64url للمفتاح العام بصيغة DER. وينتج الخادمان اللذان يشتركان في مفتاح التوقيع نفسه قيمة kid نفسها.

تدوير المفاتيح​

قد يعيد JWKS أكثر من مفتاح عند تدوير مفتاح التوقيع. تُوقّع الرموز الجديدة بأحدث مفتاح، وتبقى القديمة قابلة للتحقق حتى exp، غالبًا ضمن خمس دقائق.

لا يحتاج المستهلكون إجراءً خاصًا، ما داموا يحترمون kid ويعيدون جلب JWKS عند ظهور معرّف غير معروف، فيصبح التدوير شفافًا.

موضوعات ذات صلة​