الرئيسية›فهرس المنصات›نفاذ — النفاذ الوطني الموحد

نفاذ — النفاذ الوطني الموحدNafath (national single sign-on)

REQUIRES_APPROVALجهة حكومية (يذكر الدليل وزارة المالية في المراجع)متطلب وارد في الملفات يحتاج تحققًا أو موافقة رسمية

منصة التحقق من الهوية والدخول الموحد. قد تُستخدم لدخول الموكّل أو التوقيع الموثّق، و«إجراءات الربط تحتاج تأكيدًا» (دليل المطور ص21).

تنبيه

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

1ما المنصة، ومن الجهة المالكة، وما اختصاصها؟

خدمة حكومية للتحقق من الهوية والدخول للخدمات الإلكترونية.

2ما الإجراء الذي ينفذه المحامي فيها؟

لا شيء من المحامي في ERPOS؛ الموكّل يتحقق بتطبيق نفاذ عند الربط.

3متى يحتاج إليها المحامي؟

دخول البوابة أو توقيع عقد مهم B22 العقود الإلكترونية واتفاقيات الأتعاب والتوقيع.

4ميزات ERPOS المرتبطة بها

B01 المستخدمون والأدوار والصلاحيات، B22 العقود الإلكترونية واتفاقيات الأتعاب والتوقيع، B35 بوابة الموكّل وتطبيقه.

5الخدمة المحددة المطلوبة من المنصة

التحقق من الهوية وتوثيق المعاملة (كما يذكر الدليل) (دليل المطور ص21).

6نوع الحاجة: قراءة أو إرسال أو مزامنة أو إشعارات

طلب تحقق ثم انتظار النتيجة.

7البيانات الداخلة والخارجة وحساسيتها ومصدرها

رقم الهوية خارج؛ نتيجة التحقق داخل. حساسية عالية.

8هل يوجد API رسمي موثق لهذه الخدمة تحديدًا؟

لم نجد في الملفات ولا في المصادر التي رُوجعت واجهة برمجية رسمية موثقة لهذه الخدمة تحديدًا: غير مثبت في المصادر التي تمت مراجعتها. لا نكتب endpoints أو حقولًا.

9المصدر الرسمي وتاريخ التحقق

المصدر	الرابط	ما تحقّقنا منه	تاريخ التحقق
النفاذ الوطني الموحد	https://www.iam.gov.sa	تفتح صفحة تسجيل الدخول «النفاذ الوطني الموحد» (تطبيق نفاذ أو اسم مستخدم). لا توثيق ربط للجهات في هذه الصفحة	2026-11-04

10حالة التحقق

REQUIRES_APPROVAL

REQUIRES_APPROVAL: خدمة حكومية تتطلب إجراءات ربط تحتاج تأكيدًا (دليل المطور ص21).

11ما الذي يثبته المصدر الرسمي وما الذي لا يثبته؟

لا يثبت أهلية المنصة للربط.

12التسجيل والاعتماد والتفويض والمصادقة وبيئة الاختبار

غير مثبت في المصادر التي تمت مراجعتها.

13خطوات الربط من جهة ERPOS

لا تبدأ قبل الموافقة. حتى ذلك: دخول الموكّل بـ OTP B35 بوابة الموكّل وتطبيقه.

14تصميم Adapter مستقل للمنصة

واجهة NafathAdapter مستقلة في legal_erp/integrations/nafath.py ترث النمط الموحد نمط موصل التكامل بعمليات: start_verification، poll_status. تنفيذان: يدوي (يفتح نموذج إدخال للموظف ويسجل المصدر «يدوي») ورسمي (لا يُكتب قبل استلام توثيق رسمي وموافقة)، ويُختار من الإعداد لكل مكتب اقتراح هندسي.

15تدفق البيانات ومخطط التسلسل

مخطط تسلسل من جهة ERPOS؛ لا يمثّل واجهة حكومية موثقة ما لم يُذكر ذلك صراحة.

16نموذج الطلب والاستجابة

غير متاح قبل الاعتماد.

17انتهاء المهلة وانقطاع الخدمة والرفض وتضارب الحالة

انتهاء المهلة ← فشل مؤقت ← إعادة أسية في الطابور.
انقطاع الخدمة أو أخطاء متتالية ← إيقاف الموصل وتنبيه المدير B43 طبقة التكامل المركزية.
رفض (صلاحية، تفويض) ← فشل دائم يظهر للمسؤول بلا إعادة.
تضارب الحالة مع البيانات المحلية ← سجل فرق يقرره إنسان؛ لا كتابة صامتة ولا حذف محلي عند استجابة فارغة.

18منع التكرار وإعادة المحاولة الآمنة

كل عملية صادرة بمفتاح عدم تكرار يُحفظ مع السجل؛ إعادة المحاولة ترسل المفتاح نفسه، وكل حدث وارد يُتجاهل إن تكرر معرّفه أو بصمته B43 طبقة التكامل المركزية.

19حفظ المصدر ووقت الجلب وإيصال الجهة وسجل التدقيق

يُحفظ مع كل قيمة: data_source (يدوي/الجهة)، وقت الجلب، معرّف الاستدعاء أو رقم الإيصال من الجهة إن وُجد، والمستخدم أو المهمة المجدولة. سجل الاستدعاء لا يحفظ جسم الاستجابة ولا بيانات شخصية (خطة ناجز ص14).

20المسار اليدوي المصرح به

البديل المصرح به: OTP على جوال الموكّل مع أثر كامل، مع وصفه في الواجهة بدقة: «موافقة بالتحقق من الجوال».

21اختبارات التكامل والفشل والتفويض والتكرار والعزل

المعرّف	النوع	السيناريو	النتيجة المتوقعة
`INT-NFD-01`	تكامل	بيئة وهمية تعيد نجاحًا	تُحفظ القيمة بمصدرها ووقتها.
`INT-NFD-02`	فشل	مهلة ثم نجاح	إعادة واحدة بلا تكرار.
`INT-NFD-03`	تفويض	مفتاح أو تفويض غير صالح	فشل دائم وتنبيه، لا إعادة.
`INT-NFD-04`	تكرار	إرسال الحدث نفسه مرتين	يُعالج مرة.
`INT-NFD-05`	عزل	مكتبان على الخادم نفسه	لا يرى أحدهما بيانات الآخر ولا مفتاحه.

22المخاطر والقرارات التي تحتاج موافقة الجهة

متطلبات الربط والأهلية.