הבנת שגיאת AADSTS70000 ‏"Invalid Grant" ב-Microsoft Azure וב-M365

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

שגיאת AADSTS70000 ‏“invalid grant” היא כאב ראש נפוץ למנהלים ולמפתחים שעובדים עם Azure Active Directory ושירותי Microsoft 365. לעתים קרובות תיתקלו בשגיאה הזו בעת חיבור מערכות או אוטומציות דרך Power Platform, תוספות Outlook, או אפליקציות שנשענות על תהליכי הזדהות של Microsoft.

בפשטות, שגיאת AADSTS70000 מעידה שמשהו השתבש במהלך אימות, בדרך כלל כאשר אפליקציה או משתמש מנסים לקבל טוקן באמצעות OAuth, אבל ה־“grant” כבר אינו תקף. השגיאה הזו עלולה להפיל זרימת עבודה ב-Power Automate, לשבש אינטגרציה של Outlook, או לפגוע בכניסה לכל אפליקציה שמשתמשת ב-Azure או ב-Entra ID לאימות. אם אתם עובדים בתחום ה-IT בענן או בפיתוח אפליקציות, כדאי לקחת את השגיאה הזו ברצינות, כי היא מסמנת בעיות אימות ואבטחה שעלולות לעצור את המערכות שלכם לחלוטין.

הבנה של האופן שבו השגיאה הזו עשויה להופיע ושל המקומות שבהם היא מופיעה חיונית לפתרון תקלות מהיר, ומונעת את הרגעים המתסכלים האלה שבהם משהו פשוט מפסיק לעבוד בין לילה, בלי אזהרה מוקדמת.

ניתוח חלקי הודעת השגיאה Invalid Grant 70000

כשנתקלים בשגיאת AADSTS70000 ‏“invalid grant”, למעשה מדובר בשני חלקים מרכזיים בהודעת השגיאה. הראשון הוא קוד השגיאה עצמו, ‏“AADSTS70000”. הקוד הזה מצביע באופן ספציפי על בעיות ב-OAuth grants במסגרת האימות של Microsoft.

החלק השני הוא הסיבה, שבדרך כלל מסומנת כ-“invalid_grant” או מלווה בהודעה כמו “grant is invalid or malformed”. היא מעידה שהשרת לא הצליח לקבל את בקשת הטוקן, בדרך כלל בגלל תצורה שגויה, מדיניות אבטחה או בעיות במבנה ה-grant.

אם השגיאה מופיעה ביומני הכניסה של Azure, לעתים היא תכלול פרטים נוספים כמו “refresh token expired” או “redirect URI mismatch”. הכרה של הדפוסים האלה עוזרת להבדיל מהר בין טעויות משתמש, בעיות ברישום אפליקציות ותקלות תצורה עמוקות יותר בשירות. כך מקצרים את זמן האבחון ומגיעים מיד למשאבי התמיכה והתיעוד הטובים ביותר של Microsoft.

מה גורם לשגיאת Invalid Grant 70000?

אלה הסיבות הנפוצות ביותר לכך שתראו את שגיאת AADSTS70000 ‏“invalid grant”. כל אחת מהן קשורה לאופן שבו OAuth ו-Azure AD מטפלים בטוקנים, באבטחה ובהגדרות רישום האפליקציה:

• OAuth grants פגומים או שפג תוקפם: טוקני גישה ורענון לא תקפים או שפג תוקפם הם גורם מרכזי. אם טוקן נעשה בו שימוש לאחר תאריך התפוגה שלו, או אם הוא עבר שינוי במהלך ההעברה, Azure AD דוחה אותו מיד.
• URI הפניה שגויים או הגדרות לקוח לא תואמות: הבדלים זעירים ב-URI ההפניה הרשום (אפילו סלאש חסר) יכולים לשבור את התהליך. שינוי פרטי אפליקציה בלי לעדכן את הגדרות Azure AD הוא אשם נפוץ.
• בעיות בטוקן רענון: ניסיון להשתמש בטוקן רענון שבוטל, או בטוקן שפג תוקפו או שהונפק ללקוח אחר, מפעיל את השגיאה הזו. לפעמים מנהלים מחליפים סודות או מאפסים סיסמאות, ובכך מבטלים בטעות את הטוקנים האלה.
• הפרעה ממדיניות גישה מותנית ו-MFA: אם כלל של MFA או של תאימות מכשיר נכנס לפעולה באמצע התהליך, במיוחד בחשבונות רקע או חשבונות שירות, ה-grant נדחה בלי הסבר רב. זו בעיה עדינה שלעתים מבלבלת גם אנשי מקצוע מנוסים. רוצים להעמיק במדיניות גישה מותנית ובבעיות אמון? עיינו בדיון על פערי מדיניות ושיטות עבודה מומלצות.
• אי התאמות בהסכמה או בהיקפים: כאשר הרשאות בוטלו, אושרו חלקית, או שהיקפי האפליקציה הוצאו משימוש, אינטגרציות שעבדו קודם לכן עלולות להיכשל לפתע. מנהלים ומפתחים שמטמיעים אפליקציות של צד שלישי חייבים לוודא פעמיים שההרשאות הנדרשות והסכמת המנהל עדיין קיימות. להעמקה בסיכון של הסכמת OAuth ב-Entra ID, עיינו בדף זה.

