هوية الوكيل بدائية تحتية، وليست تسجيل دخول

افتراض الجلسة ينهار

تُبنى معظم أنظمة الوكلاء على افتراض ضمني موروث من أتمتة الويب: أن الوكيل متصفح أسرع. يحمل جلسة مستخدم، ويقدّم نفس ملفات تعريف الارتباط، ويصل إلى نفس نقاط النهاية. يصمد هذا الافتراض ما دام الوكيل يقرأ فقط. لكنه ينهار لحظة محاولة الوكيل إجراء معاملة.

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

الفجوة ليست في المصادقة. الفجوة في الهوية.

ما تحتاجه الهوية المفوَّضة

الهوية الآلية المفوَّضة هي اعتماد تصدره لوحة تحكم الأصل إلى وكيل محدد، ويحمل دورة حياته الخاصة. له ثلاث خصائص لا توجد في جلسة المستخدم.

معرّف مستقر منفصل عن الأصل

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

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

تضييق النطاق الصريح

يجب أن تكون المنحة المفوَّضة ضيقة على ثلاثة محاور في آن واحد:

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

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

مسار إلغاء لا يمس الإنسان

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

قاعدة التصميم: الهوية كمورد في لوحة التحكم

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

هذا يعني أن لوحة التحكم تحتاج إلى سجل بدورة حياة محددة لكل وكيل:

agent_id        مستقر، غامض، لا يُعاد استخدامه أبداً
principal_id    جذر السلطة
key_material    المفتاح العام، جدول التدوير
scopes          [{counterparty, action_class, window}]
state           active | suspended | revoked
rate_limits     لكل طرف مقابل، لكل action_class
audit_log       إلحاقي فقط، كل تقديم مسجّل

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

التصميم للرفض

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

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

المقايضة

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

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

إلى أين يؤدي هذا

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

الفرق التي تتعامل معها كبنية تحتية — تُصدر، وتحدد نطاقها، وتحدّ معدلها، وتلغيها، وتسجّلها — سيكون لديها جواب. وسيكون لديها أيضاً سجل التدقيق لإثباته.