حل خطأ المعامل المفقود AADSTS900144 في Azure AD

By Mirko Peters · 2026-04-21

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

Automatically translated with AI from the original post. Read the English original

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

سواء كنتم تدعمون Microsoft 365 أو Azure أو Power Platform أو أي حل متصل بـ Entra ID، ستجدون هنا نصائح للإصلاحات من جهة العميل ومن جهة الخادم. تتضمن هذه المادة استكشاف أخطاء من واقع العمل، وأفضل الممارسات الجاهزة للمؤسسات، وروابط إضافية إلى محتوى حوكمة السحابة، وكلها تهدف إلى مساعدتكم على تجنب هذه المشكلات في المرات القادمة عندما يظهر هذا الخطأ مجدداً.

لماذا يظهر الخطأ “AADSTS900144” في مصادقة Azure AD؟

يظهر الخطأ “AADSTS900144: Request body must contain the following parameter” عندما تكون تفاصيل أساسية مفقودة من طلب المصادقة المرسل إلى Azure Active Directory (أو Microsoft Entra ID). بعبارة بسيطة، يبحث Azure عن معلومات مثل grant_type أو client_id في طلب الرمز المميز، فلا يجدها، أو تكون موجودة لكن بتنسيق خاطئ أو في مكان غير صحيح.

يكثر ظهور هذا الخطأ أثناء تدفقات OAuth 2.0، خاصة عندما يحاول المستخدمون أو التطبيقات تسجيل الدخول عبر خدمات السحابة المؤسسية. عادةً ما يحدث ذلك بسبب خلل ما في معاملات نص الطلب المرسلة عند استبدال رمز التفويض برمز مميز. فإذا حُذف معامل إلزامي، أو أُخطئ في كتابته، أو وُضع خارج نص طلب POST المتوقع، يتوقف Azure AD عن معالجة الطلب ويعرض الرمز AADSTS900144.

قد تواجه هذا الخطأ عند دمج تطبيقات أعمال مخصصة، أو تسجيل تطبيقات جديدة في Azure، أو عندما تواجه تطبيقات سطح المكتب (مثل Microsoft Teams) مشكلات في المصادقة. وأحياناً قد يكفي خطأ نسخ ولصق بسيط أو تحديث سريع لتسجيل التطبيق لكي يخرج المعامل عن التزامن. قد تبدو رسالة الخطأ غامضة، لكنها في حقيقة الأمر طريقة Azure لإخبارك: “ارجع وتحقق من طلبك جيداً، وأصلح ما هو مفقود.”

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

مشكلات معاملات نص الطلب الشائعة والحلول السريعة

يعود خطأ AADSTS900144 دائماً تقريباً إلى أن شيئاً ما قد أُغفل، أو وُضع في المكان الخطأ ضمن طلب الرمز المميز. والعناصر الرئيسية مثل client_id وgrant_type هي المشتبه بهم المعتادون. فإذا أغفل تطبيقك معاملاً إلزامياً واحداً، يرفض نقطة نهاية الرموز المميزة في Azure AD الطلب رفضاً قاطعاً. تحقّق من أنك تستخدم طريقة HTTP POST، إذ لن تنفع طلبات GET أو الأفعال الأخرى هنا.

ابدأ بالتأكد من أن تطبيقك يرسل الطلبات بنوع المحتوى application/x-www-form-urlencoded. ومن المدهش كم مرة يؤدي نوع المحتوى الخاطئ إلى أن يبحث Azure AD عن معاملات لا يستطيع قراءتها. بعد ذلك، افتح أي أداة لطلبات HTTP (مثل Postman أو curl أو حتى Fiddler) وافحص نص الطلب الخام: هل تظهر client_id وgrant_type وclient_secret وغيرها فعلاً ضمن الحمولة، وليس كقيم في سلسلة الاستعلام أو مخفية في الترويسات؟

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

في التطبيقات متعددة المستأجرين، احذر من إرسال الطلبات إلى نقطة النهاية /common عندما يحتاج المستأجر المستهدف إلى معرّف GUID أو قيمة محددة، وإلا فقد يكون “المعامل المفقود” مجرد طلب موجَّه إلى المكان الخطأ. فالتوجيه إلى عنوان URL غير صحيح، خاصة في سيناريوهات تعدد المستأجرين، قد يربك حتى المطورين ذوي الخبرة، لذا تحقّق دائماً من نقطة النهاية والمعاملات معاً. أصلح هذه الأمور، وفي معظم الحالات سيختفي خطأ AADSTS900144 المزعج أمام ناظريك.

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

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

الخطوة الأولى الأسهل هي مسح بيانات الاعتماد المحفوظة. في Windows، استخدم "إدارة بيانات الاعتماد" (Credential Manager) لإزالة أي رموز مخزنة مؤقتا مرتبطة بحسابك. أما في تطبيقات الويب، فإن حذف ملفات تعريف الارتباط وبيانات المواقع من المتصفح يمكن أن يبدأ عملية مصادقة جديدة ونظيفة. وفي الحالات العنيدة، وخاصة في Microsoft Teams، جرّب إعادة تعيين محلية عبر تسجيل الخروج من جميع الأماكن، وإغلاق التطبيق، وحذف مجلدات الذاكرة المؤقتة، ثم إعادة التشغيل. وقد يحتاج بعض المستخدمين إلى حذف ملف تعريف حساب Teams قسرا من إعدادات الجهاز، لضمان إزالة كل الآثار، ثم إعادة تثبيت Teams من البداية.

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

بالنسبة لمن يتعاملون مع حوكمة Microsoft Teams أو مشكلات المصادقة المتكررة، من المفيد إدراك أن الإصلاحات التقنية وحدها لا "تحل" مشكلة الحوكمة. للاطلاع على تحليل أعمق لسبب كون الحوكمة لا تنتهي أبدا، وكيفية تطبيقها عمليا، راجع هذا الدليل حول حوكمة Teams ووهم السيطرة، أو اطلع على دليل أتمتة دورة حياة Teams هذا للحصول على استراتيجيات عملية.

أفضل الممارسات لمنع AADSTS900144 في تطبيقات المؤسسات

يعتمد منع الخطأ AADSTS900144 في الأساس على الانضباط في طلبات OAuth وفي إعدادات التطبيقات. اجعلوا من عادتكم التحقق من جميع المعلمات المطلوبة، وخاصة client_id وgrant_type، قبل إرسال الطلبات إلى نقطة نهاية الرموز في Azure AD. يمكن للفحوصات الآلية في خط أنابيب النشر أن تكتشف المعلمات المفقودة أو المشوهة قبل وصولها إلى بيئة الإنتاج، وأن توفر عليكم كثيرا من البلاغات لاحقا.

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

بالنسبة للمؤسسات ذات متطلبات الحوكمة المكثفة أو التي تضم فرق تطوير متعددة، اربطوا عملية التحقق بممارسات البنية التحتية ككود. استخدموا فحوصات المخطط في قوالب النشر ARM أو Bicep لفرض تضمين جميع معلمات OAuth المطلوبة عند تسجيل التطبيق. وهذا يقلل خطر الانحراف في الإعدادات وسوء التهيئة، خاصة مع تطور التطبيقات.

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