الخلاصة
- يتيح RFC 9701 لخادم موارد موثّق أن يتلقى جواب استبطان OAuth في JWT موقّع، ومشفّر اختيارياً، يحمل المُصدر والجمهور ووقت الإنشاء وكائن
token_introspectionداخلياً. - لا تكفي صحة التوقيع: يجب ربط هوية السائل، ونوع الجواب، والجمهور والحداثة، وحالة الرمز ونطاقه، وأساس الإفصاح، ومنع الإعادة، والقاعدة المحلية، والأثر المنفذ.
كل طلب استبطان يقول شيئين. يقول لخادم الموارد ما إذا كان رمز الوصول نشطاً وما البيانات المرتبطة به. ويقول لخادم التفويض إن مورداً معيناً يُستعمل الآن، وربما إن مستخدماً معيناً حاضر. هذه المبادلة جزء من البنية، وليست أثراً جانبياً يمكن للتشفير أن يمحوه.
يضيف RFC 9701 جواب JWT إلى آلية RFC 7662. يتيح التوقيع نسبة الجواب إلى خادم التفويض، ويتيح التشفير حصر قراءته في مستلم. لكنه يظل تقريراً عن الرمز، لا الرمز نفسه ولا قراراً نهائياً بتنفيذ العمل.
لا يحصل السائل على البيانات لمجرد أنه وصل إلى المنفذ
يجب على خادم التفويض تحديد خادم الموارد المتصل ومصادقته وتفويضه. TLS وحده لا يحدد ما إذا كان ذلك الخادم جمهوراً للرمز أو أي حقول يجوز له رؤيتها. يمكن استخدام تسجيل عميل وفق RFC 7591، لكن طريقة الإدارة محلية؛ النتيجة الإلزامية هي منع السائل المجهول أو غير المصرح له.
إذا كان الرمز باطلاً أو منتهي الصلاحية أو مسحوباً أو غير موجه إلى هذا الخادم، يحمل الكائن الداخلي active:false ولا يحمل أعضاء أخرى. تمنع هذه البنية جواب الرفض من كشف هوية أو نطاق أو موعد انتهاء. وإذا كان نشطاً، ينبغي تضييق scope إلى ما يخص المستلم، وتخضع بيانات الشخص لسياسة وأساس قانوني خاصين به.
لذلك لا تعني active:true أن الرمز نشط في كل مكان. إنها إجابة صادرة إلى خادم موارد محدد بناء على حالة وتهيئة في لحظة محددة.
الغلاف يصف الجواب، والداخل يصف الرمز
يطلب الخادم application/token-introspection+jwt، ويستعمل الجواب نوع الوسيط نفسه وtyp: token-introspection+jwt. في الأعلى توجد iss وaud وiat وtoken_introspection.
يحدد aud الخارجي من يستهلك الجواب. وقد يحدد aud الداخلي أين يستعمل رمز الوصول. يؤرخ iat الخارجي إنشاء التصريح، أما التواريخ الداخلية فتخص دورة حياة الرمز. دمج الطبقتين في قاموس واحد قد يطبق مقارنة صحيحة على السلطة الخاطئة.
لهذا لا ينصح RFC بوضع sub أو exp في الأعلى، ويؤكد أن جواب JWT ليس تمثيلاً بديلاً لرمز الوصول. سجلات IANA لـOAuth وJWT ونوع الوسيط تنظم الأسماء، ولا تتحقق من استعمالها في الطبقة الصحيحة.
التوقيع والتشفير لا يملكان القرار المحلي
يكون الجواب موقّعاً، أو موقّعاً ثم مشفّراً في Nested JWT. يحدد JWS التوقيع، وJWE التشفير، وJWT الحاوية. ويبقى على النظام تحديد المُصدرين الموثوقين والمفاتيح والخوارزميات وفترة القبول.
يمكن لخادم التفويض نشر الخوارزميات المدعومة وفق RFC 8414، ويمكن للمورد تسجيل مفاتيح التشفير. إعلان القدرة لا يثبت الخوارزمية التي استعملها جواب بعينه. وkid لا يثبت أن المفتاح كان معتمداً في نسخة السياسة المستخدمة.
يجب حفظ بصمة الجواب وtyp والمُصدر المتوقع ونسخة مجموعة المفاتيح والخوارزمية ونتيجة التوقيع، وعند التشفير مفتاح المستلم ونتيجة فك التشفير. عبارة «JWT صالح» تختصر قرارات كثيرة لا يجوز دمجها.
التشابه بين JWTs يخلق باب تبديل
قد يحمل رمز وصول JWT وجواب الاستبطان iss وaud وتوقيعاً من المجال نفسه. إذا قبل المدخل أي JWT صحيح التوقيع، يمكن تقديم الجواب كأنه رمز وصول. يستخدم RFC 9701 النوع المخصص والكائن الداخلي، ويعطي RFC 8725 قاعدة أوسع: يجب أن تكون ملفات التحقق للأغراض المختلفة صريحة ومتبادلة الاستبعاد.
لا يغير نجاح فك التشفير نوع الكائن. ولا يربط توقيع الجواب رمز الوصول بصاحبه الحالي. يحيل RFC إلى RFC 9700 لمقاومة الإعادة. إثبات الحيازة وربط الطلب والجمهور تبقى اختبارات منفصلة.
الحقيقة القديمة قد تبقى موقعة بعد زوال صلاحيتها التشغيلية
يجعل iat الخارجي عمر الجواب قابلاً للقياس، لكنه لا يحدد مدة تخزين عامة. قد يُسحب الرمز أو تنتهي صلاحيته أو يتغير نطاقه بعد إنشاء الجواب. يبقى التوقيع دليلاً صحيحاً على ما قيل آنذاك، بينما يصبح الجواب أقدم من أن يسمح بعملية حالية.
على خادم الموارد تحديد العمر الأقصى حسب مخاطر العملية. ثم يطبق قواعده: تجميد الكائن، تعليق الحساب، حد المبلغ، موافقة إضافية أو قيد قضائي. scope=write مدخل لا حكم. وحتى قرار السماح يحتاج بعده إلى دليل تنفيذ أو فشل أو تراجع.
الخصوصية سلطة مستقلة
قد ينقل الاستبطان بيانات شخصية. يتطلب RFC أساساً قانونياً وتطبيقاً مستمراً لحدوده. يحمي التشفير البيانات من غير حامل المفتاح، لكنه لا يجعل الإفصاح الزائد مشروعاً ولا يضبط استعمال البيانات بعد فكها. ويقوي RFC 9325 TLS من دون أن يلغي سجل وقت الاستخدام لدى خادم التفويض.
إذا كان كشف وقت الوصول غير مقبول، يجب استخدام وسيلة أخرى لنقل بيانات الرمز. لذلك ينبغي أن تسجل الحوكمة سبب اختيار الاستبطان، لا إعداد الخوارزمية فقط.
تربط سلسلة الإثبات بصمة الرمز والعملية وهوية خادم الموارد ومصادقته وTLS وبصمة الجواب والنوع والمفتاح والتوقيع وفك التشفير وclaims الخارجية والحالة الداخلية والنطاق وأساس الإفصاح ومنع الإعادة والسياسة المحلية والنتيجة.
تترك عقيدة Lu Heng للمواصفة الأولية الدنيا الشكل والclaims المشتركة في الطبقة العامة، وتبقي الثقة والحداثة والخصوصية والتفويض محلية وواضحة. تفصل طبقات الواقع بين التسجيل والبايتات والتوقيع والحالة والقرار والأثر. وتعطي أولوية الكود العامل لسجل المدقق والتنفيذ بدلاً من ادعاء دعم المواصفة.
المصادر
- RFC 9701 HTML
- RFC 9701 نص
- RFC 9701 XML
- معلومات RFC 9701
- تصويبات RFC 9701
- تاريخ RFC 9701
- RFC 7662
- RFC 9700
- RFC 8725
- RFC 7515
- RFC 7516
- RFC 7519
- RFC 8414
- RFC 7591
- RFC 9325
- معلمات OAuth لدى IANA
- Claims JWT لدى IANA
- نوع الوسيط token-introspection JWT
- Lu Heng: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Lu Heng: On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
- Lu Heng: Running-Code Primacy
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

