الخلاصة

  • يغيّر DPoP خاصية واحدة في رمز الحامل: لم يعد امتلاك نص الرمز كافيًا، بل يجب على مقدّمه إنشاء إثبات جديد بالمفتاح الخاص المقابل لبصمة المفتاح العام المربوطة بالرمز.
  • يقيّد الإثبات طريقة HTTP، وURI الهدف من دون الاستعلام والجزء، ووقت الإنشاء، ومعرّفًا فريدًا، وتجزئة الرمز، وأحيانًا nonce يصدره الخادم. وهو ليس توقيعًا للطلب كله ولا إذنًا بالفعل.
  • ما زال على خادم المورد التحقق من المُصدِر والجمهور والمدة والحالة والصلاحيات، وتنسيق حالة منع الإعادة، واستعادة URI الخارجي الصحيح، ثم تفويض الفاعل والعميل والمورد والفعل وحالة الكائن الحالية.

السرقة التي يتوقف عندها الرمز المنسوخ

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

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

هذه فائدة أمنية فعلية: تسريب قيمة الرمز وحدها لم يعد يمنح اعتمادًا كاملًا خارج بيئة التوقيع.

بعد ذلك يرسل العميل المشروع طلبه. يصح التوقيع، وتتطابق htm وhtu، وتطابق ath قيمة الرمز، ويكون jti جديدًا. ومع ذلك يرفض الخادم الفعل. ربما صُدر الرمز لخدمة أخرى، أو يملك قراءة فقط بينما الطلب يحذف مفتاحًا، أو عُلّق الحساب بعد الإصدار، أو انتقل المورد إلى حالة نهائية لا يجوز تعديلها.

لا يعني ذلك أن DPoP فشل. قيد المُرسِل أجاب عن استعمال المفتاح المربوط لهذا الطلب؛ أما التفويض فأجاب إن كان هذا السياق يملك حق إحداث هذه النتيجة الآن. يمكن أن تكون الإجابة الأولى نعم والثانية لا، وهذا فصل سليم لا تناقض.

من حيازة النص إلى إثبات استعمال المفتاح

تعرّف RFC 6750 خاصية bearer بوضوح: يستطيع حامل الرمز استخدامه من دون إثبات امتلاك مفتاح تشفيري. تقلل TLS والتخزين الآمن وقصر العمر وتقييد الجمهور احتمال التسريب وأثره، لكنها لا تلغي قابلية قيمة الرمز للانتقال داخل سطح القبول.

تضيف RFC 9449 إثباتًا على طبقة التطبيق. يختار العميل زوج مفاتيح غير متماثل، ويقدّم عند token endpoint إثبات DPoP موقّعًا. يستطيع خادم التفويض ربط access token أو refresh token ببصمة JWK للمفتاح العام. وعند المورد المحمي يرسل العميل الرمز وإثباتًا جديدًا، فيتحقق الخادم من أن مفتاح الإثبات هو المفتاح المربوط بالرمز.

لهذا توصي RFC 9700 بقيد المُرسِل، وتقييد الجمهور، وأقل صلاحية بوصفها ضوابط منفصلة. ربط المفتاح لا يجعل رمزًا موجّهًا إلى خدمة مختلفة صالحًا هنا، ولا يرفع read إلى write، ولا ينشئ موافقة، ولا يجمّد تفويضًا تغيّر منذ الإصدار.

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

ما الذي يحمله الإثبات فعلًا

إثبات DPoP هو JWT موقّع بوصفه JWS. يتطلب protected header النوع الصريح dpop+jwt، وخوارزمية غير متماثلة تسمح بها السياسة المحلية، وjwk عامة بلا مادة خاصة. يتيح ذلك للمستقبِل اختيار قواعد DPoP المحددة بدل تمرير أي JWT في مسار عام عنوانه «التوقيع صحيح». وتؤكد RFC 8725 أن النوع والخوارزمية والمُصدِر والجمهور وقواعد التحقق اختيارات تطبيقية، لا حقائق يفرضها الكائن الموقّع.