מסלולי פתרון לשגיאת Invalid Grant 70000

1. ניקוי טוקנים שמורים והתחברות מחדש: הדרך המהירה ביותר לפתור בעיות של טוקנים או סשנים היא לנתק ולחבר מחדש את החשבון או השירות הרלוונטי. ב-Power Automate, ב-Outlook ובאפליקציות דומות, התנתקות והתחברות ידנית יכולות לאלץ תהליך OAuth חדש ולפתור שגיאות invalid grant.
2. בדיקה ותיקון של Redirect URI: היכנסו ל-Azure Portal וודאו שה-redirect URI שמוגדר ברישום האפליקציה שלכם תואם בדיוק למה שהאפליקציה או המחבר שולחים. אפילו תו נוסף יכול לשבש את האימות כולו כש-Azure בודק את הבקשה.
3. אימות רישום האפליקציה וסודות הלקוח: ודאו שכל שינוי אחרון ברישום האפליקציה, החלפת סודות או שינוי בהרשאות מעודכן. סודות לקוח שפגו תוקף או אינם תואמים הם גורם שקט שהורס אינטגרציות פעילות.
4. בדיקת מדיניות Conditional Access והסכמות: בצעו ביקורת על מדיניות Conditional Access, וחפשו החרגות רחבות מדי או פערים בתאימות המכשירים. אלה יכולים לשבור זרימות בלי שום הודעת שגיאה ברורה. הדקו את תהליכי ההסכמה של המשתמשים וודאו שהסכמת מנהל נאכפת במקומות שבהם היא נדרשת. לאסטרטגיות ממשל, ראו מדריך מעמיק על שיטות עבודה מומלצות לאבטחה.
5. עדכון היקפי ההרשאות: בדקו שוב את היקפי ההרשאות (scopes) שהאפליקציה או האוטומציה מבקשות. לעתים היקפים משנים שם או מוצאים משימוש, במיוחד ב-Microsoft Graph. ודאו שהכול מתיישב בין קוד האפליקציה, הרישום בפורטל והיסטוריית ההסכמות.
6. ניקוי טוקנים בעקבות שינויי אבטחה: אם טוקנים נחשפו אולי או שעדכנתם מדיניות סיסמאות, השתמשו ב-Intune או ב-Azure Portal כדי לבטל את כל הסשנים הפעילים ולדרוש התחברות מחדש מכל המשתמשים והאוטומציות. לקריאה נוספת על התמודדות עם תקיפות גישה מתמשכות המבוססות על הסכמה, עיינו במדריך על הסיכונים בתקיפות הסכמה ב-Entra ID והדרכים למניעתם.

בעיית Power Automate: פתרון תקלות של כשלי אימות מסוג Invalid Grant

1. חיבור מחדש או עדכון של חיבורי נתונים מושפעים: אם הזרימה שלכם מציגה שגיאה 70000, התחילו בפתיחת הזרימה ב-Power Automate, אתרו חיבורים שמציגים אזהרות וחברו אותם מחדש. כך השירות מקבל טוקן חדש המבוסס על פרטי הגישה העדכניים.
2. בדיקת הרשאות משתמש ותקפות פרטי הגישה: ודאו שלמשתמש שמשויך לזרימה יש גישה נכונה למקור הנתונים. אם חשבון שבו נעשה שימוש בזרימה מנוטרל, הסיסמה פגה או שדרישות ה-MFA השתנו, תראו כשלי אימות מתמשכים.
3. אימות היקפי הרשאות נדרשים: בדקו שההיקפים שניתנו תואמים למה שהזרימה צריכה לקריאה או שליחה של הודעות דוא"ל, יצירת קבצים או הוספת פריטים ל-SharePoint. זה חשוב במיוחד במחברי Outlook ו-Teams.
4. בדיקת מדיניות DLP והגבלות מחברים: מדיניות Data Loss Prevention (DLP) יכולה לשבור זרימות בשקט אם מחבר עובר ממצב לא חסום למצב חסום, או אם מנהלים מסווגים אותו מחדש. למידע נוסף על בניית אוטומציות יציבות עם גבולות DLP נכונים, עיינו במדריך מדיניות DLP למפתחי Power Platform.
5. הבחנה בין כשלים חולפים לכשלים מתמשכים: לפעמים שגיאה 70000 נובעת מתקלות שירות קצרות או מהפרעות זמניות. כשל יחיד שמלווה בהתאוששות בדרך כלל אינו סיבה לדאגה, אבל אם השגיאה נמשכת, התחילו לעקוב אחר הרשאות החיבור והיקפי ההסכמה בכל הדייר.
6. בדיקת תצורת הממשל: פערים בממשל של הסביבות או של הזהויות יכולים לאפשר לסיכוני אימות להתגנב לאורך זמן. לטיפים על ממשל Power Platform, עיינו בסקירת שיטות העבודה המומלצות הזו.

