موافقة الخدمات المصرفية المفتوحة كآلة حالات أساسية
استمع إلى المقال
جارٍ تجهيز الصوت…
هندسة التقنيات المالية
أبدأ من التفويض الذي منحه المستخدم فعلاً: النطاق والغرض والأطراف والزمن والحالات النهائية. لا أختزل موافقة الخدمات المصرفية المفتوحة في consented=true.
حدّد الولاية والإصدار
تختلف الموافقة بين الخدمات المصرفية المفتوحة البريطانية وقواعد الاتحاد الأوروبي والتمويل المفتوح في الإمارات وغيرها. يستخدم هذا المقال مواصفة OBIE البريطانية Read/Write API v3.1.2 كمثال هندسي، لا كنموذج قانوني عالمي.
تعرّف مواصفة Account Access Consents v3.1.2 الصلاحيات وأزمنة الإنشاء والتحديث والانتهاء الاختياري، وحالات AwaitingAuthorisation وAuthorised وRejected وRevoked. ويشرح ملف Read/Write API أن «النية» تحمل تفويضاً دقيقاً يتجاوز نطاق OAuth العام.
افصل أربعة أشياء
سجل الموافقة يحدد من طلب ماذا ولأي حسابات ومدة وغرض وإصدار سياسة. جلسة التفويض تحفظ دليل مصادقة المستخدم وما عُرض عليه واختياره. أما رموز الوصول والتحديث فهي بيانات اعتماد تقنية لها جمهور ونطاق وانتهاء. وأخيراً يقيّم خادم المورد حالة الموافقة والرمز والاستحقاق في كل طلب.
قد ينتهي رمز الوصول بينما تبقى موافقة طويلة الأجل مخولة؛ وتذكر مواصفة OBIE هذا الفصل. وبالعكس، يجب أن توقف حالة Revoked الوصول حتى لو كان الانتهاء التشفيري للرمز لاحقاً.
استخدم آلة حالات حقيقية
تبدأ الموافقة بـAwaitingAuthorisation، ثم تنتقل إلى Authorised عند نجاح رحلة المستخدم أو Rejected عند الرفض. والإلغاء ينقلها إلى Revoked. الحالات النهائية لا تُفتح من جديد؛ أنشئ موافقة جديدة بدليل جديد. احفظ الحالة ووقت التحديث والإصدار وسجل انتقالات إضافياً غير قابل للتعديل.
مثّل الصلاحيات كبيانات قابلة للتنفيذ: الحسابات، ومجموعات البيانات، وفترة الحركات، والانتهاء، والطرف الطالب، والغرض. لا تفترض أن نطاق accounts يعبّر عن هذه التفاصيل.
تحدد FAPI 2.0 Security Profile، التي وصلت إلى الإصدار النهائي في 20 فبراير 2025، ضوابط لواجهات عالية القيمة مثل رموز الوصول المقيدة بالمرسل. لكن التطبيق يعتمد على ملف النظام البيئي الفعلي.
مثّل النطاق كبيانات قابلة للتنفيذ
أربط الموافقة بمعرفات الصلاحيات والحسابات المختارة أو قاعدة اختيارها، ومجموعات البيانات، ونافذة تاريخ الحركات، والانتهاء، والطرف الطالب، والبنك، والمستخدم. أحفظ إصدار الإفصاح والسياسة وبصمة أو مرجعاً ثابتاً لما ظهر للمستخدم. بهذه الصورة يستطيع خادم المورد تقييم الطلب آلياً، ويستطيع التحقيق إعادة بناء ما كان مسموحاً وقت الوصول.
لا أفترض أن نطاق OAuth عام مثل accounts يعبّر عن اختيار حسابين دون غيرهما أو عن فترة زمنية محددة. وقد يكون الغرض مهماً رقابياً حتى لو تعذر فرضه بالكامل في طبقة البروتوكول؛ لذلك أسجله وأستخدمه في السياسة والمراقبة، وأتجنب إعادة استعمال البيانات في منتج لم تشمل الموافقة غرضه. النطاق نص تعاقدي أيضاً، لكنه يجب أن يتحول إلى قواعد يمكن اختبارها.
الإلغاء عملية شاملة
يجب أن يحدّث الإلغاء سلطة الموافقة ويوقف الرموز والذاكرة المخبأة والجمع المجدول والمنتجات التابعة وفق السياسة. وتطلب مواصفة OBIE من الطرف الثالث استدعاء DELETE عند إلغاء المستخدم لديه قبل تأكيد الإلغاء. احتفظ بدليل الانتقال حتى لو عرضت الواجهة دلالة الحذف.
أما البيانات المجموعة سابقاً فلها سياسة احتفاظ وحذف مستقلة؛ إلغاء الوصول المستقبلي لا يجيب تلقائياً عن مصيرها.
اختبر الحالات غير المريحة
أختبر التخلي عن رحلة التفويض، ورفض المستخدم، واختيار بعض الحسابات، وانتهاء الموافقة أثناء تحديث الرمز، والإلغاء المتزامن مع قراءة، وتكرار الاستدعاء، وانحراف الساعة، وتدوير شهادة الطرف الثالث، ومهمة خلفية تعمل على صلاحية مخبأة. لكل حالة أحدد أي سجل هو صاحب القرار وما الدليل الذي يجب أن يبقى.
يجب أن يستطيع المدقق الإجابة: ما الذي طُلب، وما الذي عُرض، ومن فوّض، وأي حسابات وبيانات شملها القرار، وأي إصدار سياسة طُبق، ومتى حدث الوصول، ولماذا توقف؟ لا أحتاج إلى تسجيل رموز الاعتماد أو بيانات شخصية غير لازمة لتحقيق ذلك. أفضل المعرفات الثابتة والبصمات وسجل الانتقالات على نسخ أسرار الجلسة.
أراقب اكتمال التفويض والرفض وزمن انتشار الإلغاء ورفض الوصول حسب السبب ومحاولات استعمال موافقة منتهية واكتشاف الذاكرة المخبأة القديمة والمهام التي توقفت بعد الإلغاء. إذا ظل نظام تحليلي يجمع البيانات بعد أن أصبحت الحالة Revoked، فنجاح واجهة الحذف وحدها لا يعني أن الإلغاء نجح.
القاعدة الهندسية
قاعدتي أن أجعل الموافقة تجميعاً مجالياً من الدرجة الأولى وأن تشير الرموز إليها، لا أن تستبدلها. أقيّم الموافقة والرمز والاستحقاق عند الوصول، وأحفظ دليل الانتقال، وأصرح بالولاية وإصدار المواصفة. قبل الإطلاق أمرر موافقة واحدة عبر التفويض والوصول وانتهاء الرمز وإعادة المصادقة والإلغاء من كل قناة، ثم أتحقق من توقف المهام التابعة ومعالجة الاحتفاظ أو الحذف وفق السياسة.
أكرر المراجعة عندما تتغير الولاية أو نسخة الملف أو مجموعة البيانات المطلوبة أو دور الطرف الثالث. هذه التغييرات قد تبدل العقد والأدلة اللازمة معاً. القيمة المنطقية تستطيع قول «نعم»، لكنها لا تشرح ما الذي أُجيز ولا أي نظام يجب أن يتوقف عندما تصبح الإجابة «لا».
قبل الإنتاج أبني جدولاً يربط كل حالة موافقة بما تسمح به من إصدار رمز وقراءة بيانات وتشغيل مهمة مجدولة. أختبر الجدول عبر خادم التفويض وخادم المورد والذاكرة المخبأة والأنظمة التابعة، لا داخل خدمة واحدة فقط. ثم أستخدم ساعة مضبوطة لاختبار اللحظة السابقة للانتهاء واللحظة التالية له، مع طلب متزامن وإلغاء صادر من قناة أخرى.
أراجع كذلك تجربة المستخدم: يجب أن يرى الطرف الطالب والغرض والحسابات والبيانات والمدة بلغة واضحة، وأن يستطيع معرفة أين يلغي. لا أخلط سجل الموافقة التسويقية بموافقة وصول تقني. وإذا احتاج المنتج إلى غرض جديد أو مجموعة بيانات جديدة، أنشئ رحلة تفويض جديدة بدلاً من توسيع سجل قديم في الخلفية.
في الدعم أو التحقيق أبدأ بمعرف الموافقة وأتنقل إلى جلسة التفويض والرموز المستخدمة وقرارات المورد والمهام التابعة. إذا فقدت إحدى الحلقات، قد تبدو الواجهة صحيحة بينما يستمر وصول غير مشروع. لذلك أعد سلامة الرابط بين هذه السجلات جزءاً من ضوابط التشغيل والمراجعة الدورية.
وعند تصميم الذاكرة المخبأة أضع مدة قصيرة وحداً لإبطالها عند الإلغاء، وأتعامل مع فشل الإبطال كحادث وصول لا كمشكلة أداء فقط. أختبر عقدة معزولة لم تستلم الحدث، ورمزاً صالحاً تشفيرياً لموافقة أُلغيت، ومهمة بدأت قبل الإلغاء وتكتب بعده. بهذه الحالات أتأكد أن القرار النهائي يعود إلى سلطة الموافقة الحالية، لا إلى نسخة قديمة مريحة.
اختبر التخلي عن الرحلة، والرفض، واختيار بعض الحسابات، والانتهاء أثناء تحديث الرمز، والإلغاء المتزامن مع القراءة، وانحراف الساعة، ومهمة تابعة تستخدم صلاحية مخبأة. وقِس زمن انتشار الإلغاء ومحاولات استخدام موافقة منتهية وأسباب رفض الوصول.
قاعدتي التصميمية أن أجعل الموافقة تجميعاً مجالياً من الدرجة الأولى، وأن تشير الرموز إليها. أقيّم الاثنين عند الوصول وأحفظ دليل الانتقال؛ فالقيمة المنطقية لا تشرح لماذا أو لأي بيانات أو حتى متى أو من يجب أن يتوقف.
ما القرار الذي كنت ستتخذه؟
شارك سؤالاً أو تجربة أو رأياً مخالفاً. التعليقات متاحة للأعضاء المسجلين للحفاظ على نقاش مهني ومفيد.