مصادقة OAuth في واجهة الفوترة الإلكترونية

عندما تبني نظاماً يتحدث مع واجهات برمجية (APIs) خارجية، يظهر سؤال واحد قبل أي شيء آخر: من أنت، وما الذي يُسمح لك بالوصول إليه؟ هذا هو جوهر «المصادقة» و«التفويض». في عالم الفوترة الإلكترونية تتعدد طرق إثبات الهوية بين الأنظمة، ومن أشهرها معيار OAuth 2.0 الذي صار اللغة المشتركة لمعظم الواجهات الحديثة.

في هذا الدليل نشرح مصادقة OAuth من جذورها للمطورين والمدمجين التقنيين: ما هي، وكيف يعمل تدفق رمز الوصول، وما الفرق بين رمز الوصول ورمز التحديث، وما معنى النطاقات (Scopes). والأهم من ذلك، نوضّح نقطة دقيقة كثيراً ما تُساء: واجهات منصة فاتورة الخاصة بهيئة الزكاة والضريبة والجمارك لا تستخدم OAuth لإرسال الفواتير، بل تعتمد على المصادقة الأساسية (Basic Auth) مع شهادة CSID. الخلط بين الأمرين سبب شائع جداً لأخطاء الربط.

ما هي مصادقة OAuth 2.0؟

OAuth 2.0 هو معيار مفتوح للتفويض، يتيح لتطبيق أو خدمة الوصول إلى موارد محمية على خادم آخر دون أن يشارك كلمة المرور الأصلية. بدلاً من تمرير اسم المستخدم وكلمة المرور في كل طلب، يحصل التطبيق على «رمز وصول» (Access Token) مؤقت يثبت هويته وصلاحياته.

الفكرة الأساسية بسيطة. تخيّل فندقاً يمنحك بطاقة دخول إلكترونية بدلاً من مفتاح رئيسي لكل الأبواب. البطاقة تفتح غرفتك فقط، ولفترة محددة، ويمكن إلغاؤها في أي لحظة دون تغيير أقفال الفندق كلها. رمز الوصول في OAuth يعمل بالمنطق نفسه: صلاحية محدودة، ومدة محدودة، وقابلية إلغاء فورية.

من المهم التفريق بين مصطلحين يخلط بينهما كثيرون. «المصادقة» (Authentication) تعني إثبات من أنت. أما «التفويض» (Authorization) فيعني تحديد ما يُسمح لك بفعله بعد إثبات هويتك. OAuth في جوهره معيار تفويض، لكنه يُستخدم عملياً كطبقة تثبت الهوية وتمنح الصلاحية معاً في تكاملات الأنظمة.

يحل OAuth مشكلة قديمة في تكامل الأنظمة. قبله كانت التطبيقات تخزّن كلمات مرور المستخدمين لتتصرف نيابة عنهم، وهي ممارسة خطيرة. مع OAuth لا يرى التطبيق كلمة المرور أبداً، بل يحصل على رمز محدود الصلاحية يمكن سحبه دون المساس بالحساب الأصلي.

لماذا يهم OAuth في تكامل أنظمة الفوترة؟

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

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

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

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

تدفق بيانات اعتماد العميل (Client Credentials Grant)

يحدد معيار OAuth 2.0 عدة أنواع من «تدفقات المنح» (Grant Types)، كل منها مناسب لسيناريو مختلف. في تكامل الأنظمة من خادم إلى خادم، حيث لا يوجد مستخدم بشري يضغط زر الموافقة، يكون التدفق الأنسب هو «تدفق بيانات اعتماد العميل» (Client Credentials Grant).

كيف يعمل هذا التدفق خطوة بخطوة

في هذا النوع، يملك النظام المتكامل معرّفاً للعميل (Client ID) ومفتاحاً سرياً (Client Secret) أصدرهما له مزوّد الخدمة مسبقاً. يستخدم النظام هذين العنصرين للحصول على رمز وصول من خادم التفويض، ثم يستعمل الرمز في كل طلب لاحق على الواجهة البرمجية.

عملياً يبدأ كل شيء بطلب واحد إلى نقطة إصدار الرموز (Token Endpoint). يرسل النظام بيانات الاعتماد ويطلب رمزاً، كما في المثال التالي:

POST /oauth/token HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET
&scope=invoices.read invoices.write

إذا كانت البيانات صحيحة، يرد خادم التفويض برمز وصول وبيانات إضافية تصف نوعه ومدة صلاحيته والنطاقات الممنوحة:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "invoices.read invoices.write"
}