כניסה ל-Azure 70000: שימוש ביומני Azure AD וביקורת לצורך אבחון

1. התחילו ביומני הכניסה של Azure AD: היכנסו ליומני הכניסה (Sign-In logs) ב-Azure Portal וסננו כשלים עם הקוד "AADSTS70000". בדקו את סיבת הכשל, את אפליקציית הלקוח ואת כתובת ה-IP המקורית. כך תוכלו לבודד אם הבעיה נובעת מהמשתמש, מהאפליקציה או מתצורה שגויה.
2. ניתוח דפוסי התנהגות של טוקנים ולקוחות: חפשו שגיאות חוזרות שקשורות לאותו משתמש, לאותו service principal או לאותה אפליקציה. שגיאות "invalid grant" עקביות שמופיעות אחרי אירוע מתוזמן (כמו החלפת סוד) מצביעות לרוב על מדיניות טוקנים לא מיושרת או על רענון טוקנים (refresh tokens) שפג תוקפם.
3. שימוש ביומני הביקורת של Azure AD להקשר רחב יותר: שלבו כשלי כניסה עם יומני הביקורת של Azure AD. כך תראו שינויים ברישום אפליקציות, עדכוני מדיניות גישה מותנית וביטולי טוקנים המוניים אפשריים. זיהוי שינוי שקרה ממש לפני תחילת השגיאות יכול להוביל ישירות לשורש הבעיה.
4. שימוש בכלי ביקורת מתקדמים: לחקירות רחבות יותר בכל Microsoft 365, כלים כמו Microsoft Purview Audit מספקים שמירת נתונים ממושכת ואותות מעמיקים לניתוח פורנזי. כיצד להגדיר ולהשתמש בכלים אלה מוסבר בסקירה זו של Purview Audit.
5. חיזוק הממשל לטווח ארוך: ממשל טוב מונע כשלים שקטים וסחיפה מצטברת של מדיניות לאורך זמן. אכפו מעקות בטיחות באמצעות Azure Policy ועקבו אחר החריגות. לאסטרטגיה מקיפה, ראו את מדריך הממשל הארגוני של Azure.

סנכרון זמן ו-Clock Skew: הגורם הנסתר לשגיאות OAuth מסוג Invalid Grant

אחת הסיבות שמתעלמים מהן לעיתים קרובות לשגיאות AADSTS70000 מסוג invalid grant היא פשוט חוסר יישור בשעון המערכת, המוכר בשם clock skew. כאשר מחשב הלקוח והשרתים של Microsoft אינם מסכימים על השעה הנוכחית, טוקני OAuth וקודי ההרשאה עלולים להיראות כפגי תוקף או כעדיין לא תקפים, גם כשכל היתר תקין.

זה במיוחד מאתגר בסביבות וירטואליות או ענן, שבהן מערכות שונות פועלות עם שעונים שאינם מסונכרנים בדיוק. עיכובי רשת או מצבי שינה של מכשירים יכולים להחמיר את הבעיה ולגרום לניסיון אימות תקין להיכשל ללא סיבה נראית לעין.

הפתרון? סנכרנו באופן קבוע את כל המכשירים מול שרת NTP אמין. הגדירו תיקון זמן אוטומטי בבקרי הדומיין, במכונות הווירטואליות ובמכשירי קצה של משתמשים. שמירה על סטייה של דקה או שתיים מ"הזמן האמיתי" עדיפה על כשלי הענקה מסתוריים בכל יום. לתמונה רחבה יותר של גישות יזומות לאבטחת Microsoft 365 ו-Dynamics (כולל בקרות אדפטיביות), כדאי לצפות בפודקאסט Zero Trust by Design זה.