الخلاصة

  • يقترح draft-tulshi-oauth-transactional-access-tokens-00 رمز JWT قصير العمر لمورد واحد، مع إعادة تقييم السياسة عند كل طلب.
  • لا تجعل مدة الخمس دقائق refresh token أو client credential أو الموافقة قصيرة، ولا تثبت أن العملية نُفذت مرة واحدة أو نجحت.

نُشرت النسخة الأولى في 29 سبتمبر 2026. وهي Internet-Draft فردية تستهدف Standards Track، وليست وثيقة متبناة من مجموعة OAuth ولا إجماعاً في IETF ولا RFC. ولا يثبت أي مصدر تمت مراجعته وجود تنفيذ أو تشغيل أو نتيجة أمنية. الخبر هنا هو تقسيم المسؤوليات المقترح.

يبني Txn-AT على ملف JWT access token في RFC 9068. يستخدم النوع txnat+jwt لكي يرفضه المستهلك القديم بدلاً من قبوله مع تجاهل معنى المعاملة. يجب أن يحتوي aud على resource server واحد، وأن يوجد txn، وأن تكون قيم tctx وrctx مما قيّمه authorization server وقرر أن يؤكده.

قبل الرمز توجد سلطة أطول عمراً. يطلب العميل بواسطة token exchange أو refresh token أو client credentials. يجب على الخادم تشغيل السياسة لكل طلب، ويمكنه الرفض حتى لو كان الاعتماد أو transaction handle صالحاً. وعند إنشاء معاملة جديدة يعيد مقبضاً opaque بقدر كاف من العشوائية، مربوطاً بالعميل والsubject وبالمفتاح عند استعمال sender constraint.

يستطيع المقبض طلب رمز آخر لمورد آخر في المعاملة نفسها. لذلك توجد ستة إيصالات مختلفة: الاعتماد الدائم يشرح حق السؤال؛ قرار السياسة يشرح قبول الطلب الحالي؛ المقبض يربط الطلبات؛ Txn-AT ينقل تأكيداً لمورد بعينه؛ Txn-Token يحمل سياقاً داخل trust domain؛ وإيصال التنفيذ يصف ما حدث فعلاً.

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

لهذا تعتمد الفائدة على معنى «تقييم». لا يجوز نسخ سياق قدمه العميل إلى tctx أو rctx بلا سياسة. يجب فحص هوية subject، وطريقة التوثيق، وبيانات client، وattestation، والمورد، وauthorization details، والبيئة وحداثتها. التوقيع الصحيح يحمي قول الخادم؛ لا يثبت صحة حكمه.

يختلف txn بين audiences في المعاملة ذاتها. يقلل ذلك قدرة موردين على الربط بالمقارنة المباشرة. لكنه لا يمنع الربط عبر client_id أو الوقت أو subject أو سياق مميز. أما authorization server فيعرف المعرف الداخلي ويرى كل طلب. انتقلت الرؤية إلى المركز ولم تختف.

تقترح المسودة اشتقاقاً بـHMAC من معرف داخلي وaudience. يوفر ذلك جدول الربط، لكنه يجعل K_txn مفتاحاً للخصوصية والتدقيق. يجب تحديد دورانه، ومدة الاحتفاظ بالمفاتيح المتقاعدة، ومن يستطيع استخدامها. تسرب المفتاح مع الحالة الداخلية يعيد بناء العلاقات بين الموارد.

إعادة الاستخدام حد قائم. يمكن إعادة bearer Txn-AT داخل مدة صلاحيته. توصي المسودة بـDPoP أو mutual TLS، وتسمح للمورد بتخزين jti إذا احتاج single-use، لكنها لا تفرض ذلك. خمس دقائق تكفي لتكرار دفع أو حذف أو تغيير شبكة.

كما أن txn ليس idempotency key للأثر التجاري. لا يقرر إن كان طلبان HTTP يجب أن ينتجا أثراً واحداً، ولا يعالج نجاح مورد وفشل آخر. يحتاج التطبيق إلى request ID، وقاعدة للتكرار، وإيصال commit، ومسار تعويض.

يجب إثبات الفصل بين الأنواع باختبارات فشل. مورد يشترط Txn-AT يرفض at+jwt. workload داخلي يرفض الرمز الخارجي مكان txntoken+jwt. audience متعددة، أو مقبض منتهي، أو عميل أو subject مختلف يجب أن يفشل. metadata تعلن النية ولا تثبت enforcement.

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

الطبقة المشتركة الرقيقة تحمل النوع وaudience والمصدر والسياق المقيم. لا تحول سياسة الخادم إلى حقيقة عالمية، ولا تحول قبول الرمز إلى نتيجة. قيمة Txn-AT تأتي من تضييق القرار مع بقاء التنفيذ قابلاً للملاحظة منفصلاً.

المصادر