بعد الحصول على الرمز، يضعه النظام في ترويسة كل طلب لاحق على الواجهة البرمجية. تُستخدم ترويسة التفويض القياسية مع كلمة Bearer التي تعني «حامل الرمز»:

GET /v2/invoices HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json

يتحقق الخادم من الرمز في كل طلب: هل هو صالح؟ هل انتهت مدته؟ هل يحمل النطاق المطلوب لهذه العملية؟ إذا اجتاز الفحص، تُنفّذ العملية. هذا الفصل بين بيانات الاعتماد الدائمة والرمز المؤقت هو ما يجعل OAuth أكثر أماناً من تمرير كلمة مرور في كل طلب.

رمز الوصول ورمز التحديث: الفرق والدورة

رمز الوصول (Access Token) قصير العمر بطبيعته. المدة الشائعة ساعة واحدة أو أقل، كما رأينا في القيمة expires_in بالثواني. هذا القِصر مقصود: لو تسرّب الرمز، تنتهي صلاحيته سريعاً وتقلّ مدة الخطر.

لكن انتهاء الرمز كل ساعة يطرح سؤالاً عملياً: هل يعيد النظام إرسال بيانات الاعتماد في كل مرة؟ في تدفق بيانات اعتماد العميل، نعم، يطلب النظام رمزاً جديداً عند انتهاء القديم لأنه يملك المفتاح السري أصلاً. أما في التدفقات التي تشمل مستخدماً بشرياً، فيظهر «رمز التحديث» (Refresh Token).

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

طلب التحديث يبدو كالتالي. لاحظ أن grant_type تغيّر إلى refresh_token:

POST /oauth/token HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=def502004a8f...
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET

قاعدة عملية مهمة لكل مطوّر: خزّن رمز التحديث في مكان آمن، ولا تُرسله أبداً مع طلبات الموارد العادية. رمز التحديث أثمن من رمز الوصول لأنه يفتح باب إصدار رموز جديدة. تسرّبه أخطر بكثير من تسرّب رمز وصول واحد سينتهي خلال دقائق.

النطاقات (Scopes): تحديد الصلاحيات بدقة

النطاق في OAuth وسم نصي يحدد صلاحية معينة. عند طلب الرمز، يطلب النظام مجموعة من النطاقات، ويمنحه خادم التفويض ما يحق له منها فقط. الرمز الناتج محصور بهذه النطاقات، فلا يستطيع تجاوزها مهما حاول.

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

هذا المبدأ يُعرف بـ«أقل صلاحية ممكنة» (Least Privilege)، وهو من أهم قواعد أمان الواجهات البرمجية. كل صلاحية إضافية تمنحها لتطبيق هي باب إضافي قد يُساء استخدامه إذا تعرّض التطبيق للاختراق.

أنواع تدفقات المنح في OAuth وأيها يناسب الفوترة

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

تدفق بيانات اعتماد العميل (Client Credentials) هو الأنسب للتكامل بين خادم وخادم، حيث لا مستخدم بشري في الصورة. وهذا هو النمط الغالب في تكامل أنظمة الفوترة والمحاسبة، لأن التطبيق نفسه هو المالك للموارد لا وكيلاً عن مستخدم.

تدفق رمز التفويض (Authorization Code) يناسب الحالات التي يمنح فيها مستخدم بشري تطبيقاً إذن الوصول إلى بياناته. مثلاً عندما يربط مالك متجر حسابه في نظام محاسبي بأداة خارجية، فيظهر له شاشة موافقة. هذا التدفق يستخدم رمز التحديث بكثرة للإبقاء على الجلسة.

هناك تدفقات قديمة مثل تدفق كلمة المرور (Password Grant) وتدفق ضمني (Implicit) لم تعد موصى بها أمنياً في معظم الحالات. القاعدة العملية: للتكامل التقني بين الأنظمة استخدم بيانات اعتماد العميل، ولتفويض مستخدم بشري استخدم رمز التفويض، وتجنّب الباقي ما لم يكن هناك سبب قوي.

جدول مختصر لاختيار التدفق المناسب

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

رموز JWT مقابل الرموز المبهمة

رموز الوصول في OAuth تأتي على شكلين رئيسيين. الأول رمز JWT (JSON Web Token)، وهو رمز موقّع يحمل بداخله معلومات مقروءة بعد فك الترميز، مثل هوية العميل والنطاقات ووقت الانتهاء. الخادم يتحقق من توقيعه دون الرجوع إلى قاعدة بيانات في كل مرة.