يحمل المتن الأساسي htm لطريقة HTTP، وhtu لعنوان الهدف من دون query أو fragment، وiat لوقت الإنشاء، وjti معرّفًا يولّد باحتمال تصادم ضئيل للغاية.

عند استعمال access token يحمل الإثبات أيضًا ath، وهي تجزئة SHA-256 للقيمة الدقيقة للرمز المقدم. يعيد الخادم حسابها، فلا يمكن تركيب إثبات التُقط بجانب رمز مع رمز آخر حتى لو استعملا مفتاح الإثبات نفسه.

إذا تحدى الخادم العميل بحقل DPoP-Nonce وجب أن يتضمن الإثبات التالي ذلك nonce. القيمة الحديثة غير المتوقعة تقلل نفع مخزون من الإثباتات الموقعة مسبقًا، وتبين أن قدرة التوقيع استجابت لقيمة اختارها الخادم مؤخرًا.

وجود الحقول لا ينفذ القواعد. يجب رفض حقول DPoP المتعددة، وJWT المشوه، والادعاءات الناقصة، والنوع الخطأ، والخوارزمية غير المسموحة، والتوقيع غير الصحيح، وJWK التي تكشف مفتاحًا خاصًا. ثم تُقارن الطريقة وURI، وتُفرض نافذة الزمن، ويعاد حساب ath، وتُطابق بصمة الرمز، وتُطبق سياسة nonce التي أصدرها الخادم فعلًا.

ثلاث روابط لا يجوز ضغطها في مؤشر واحد

الأولى هي ربط الرمز بالمفتاح. يسجل خادم التفويض بصمة JWK عادةً في cnf.jkt. ويقارن خادم المورد تلك القيمة ببصمة المفتاح العام الذي تحقق به إثبات الطلب الحالي.

الثانية هي ربط الإثبات بالرمز. يربط ath الإثبات بالقيمة الدقيقة لـ access token في هذا الطلب. يمنع استبدال الرمز، لكنه لا يثبت الجمهور أو النطاق أو الصلاحية الزمنية أو حالة الإبطال.

الثالثة يمكن أن تبدأ قبل الإصدار. يربط المعامل الاختياري dpop_jkt authorization code بمفتاح الإثبات الذي قصده العميل. من دونه قد يحاول من يعترض الكود ويمتلك بقية مواد الاستبدال تقديمه بمفتاح يخصه، فيحصل على رمز مقيّد بطريقة صحيحة — لكن للمهاجم. هذا الربط يسد مسارًا مختلفًا، ولا يحل محل PKCE أو مصادقة العميل أو تفويض مالك المورد.

قد ينفذ النظام رابطًا ويغفل آخر. لذلك يجب أن تسمي الأدلة المرحلة والقيم المقارنة، لا أن تختزل الواقع في علم واحد يقول «PoP مفعّل».

حدود الطلب الموصوف أصغر من أمر العمل

يجعل htm وhtu الإثبات خاصًا بجزء من الطلب. لا ينبغي إعادة إثبات GET كأنه DELETE، ولا نقل إثبات هدف إلى هدف آخر.

لكن htu في المواصفة يستبعد query وfragment. ولا يوقّع DPoP الأساسي أجسام الطلبات أو الحقول الاعتباطية. إذا كان POST /transfer?account=A وPOST /transfer?account=B يؤديان إلى htu نفسها، فلا يميز الإثبات الحسابين. وإذا غُيّر المبلغ أو المستفيد في JSON فلا يصبح الجسم مغطى تلقائيًا.

ليست هذه ثغرة مخفية، بل حد وظيفي مقصود. DPoP يقيد المُرسِل، ولا يحل محل HTTP Message Signatures أو تفويض معاملة أو idempotency على طبقة العمل. تصف RFC 9110 دلالات HTTP، بينما يبقى معنى query وbody وحالة الكائن من مسؤولية الخدمة التي ستنفذ الأثر.

وتزيد البوابات الأمر دقة. يثبت العميل scheme وauthority وpath الخارجي الذي يراه، بينما قد تنهي البوابة TLS وتعيد كتابة المسار وتمرر host داخليًا. إن أعاد backend بناء htu من الجانب الخطأ رفض عملاء صحيحين؛ وإن قبل بدائل رخوة لتجنب الأعطال وسّع سطح القبول. يحتاج سياق الطلب الخارجي وسلسلة forwarding الموثوقة وقواعد normalization إلى مالك واختبارات قابلة للإعادة.

