فهم خطأ AADSTS70000 “Invalid Grant” في Microsoft Azure وMicrosoft 365

By Mirko Peters · 2026-04-21

يُعد الخطأ AADSTS70000 “invalid grant” مصدر صداع متكرر للمسؤولين والمطورين الذين يعملون مع Azure Active Directory وخدمات Microsoft 365. وغالبًا ما تظهر هذه الرسالة عند ربط الأنظمة أو الأتمتة عبر Power Platform أو إضافات Outlook أو التطبيقات التي تعتمد على تدفقات هوية Microsoft.

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

Cover: Fix Conditional Access Loopholes in Microsoft 365

باختصار، يعني الخطأ AADSTS70000 أن شيئًا ما فشل أثناء المصادقة، وعادةً عندما يحاول تطبيق أو مستخدم الحصول على رمز مميز باستخدام OAuth، لكن “المنحة” لم تعد صالحة. وقد يؤدي ذلك إلى إيقاف سير عمل Power Automate، أو تعطيل تكامل Outlook، أو تعطيل تسجيل الدخول إلى أي تطبيق يعتمد على Azure أو Entra ID للمصادقة. وإذا كنت تعمل في مجال تقنية المعلومات السحابية أو تطوير التطبيقات، فيجب أخذ هذا الخطأ بجدية، لأنه يشير إلى مشكلات في المصادقة والأمان قد توقف أنظمتك تمامًا.

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

تحليل مكونات رسالة الخطأ 70000 Invalid Grant

عندما تواجه الخطأ AADSTS70000 invalid grant، فأنت في الحقيقة تنظر إلى جزأين أساسيين في رسالة الخطأ. الأول هو رمز الخطأ نفسه “AADSTS70000”، وهذا الرمز يشير تحديدًا إلى مشكلات في منح OAuth ضمن إطار المصادقة لدى Microsoft.

أما الجزء الثاني فهو السبب، وعادةً ما يُعرض بالعبارة “invalid_grant” أو برسالة مثل “grant is invalid or malformed”. وهذا يعني أن الخادم لم يتمكن من قبول طلب الرمز المميز، وغالبًا بسبب أخطاء في الإعداد أو سياسات أمان أو مشكلات في بنية المنحة.

إذا ظهر هذا الخطأ في سجلات تسجيل الدخول في Azure، فقد تتضمن الرسالة تفاصيل إضافية مثل “refresh token expired” أو “redirect URI mismatch”. إن تعلّم التعرف على هذه الأنماط يساعدك على التمييز بسرعة بين أخطاء المستخدمين ومشكلات تسجيل التطبيقات والاختلالات الأعمق في إعدادات الخدمة، ما يقلل وقت التشخيص ويوجهك مباشرة إلى أكثر وثائق Microsoft فائدة أو إلى قنوات الدعم المناسبة.

ما الذي يسبب الخطأ 70000 Invalid Grant؟

إليك الأسباب الأكثر شيوعًا التي قد تؤدي إلى ظهور الخطأ AADSTS70000 invalid grant. وكل سبب منها يرتبط بكيفية تعامل OAuth وAzure AD مع الرموز المميزة والأمان وإعدادات تسجيل التطبيقات:

منح OAuth تالفة أو منتهية الصلاحية: تُعد الرموز المميزة للوصول والتحديث غير الصالحة أو المنتهية الصلاحية من أبرز الأسباب. فإذا استُخدم رمز مميز بعد انتهاء صلاحيته، أو جرى التلاعب به أثناء النقل، يرفضه Azure AD فورًا.
عناوين Redirect URI غير الصحيحة أو إعدادات عميل غير متطابقة: حتى الفروق الطفيفة في عنوان redirect URI المسجل (مثل شرطة مائلة ناقصة) قد تكسر التدفق. وتُعد تغييرات بيانات التطبيق دون تحديث إعدادات Azure AD من الأسباب الشائعة.
مشكلات الرمز المميز للتحديث: محاولة إعادة استخدام رمز تحديث ملغى، أو استخدام رمز منتهٍ أو صادر لعميل آخر، تؤدي إلى ظهور هذا الخطأ. وفي بعض الأحيان، يقوم المسؤولون بتدوير الأسرار أو إعادة تعيين كلمات المرور، فيُبطلون هذه الرموز عن غير قصد.
تدخل نهج الوصول المشروط وMFA: إذا طُبّقت قاعدة MFA أو قاعدة الامتثال للجهاز في منتصف التدفق، خاصةً في الحسابات الخدمية أو الحسابات التي تعمل في الخلفية، فإن المنحة تُرفض دون تفسير يُذكر. وهذه من المشكلات الدقيقة التي تربك حتى المحترفين ذوي الخبرة. هل تحتاج إلى التعمق في نهج الوصول المشروط وقضايا الثقة؟ اطّلع على هذا النقاش حول ثغرات النهج وأفضل الممارسات.
عدم تطابق الموافقة أو النطاقات: عندما تُلغى الأذونات، أو تُمنح جزئيًا، أو تُهمل نطاقات التطبيقات، قد تتوقف فجأة تكاملات كانت تعمل سابقًا. ويجب على المسؤولين والمطورين الذين يدمجون تطبيقات خارجية التحقق مرتين من أن الأذونات المطلوبة وموافقة المسؤول ما زالت سارية. وللاطلاع على تحليل معمّق لمخاطر موافقة OAuth في Entra ID، راجع هذه الصفحة.

