פתרון השגיאה AADSTS700054 (Response Type Not Enabled) באפליקציות Azure AD

By Mirko Peters · 2026-04-21

נתקלתם פעם בשגיאה AADSTS700054 ושאלתם את עצמכם, "מה שוב השתבש?" אינכם לבד. השגיאה הזו ידועה במיוחד כי היא מופיעה בדיוק כשמנסים לאמת אפליקציה באמצעות Azure Active Directory, במיוחד עם Microsoft 365, Dynamics 365 או אפליקציות Single Page משלכם. בבסיסה, היא אומרת שהאפליקציה שלכם לא הוגדרה לקבל את ה"סוג התגובה" הספציפי שהתבקש, כמו ID token או access token מנקודת הקצה של ההרשאה.

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

Cover: Power Platform Tenant Governance and Security Risks

המדריך הזה מפרק את הסיבות לשגיאה ומראה איך לתקן אותה, הן באפליקציות ישנות המבוססות על implicit grant והן בהגדרות מודרניות עם MSAL.js ו-PKCE. תמצאו גם שיטות עבודה מומלצות לאבטחת ההגדרות, וכן הפניות למשאבי הקהילה ורמזים לניווט בבלוג שיעזרו למצוא תשובות מהר. בין אם אתם מאתרים תקלות באפליקציות ישנות ובין אם במודרניות, בסוף המדריך תדעו בדיוק איך לפתור את כאב הראש האימותי הנפוץ הזה ולהימנע ממנו.

הבנת הסיבות לבעיה AADSTS700054

שגיאה AADSTS700054 אינה רק קוד מסתורי נוסף מבית Microsoft. למעשה, זו הדרך של Azure לומר לכם, "האפליקציה שלכם ביקשה ממני דבר שאין לה רשות לקבל." בדרך כלל הבעיה נוגעת לסוגי תגובה. כשהאפליקציה מנסה לבקש טוקן מ-Azure AD אבל לא הוגדרה ל"זרימה" המתאימה (כמו implicit grant), Azure חוסם את הבקשה ומציג את השגיאה הזו.

למה זה קורה? ברוב המקרים השגיאה מופיעה כי ברישום האפליקציה חסרות ההגדרות הנכונות עבור ID tokens, access tokens או שניהם, בנקודת הקצה של ההרשאה. לדוגמה, דמיינו אפליקציית Single Page Application (SPA) שמנסה לקבל טוקנים באמצעות implicit flow בלי שהאפשרות הופעלה ב-Azure AD. Azure מזהה את אי ההתאמה בין מה שמבוקש לבין מה שמותר, ו-AADSTS700054 מופיעה.

תצורות שגויות נפוצות במיוחד במעבר מגישות אימות ישנות לשיטות עבודה מודרניות. ארגונים שתומכים גם באפליקציות ישנות (שעדיין עשויות להשתמש ב-implicit grant) וגם באפליקציות חדשות (שאמורות להשתמש ב-PKCE ובזרימת קוד ההרשאה) נמצאים בסיכון מיוחד. גם כשמעדכנים אימות בענן או משלבים שירותים חדשים של Microsoft, הסיכוי להיתקל בבעיה הזו גדל.

הבנת השגיאה הזו מאפשרת לקשר בין מה שהקוד שלכם מבקש לבין מה שאפליקציית Azure שלכם מוגדרת לטפל בו. לכן לאורך שאר המדריך תראו איך ליישר את בקשות הטוקן של האפליקציה עם מה ש-Microsoft Identity Platform מצפה לו, וכך תהיו צעד אחד לפני הבעיה בתהליך פתרון התקלות.

הפתרון המומלץ לבעיות סוג תגובה מסוג Implicit Grant

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

כך מטפלים בזה בפורטל Azure: ראשית, היכנסו אל "App registrations", מצאו את האפליקציה הרלוונטית ופתחו את הסעיף "Authentication". חפשו את האזור "Implicit grant and hybrid flows". שם תראו תיבות סימון עבור "Access tokens" ו-"ID tokens". סמנו את אלה המתאימים לתרחיש שלכם. בדרך כלל, אפליקציות SPA צריכות לפחות את התיבה "ID tokens", ואפליקציות ישנות עשויות להזדקק לשתיהן.

אבל אל תסמנו הכול ותקוו לטוב! הפעילו רק את האפשרויות שהאפליקציה באמת צריכה, תוך שמירה על אבטחה בראש סדר העדיפויות. אם האפליקציה מבקשת טוקנים דרך נקודת הקצה של ההרשאה, כמו רוב האפליקציות שפועלות בדפדפן, ההגדרות האלה נדרשות. באפליקציות אחרות, במיוחד כאלה שעוברות לזרימות מאובטחות יותר (כמו PKCE), ייתכן שלא תצטרכו לגעת ב-implicit grant כלל.