الشكل الثاني الرمز المبهم (Opaque Token)، وهو سلسلة عشوائية لا تحمل معنى بذاتها. للتحقق منه يجب على الخادم الرجوع إلى خادم التفويض أو قاعدة البيانات. هذا الشكل أبطأ قليلاً لكنه يتيح إلغاء الرمز فورياً، بينما رمز JWT يبقى صالحاً حتى انتهاء مدته ما لم تُضف آلية إلغاء إضافية.

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

حالة عملية: متجر إلكتروني يتكامل مع نظام محاسبي

لنجمع المفاهيم في سيناريو واقعي. متجر إلكتروني يريد أن يرسل كل طلب بيع جديد إلى نظام محاسبي ليتحول إلى فاتورة متوافقة. كيف تعمل المصادقة هنا من البداية للنهاية؟

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

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

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

رابعاً، عندما يقترب الرمز من الانتهاء أو يرد الخادم بالخطأ 401، يطلب المتجر رمزاً جديداً ويعيد المحاولة. بهذه الدورة البسيطة يبقى التكامل آمناً ومستمراً دون تدخل بشري.

هذا السيناريو يوضّح التقسيم الصحيح للمسؤوليات: المتجر يصادق مع النظام المحاسبي عبر OAuth، والنظام المحاسبي يصادق مع الهيئة عبر CSID. كل طبقة بآليتها المناسبة. لمزيد من التفصيل حول الطبقة التقنية للفاتورة وبيئة اختبار التكامل، راجع بيئة المحاكاة (Sandbox) للمطورين.

نقطة دقيقة: واجهات منصة فاتورة لا تستخدم OAuth

هنا أهم تصحيح في هذا الدليل، وهو خطأ متكرر بين المطورين الجدد على الفوترة الإلكترونية السعودية. واجهات منصة فاتورة الخاصة بهيئة الزكاة والضريبة والجمارك، المسؤولة عن المقاصة والإبلاغ، لا تستخدم OAuth 2.0 لإرسال الفواتير. بل تعتمد على المصادقة الأساسية (Basic Authentication) باستخدام شهادة CSID.

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

لماذا اختارت الهيئة هذا النهج؟ لأن الهدف ليس مجرد إثبات هوية مؤقتة، بل ربط كل فاتورة بهوية تشفيرية ثابتة لا تقبل التزوير. شهادة CSID من نوع X.509 توفّر هذا الربط عبر التوقيع الرقمي، وهو متطلب يتجاوز ما يقدمه رمز وصول بسيط. لتفاصيل الشهادة نفسها راجع دليل شهادة CSID ومعرّف الختم التشفيري.

الخلاصة العملية: إذا كنت تبني تكاملاً مباشراً مع منصة فاتورة، فستتعامل مع المصادقة الأساسية وشهادة CSID، لا مع OAuth. أما إذا كنت تبني تكاملاً مع نظام محاسبي أو منصة وسيطة تتولى هي بدورها الربط مع الهيئة، فقد تتعامل مع OAuth على طبقة ذلك النظام. فهم أي طبقة تعمل عليها يحدد آلية المصادقة الصحيحة.

أين يظهر OAuth فعلياً في منظومة الفوترة؟

بعد أن وضّحنا أن منصة فاتورة لا تستخدم OAuth، يبقى السؤال: أين يظهر إذن؟ الإجابة في الطبقات التي تسبق الهيئة أو تحيط بها، لا في خطوة الإرسال إليها.

السيناريو الأول هو المنصات الوسيطة. كثير من المنشآت الكبيرة تستخدم طبقة وسيطة (Middleware) تجمع الفواتير من عدة أنظمة داخلية ثم تربطها بمنصة فاتورة. الأنظمة الداخلية تتحدث مع الوسيط عبر واجهة برمجية محمية بـ OAuth، ثم يتولى الوسيط بدوره المصادقة الأساسية مع الهيئة عبر CSID.

السيناريو الثاني هو التكامل مع الأنظمة المحاسبية والتجارية. عندما يربط متجر إلكتروني نفسه بنظام محاسبي ليرسل بيانات الطلبات وتتحول إلى فواتير، تُحمى هذه الواجهة عادة بـ OAuth. النظام المحاسبي هو من يتولى لاحقاً التعامل مع الهيئة. هذا هو النمط الذي يعمل به تكامل قيود مع الأنظمة الخارجية.

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