حلول معالجة الخطأ 70000 Invalid Grant

مسح الرموز المخزّنة مؤقتًا وإعادة المصادقة: أسرع حل لمشكلات الرموز المميّزة أو الجلسات هو قطع الاتصال بالحساب أو الخدمة المتأثرة ثم إعادة الاتصال بها. في Power Automate وOutlook والتطبيقات المشابهة، يمكن أن يؤدي تسجيل الخروج يدويًا ثم الدخول مجددًا إلى فرض تدفق OAuth جديد وحل أخطاء invalid grant.
التحقق من عناوين Redirect URI وتصحيحها: توجّه إلى Azure Portal وتأكد من أن عنوان redirect URI في تسجيل تطبيقك يطابق تمامًا ما يرسله التطبيق أو الموصل. حتى حرف إضافي واحد قد يُفسد المصادقة بالكامل عندما يتحقق Azure من الطلب.
التحقق من تسجيل التطبيق والأسرار السرية للعميل: تأكد من أن أي تعديلات حديثة على تسجيل التطبيق، أو تدوير الأسرار، أو تغييرات الأذونات محدّثة. الأسرار السرية للعميل المنتهية الصلاحية أو غير المتطابقة تمثل تهديدًا صامتًا للتكاملات المستمرة.
مراجعة نهج الوصول المشروط والموافقة: دقّق نهج الوصول المشروط بحثًا عن استثناءات واسعة أو فجوات في امتثال الأجهزة، فهذه قد تعطّل التدفقات دون أي رسالة خطأ واضحة. شدّد تدفقات موافقة المستخدمين وتحقّق من أن موافقة المسؤول لا تزال مفروضة حيثما يلزم. للاطلاع على استراتيجيات الحوكمة، راجع دليل أفضل الممارسات الأمنية المعمّق هذا.
تحديث نطاقات الأذونات: راجع مرة أخرى نطاقات الأذونات التي يطلبها تطبيقك أو أتمتتك. فقد تتغيّر أسماء النطاقات أو يتم إيقافها، خاصةً في Microsoft Graph. تأكد من تطابق كل شيء بين كود التطبيق وتسجيله في البوابة وسجل الموافقات.
فرض مسح الرموز بعد التغييرات الأمنية: إذا ربما تعرّضت الرموز المميّزة للاختراق، أو إذا حدّثت للتوّ نهج كلمات المرور، فاستخدم Intune أو Azure Portal لإبطال جميع الجلسات النشطة وطلب تسجيل دخول جديد لجميع المستخدمين والأتمتات. لمزيد من المعلومات حول مواجهة هجمات الوصول المستمرة القائمة على الموافقة، راجع هذا الدليل حول مخاطر هجمات الموافقة في Entra ID وسبل التخفيف منها.

مشكلة Power Automate: استكشاف أخطاء فشل مصادقة invalid grant وإصلاحها

إعادة الاتصال بمصادر البيانات المتأثرة أو تحديثها: إذا كان تدفقك يُظهر الخطأ 70000، فابدأ بفتح التدفق في Power Automate، وحدّد أي اتصالات تعرض تحذيرات، ثم أعد الاتصال بها ببساطة. يؤدي ذلك إلى حصول الخدمة على رمز مميّز جديد باستخدام أحدث بيانات الاعتماد.
التحقق من أذونات المستخدم وصلاحية بيانات الاعتماد: تأكد من أن المستخدم المعيّن للتدفق يملك الصلاحيات المناسبة للوصول إلى مصدر البيانات. إذا كان الحساب المستخدم في التدفق معطّلًا، أو انتهت صلاحية كلمة المرور، أو تغيّرت متطلبات MFA، فستلاحظ فشلًا متكررًا في المصادقة.
التحقق من نطاقات الأذونات المطلوبة: تأكد مرة أخرى من أن النطاقات الممنوحة تطابق ما يحتاجه التدفق لقراءة الرسائل الإلكترونية أو إرسالها، أو إنشاء الملفات، أو إضافة عناصر إلى SharePoint. هذا مهم بشكل خاص مع موصلات Outlook وTeams.
مراجعة نهج DLP وقيود الموصلات: يمكن لنهج Data Loss Prevention (DLP) أن تعطّل التدفقات بصمت إذا انتقل موصل من غير محظور إلى محظور، أو أعاد المسؤولون تصنيفه. للمزيد حول بناء أتمتات مستقرة ضمن حدود DLP الصحيحة، اطلع على دليل نهج DLP هذا لمطوّري Power Platform.
التمييز بين الإخفاقات العابرة والمستمرة: أحيانًا يكون الخطأ 70000 ناتجًا عن انقطاعات قصيرة أو اضطرابات مؤقتة في الخدمة. فالفشل الواحد الذي يعقبه تعافٍ عادةً لا يدعو للقلق، لكن إذا استمر الخطأ، فابدأ بتتبع أذونات الاتصال ونطاقات الموافقة عبر المستأجر بأكمله.
مراجعة إعدادات الحوكمة: يمكن للثغرات في حوكمة البيئات أو الهوية أن تسمح لمخاطر المصادقة بالتسلل مع مرور الوقت. للحصول على نصائح حول حوكمة Power Platform، راجع نظرة عامة على أفضل الممارسات هذه.