לאחר שתבצעו את השינויים, רוב תקלות AADSTS700054 ייפתרו מיד. אם הבעיה נמשכת, בדקו שוב את היקף ההרשאות של האפליקציה, את כתובות ה-redirect URI, וגם אם השינויים התפשטו במלואם בחשבון שלכם. זהו הבסיס להתמודדות עם השגיאה הזו, ולהחזרת המשתמשים (והמפתחים) לעבודה.

שיטות עבודה מומלצות לאבטחה כדי להימנע מתצורות שגויות של סוג תגובה

עריכת הגדרות ה-implicit grant עשויה לפתור שגיאה, אבל זו לא תמיד התוכנית הבטוחה ביותר לטווח הארוך. הפעלת implicit flow מגדילה את סיכון האבטחה, מכיוון שהטוקנים מוחזרים ישירות בתגובות הדפדפן, ולכן ייתכן שיהיה קל יותר ליירט אותם. לכן Microsoft, וכל מנהל מודע לאבטחה, ממליצים להשתמש באלטרנטיבות מודרניות כמו Authorization Code Flow with PKCE ברוב התרחישים, במיוחד עבור SPA חדשים או מעודכנים.

אז מתי כדאי להפעיל implicit grant? בקצרה: רק אם יש לכם אפליקציות מדור קודם או מקרים מיוחדים שדורשים זאת. לכל השאר, הגדירו את האפליקציות שלכם להשתמש ב-authorization code flow (עם PKCE). כך הטוקנים נשארים מחוץ לשורת הכתובת של הדפדפן, ומצמצמים משמעותית את משטח התקיפה.

ארגונים שמשלבים Power Platform, Microsoft 365 ו-Dynamics 365 לא יכולים להתפשר על שיטות העבודה המומלצות האלה. הגדרות response type שגויות לא רק שוברות התחברויות, אלא עלולות לפתוח דלתות לתוקפים או ליצור בעיות תאימות בהמשך. הסקירה הזו על אבטחה וממשל ב-Power Platform מסבירה מדוע בקרות מחמירות והכרת הflows שבחרתם חשובות כל כך, במיוחד כאשר מפתחים אזרחים מוסיפים אפליקציות מותאמות אישית ואינטגרציות.

בשורה התחתונה: הפעילו רק את מה שנחוץ, העדיפו code flow עם PKCE כשאפשר, ונעלו את רישומי האפליקציות שלכם כחלק מאסטרטגיית ממשל רחבה יותר. ודאו שכל ההגדרות תואמות למדיניות האבטחה שאתם רוצים לאכוף. העתיד שלכם (וה-auditors שלכם) יודו לכם על כך.

פתרון תקלות AADSTS700054 באפליקציות מודרניות שמשתמשות ב-MSAL.js

אפשר היה לחשוב שמעבר לספריות אימות מודרניות כמו MSAL.js v2 ומעבר ל-PKCE ישחרר אתכם משגיאות "מהעולם הישן" כמו AADSTS700054, נכון? לא כל כך מהר. גם אפליקציות Single Page Applications מודרניות עלולות להיתקע אם רישום האפליקציה או הגדרות צד הלקוח שלהן אינם מיושרים עם שיטות העבודה המומלצות הנוכחיות.

האשם העיקרי? הנחות ישנות. מפתחים עלולים לעבור ל-MSAL.js אך להישאר עם redirect URIs מדור קודם, או לבקש בטעות response types (כמו id_token) שאינם מופעלים ב-Azure AD. זה במיוחד נכון כאשר ה-app manifest הועתק מפרויקט אחר. התוצאה: Azure AD מחזיר את השגיאה המטרידה הזו כשהאפליקציה מתחילה את תהליך האימות.

איך לנפות את התקלה? פתחו את כלי הפיתוח של הדפדפן, עברו ללשונית Network והתבוננו בבקשת ההרשאה. ודאו שה-response_type תואם לזרימות שאפליקציית Azure שלכם מוגדרת באמת לקבל. אם אתם רואים בקשות לטוקנים שאינם מופעלים כראוי, חזרו לפורטל Azure והתאימו את רישום האפליקציה בהתאם.

שימו לב: עם MSAL.js v2 ו-PKCE, בדרך כלל אין צורך להפעיל בכלל את implicit flow. אבל אם האפליקציה שלכם עדיין נכשלת, חפשו הגדרות "implicit" שנכתבו בקוד, שגיאות כתיב ב-redirect URIs, או grant types שגויים. בדיקה זהירה של ההגדרות (גם בצד Azure וגם בצד הלקוח) פותרת את רוב הבעיות. זה אולי לא מרשים, אבל פתרון תקלות יעיל חוסך שעות של ניחושים.