الحداثة حالة موزعة وليست صياغة

يوفر iat وjti مواد كشف الإعادة، ولا يرفضان التكرار بنفسيهما. يختار الخادم العمر المقبول، وتسامح الساعة، ومفتاح سجل replay، ومدة الاحتفاظ، والنسخ التي تتشارك الحالة.

إن سجل إقليم jti ولم يصل السجل إلى إقليم آخر أمكن للإثبات نفسه أن ينجح مرتين. وإن لم تكن عملية الفحص والكتابة ذرية فقد ترى نسختان متزامنتان «غير مستخدم». وإذا ثبت nonce أو أعيد استعماله على نطاق واسع صار طقسًا لا تحديًا حاليًا.

nonce الصادر عن خادم التفويض ليس nonce خادم المورد. على العميل متعدد الخوادم أن يحفظ كل تحدٍ مع مُصدِره، وإلا تحولت آلية الحداثة إلى أخطاء عابرة بين الحدود.

كما أن رفض إثبات مكرر لا يضمن تنفيذًا واحدًا للعمل. يستطيع العميل صنع إثباتين جديدين لمحاولتي retry. كلاهما فريد تشفيريًا. فإذا اكتمل الخصم الأول وضاعت الاستجابة، يقرر idempotency وسجل commit والمصالحة ما إذا كانت المحاولة الثانية تكرر الأثر.

امتلاك المفتاح ليس هوية ولا موافقة

تقول JWK العامة أي مفتاح تحقق به التوقيع، ولا تقول من أنشأه أو يسيطر على العملية، وهل العميل مسجل أو المستخدم وافق على الفعل. يمكن أن تجتمع مصادقة confidential client وDPoP؛ فهما سؤالان مختلفان. يقدم الرمز سياق التفويض الذي أصدره authorization server، ويقدم الإثبات قيد المُرسِل، ويقدم التطبيق الحكم النهائي على المورد.

هذا الفصل مهم في المتصفح. توضح RFC 10017 كيف تجعل non-extractable key سرقة الرمز والمفتاح لاستخدامهما لاحقًا في بيئة أخرى أصعب. لكن JavaScript خبيثًا يعمل أصلًا بصلاحيات origin نفسه يستطيع طلب التوقيع من الواجهة المتاحة، أو إرسال طلب في الجلسة الحية، أو بدء flow جديد. عدم إمكان إخراج المفتاح لا يعني عدم إمكان استعماله من الكود الخطأ في المكان الصحيح.

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

أدلة تمر عبر مسار القبول كله

تسجل IANA الحقلين DPoP وDPoP-Nonce وتدير معاملات OAuth ذات الصلة. يمنح هذا لغة مشتركة، لكنه لا يثبت أن نشرًا بعينه أعاد بناء URI نفسه أو نسق replay أو أبقى قرار المورد مستقلًا.

يجب ربط الإصدار بالنتيجة في الأثر التشغيلي. من دون حفظ رمز خام أو مفتاح خاص، تُحفظ تجزئة آمنة للإثبات، وبصمة المفتاح، ونوع الرمز، ونتيجة ath، وURI الخارجي والداخلي بعد normalization، وعمر الإثبات، ومُصدِر nonce، ونتيجة replay store، ومُصدِر الرمز وجمهوره، وقرار النطاق، وإصدار سياسة المورد، ومعرّف commit النهائي.

وتعبر الاختبارات السلبية المكونات: رمز منسوخ بلا مفتاح؛ المفتاح الصحيح مع رمز خطأ؛ إثبات قديم؛ jti مكرر؛ طريقة خطأ؛ إعادة كتابة بين الخارج والداخل؛ nonce مفقود أو صادر عن غير الجهة؛ جمهور خطأ؛ نطاق ناقص؛ حساب معلق؛ عملية اكتملت. القدرة على شرح موضع كل رفض أقوى من شارة تقول إن DPoP أخضر.