تسجيل الدخول إلى Azure 70000: استخدام سجلات Azure AD والتدقيق للتشخيص

ابدأ بسجلات تسجيل الدخول في Azure AD: انتقل إلى سجلات تسجيل الدخول في Azure Portal، وقم بتصفية حالات الفشل التي تحمل الرمز "AADSTS70000". تحقّق من سبب الفشل والتطبيق العميل وعنوان IP المصدر. يساعد ذلك في عزل ما إذا كانت المشكلة متعلقة بالمستخدم أو بالتطبيق أو بالإعدادات.
تحليل أنماط سلوك الرموز المميزة والعملاء: ابحث عن الأخطاء المتكررة المرتبطة بالمستخدم نفسه أو بمبدأ الخدمة (service principal) أو بالتطبيق نفسه. غالباً ما تشير أخطاء “invalid grant” المتكررة بعد حدث مجدول، مثل تدوير الأسرار (secret rotation)، إلى نهج رموز مميزة غير متوافق أو إلى رموز تحديث (refresh tokens) منتهية الصلاحية.
استخدم سجلات تدقيق Azure AD للحصول على سياق أوسع: اجمع بين إخفاقات تسجيل الدخول وسجلات تدقيق Azure AD. فهذا يكشف تغييرات تسجيل التطبيقات، وتحديثات نهج الوصول المشروط، وعمليات الإبطال الجماعي المحتملة للرموز المميزة. إن تحديد تغيير وقع مباشرةً قبل بدء الأخطاء يمكن أن يقودك إلى السبب الجذري مباشرةً.
استفِد من أدوات التدقيق المتقدمة: للتحقيقات الأوسع عبر Microsoft 365، توفر أدوات مثل Microsoft Purview Audit فترة احتفاظ ممتدة وإشارات تحليلية معمّقة لأغراض التحليل الجنائي. تعرّف على كيفية إعداد هذه الأدوات واستخدامها في نظرة عامة على Purview Audit هذه.
عزّز الحوكمة لتحقيق الاستقرار على المدى الطويل: تساعد الحوكمة الجيدة على منع الأعطال الصامتة وتراكم انحراف النهج بمرور الوقت. فرض الضوابط الوقائية باستخدام Azure Policy وراقب الاستثناءات. للاطلاع على استراتيجية شاملة، راجع دليل حوكمة Azure للمؤسسات.

مزامنة الوقت وانحراف الساعة: السبب الخفي لأخطاء invalid grant في OAuth

من أكثر أسباب أخطاء AADSTS70000 من نوع invalid grant إغفالاً هو ببساطة عدم تطابق ساعة النظام، ويُعرف ذلك بانحراف الساعة (clock skew). فعندما لا تتفق ساعة جهاز العميل مع ساعة خوادم Microsoft، قد تبدو رموز OAuth ورموز التفويض منتهية الصلاحية أو غير سارية بعد، حتى لو كان كل شيء آخر صحيحاً.

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

الحل؟ زامن جميع الأجهزة بانتظام مع خادم NTP موثوق. فعّل التصحيح التلقائي للوقت على وحدات التحكم بالمجال، والأجهزة الافتراضية، وأجهزة المستخدمين النهائيين. فالبقاء ضمن دقيقة أو دقيقتين من “الوقت الحقيقي” أفضل بكثير من إخفاقات المنح الغامضة في أي يوم. وللاطلاع على نظرة أوسع حول مقاربات Microsoft 365 وDynamics الاستباقية للأمان (بما في ذلك الضوابط التكيفية)، اطّلع على بودكاست Zero Trust by Design هذا.