لفهم كيفية الربط الفعلي مع الهيئة وتسلسل الخطوات، راجع دليلي تكامل API مع منصة فاتورة والتهيئة والربط مع منصة فاتورة، وكلاهما يشرح الطبقة التي تتولاها الهيئة مباشرة.

أفضل ممارسات أمان OAuth للمطورين

بناء طبقة مصادقة سليمة يتطلب الالتزام بمجموعة من القواعد التي تختصر سنوات من أخطاء الصناعة. إليك أبرزها:

• احفظ المفتاح السري للعميل (Client Secret) في خزنة أسرار، لا في الكود المصدري ولا في مستودع جيت. تسرّبه يعني انكشاف هويتك بالكامل.
• استخدم بروتوكول HTTPS في كل طلب دون استثناء. إرسال رمز وصول عبر اتصال غير مشفّر يجعله عرضة للاعتراض.
• اطلب أقل النطاقات الممكنة. لا تطلب صلاحية كتابة إذا كان تطبيقك يقرأ فقط.
• تعامل مع انتهاء الرمز بأناقة. عندما يرد الخادم برمز الخطأ 401، اطلب رمزاً جديداً وأعد المحاولة بدلاً من إظهار خطأ للمستخدم.
• خزّن رمز التحديث بأمان أشد من رمز الوصول، ولا ترسله إلا إلى نقطة إصدار الرموز.
• راقب الرموز المُصدَرة، وألغِ أي رمز يُشتبه في تسرّبه فوراً عبر آلية الإلغاء التي يوفرها مزوّد الخدمة.

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

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

التعامل مع أخطاء المصادقة الشائعة

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

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

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

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

كيف يبسّط قيود طبقة المصادقة عنك

كل ما سبق يوضّح أن بناء طبقة مصادقة سليمة عمل دقيق ومسؤولية أمنية كبيرة. الخبر الجيد أن قيود يتولى الجزء الأصعب نيابة عنك في كل ما يخص الفوترة الإلكترونية.

قيود نظام محاسبي سحابي يدير دورة الفاتورة الإلكترونية كاملة. يربط منشأتك بمنصة فاتورة، ويدير شهادة CSID والمفتاح الخاص بأمان، ويوقّع كل فاتورة رقمياً، ويتولى المقاصة للفواتير بين المنشآت والإبلاغ لفواتير الأفراد. أنت لا تتعامل مع المصادقة الأساسية ولا مع تفاصيل الشهادات بنفسك.

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

جرّب قيود مجاناً لمدة 14 يوماً دون بطاقة ائتمان.

الأسئلة الشائعة

هل تستخدم منصة فاتورة OAuth لإرسال الفواتير؟
لا. واجهات منصة فاتورة الخاصة بهيئة الزكاة والضريبة والجمارك تستخدم المصادقة الأساسية (Basic Auth) المبنية على شهادة CSID للمقاصة والإبلاغ، وليس OAuth. يظهر OAuth في طبقات تكامل الأنظمة العامة والمنصات الوسيطة، لا في خطوة الإرسال إلى الهيئة.

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

ما هو تدفق بيانات اعتماد العميل؟
هو نوع منح في OAuth مخصص للتكامل بين خادم وخادم دون تدخل مستخدم بشري. يستخدم النظام معرّف العميل ومفتاحه السري للحصول على رمز وصول مباشرة من خادم التفويض.

ما المقصود بالنطاقات (Scopes)؟
النطاقات وسوم تحدد صلاحيات الرمز بدقة، مثل قراءة الفواتير أو إنشائها. تتيح تطبيق مبدأ أقل صلاحية ممكنة، فلا يُمنح التطبيق إلا ما يحتاجه فعلاً.

هل أحتاج لبناء طبقة OAuth بنفسي لاستخدام الفوترة الإلكترونية في قيود؟
لا. قيود يتولى الربط مع منصة فاتورة وإدارة الشهادات والتوقيع الرقمي والمقاصة والإبلاغ نيابة عنك. تستخدم النظام مباشرة دون بناء طبقة مصادقة مع الهيئة.

ماذا يعني الخطأ 401 عند استدعاء واجهة برمجية؟
يعني أن الطلب غير مصرّح به، غالباً بسبب رمز مفقود أو منتهٍ أو غير صحيح. الحل عادة إصدار رمز وصول جديد وإعادة المحاولة.