מעבר של אפליקציות מדור קודם מ-Implicit Grant ל-PKCE

מוכנים להניח את implicit flow סופית מאחוריכם? החלטה נכונה. המעבר ל-PKCE (Proof Key for Code Exchange) הוא כיום התקן המוביל, ו-Microsoft ממליצה עליו בחום. אבל, בואו נהיה ריאליים: מעבר של אפליקציה פעילה עם משתמשים אינו מעולם רק החלפת הגדרה. צריך תוכנית שמונעת השבתות, ממזערת הפרעות בהתחברות ומשאירה את כולם מעודכנים.

הצעד הראשון הוא להעריך ולרשום את כל רישומי האפליקציות שלכם שמשתמשים ב-implicit grant. לאחר מכן, בדקו את זרימת ה-PKCE החדשה בסביבת staging. המשמעות היא הגדרת האפליקציה לשימוש ב-authorization code flow, עדכון redirect URIs והתאמת קבצי הגדרות הלקוח (כמו החלפת MSAL.js או ADAL.js). עברו על מחזורי ההתחברות וההתנתקות המלאים ועל חידושי הטוקנים. ודאו שהכול עובד לכל סוגי המשתמשים.

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

לבסוף, שימו לב לבעיות כמו כשלים בחידוש טוקנים או הפסקת סשנים פעילים לאחר המעבר. תכננו שדרוגים לשעות עם תעבורה נמוכה, אם אפשר. מעוניינים להרחיב על הטמעת המעברים האלה בפועל? חלק מהמשאבים מפנים לכתובות אחרות, אבל תמיד אפשר להאזין לפודקאסטים האחרונים על Microsoft 365 Copilot וארכיטקטורה כדי למצוא רמזים עקיפים לניהול שינויים בארגון (לדיונים האחרונים לחצו כאן).

גילוי בלוגים מהימנים כמו הבלוג של Nishant Rana לפתרונות אמינים

הבלוג של Nishant Rana: מקור מומלץ לפתרון בעיות באינטגרציה של Azure AD. Nishant מכסה תרחישים מעמיקים, תיקונים צעד אחר צעד ואף מקרים נישתיים עבור Dynamics 365 ו-Power Platform. ההסברים הברורים שלו הופכים שגיאות אימות מסובכות להרבה פחות מאיימות.
בלוג ה-MVP של KingswaySoft: הבלוג, שמוביל MVP, ידוע בעצות מעשיות לשילוב נתוני CRM ומתייחס באופן קבוע למקרי קצה באימות. זה חיוני לכל מי שעובד עם מערכת Azure AD ומערכת Microsoft 365.
100 בלוגי ה-CRM המובילים: רשימות מאוצרות כמו זו מאירות את הקהילה הטכנית הרחבה ומאפשרות לגלות כותבים שמפרסמים באופן קבוע בנושאי זהות, אבטחה ופתרון תקלות ב-Microsoft. הרחבת רשימת הקריאה שלכם מגדילה את הסיכוי למצוא פתרון המותאם למקרה הקצה שלכם.

שימוש בחיפוש מהיר ובארכיונים לאיתור פוסטים אחרונים על בעיות ב-Azure AD

שימוש בחיפוש מהיר: לרוב הבלוגים הטכניים המוכרים יש שורת חיפוש, השתמשו בה! הקלידו "AADSTS700054", "Azure AD error" או "implicit grant" כדי לאתר מיד פוסטים ומדריכים הרלוונטיים לבעיה שלכם. זה הרבה יותר מהיר מגלישה ידנית.
עיון בארכיונים ובעדכונים האחרונים: אם לא מצאתם את הבעיה דרך החיפוש, נווטו לארכיון של האתר או לרשימות "הפוסטים האחרונים" המסוננות. מדריכים לפתרון תקלות שנבדקו לאורך זמן מסתתרים לא פעם בתכנים ישנים, ולעיתים פוסט חדש מכיל בדיוק את התיקון שאתם צריכים לשינויי האימות החדשים בפלטפורמה של Microsoft.
שילוב מסננים למשתמשים מתקדמים: רוצים לנסות משהו מתקדם? השתמשו במערכות תגיות או קטגוריות בשילוב עם החיפוש. סינון של כל הפוסטים על "Azure AD" או צמצום לפי "app registration" יקצרו את זמן פתרון התקלות וייחשפו בעיות ופתרונות שאולי הייתם מפספסים אחרת.