Rozwiązywanie problemu AADSTS700054 (Response Type Not Enabled) w aplikacjach Azure AD

By Mirko Peters · 2026-04-21

Zdarzyło Ci się kiedyś natrafić na błąd AADSTS700054 i pomyśleć: „Co tym razem zepsułem?” Nie jesteś w tym sam. Ten błąd słynie z tego, że pojawia się dokładnie wtedy, gdy próbujesz uwierzytelnić aplikację w Azure Active Directory, zwłaszcza w połączeniu z Microsoft 365, Dynamics 365 lub własnymi aplikacjami typu single page. W istocie oznacza on, że aplikacja nie jest skonfigurowana tak, by akcep

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

Zdarzyło Ci się kiedyś natrafić na błąd AADSTS700054 i pomyśleć: „Co tym razem zepsułem?” Nie jesteś w tym sam. Ten błąd słynie z tego, że pojawia się dokładnie wtedy, gdy próbujesz uwierzytelnić aplikację w Azure Active Directory, zwłaszcza w połączeniu z Microsoft 365, Dynamics 365 lub własnymi aplikacjami typu single page. W istocie oznacza on, że aplikacja nie jest skonfigurowana tak, by akceptować konkretny „typ odpowiedzi” (response type), o który prosi – na przykład token ID lub token dostępu z punktu końcowego autoryzacji.

Ten przewodnik wyjaśnia, dlaczego to się dzieje, i pokazuje, jak naprawić problem zarówno w starszych aplikacjach opartych na implicit grant, jak i w nowoczesnych konfiguracjach z użyciem MSAL.js i PKCE. Znajdziesz tu także najlepsze praktyki dotyczące bezpiecznej konfiguracji, wskazówki dotyczące społeczności oraz podpowiedzi, jak szybko odnaleźć odpowiedzi na blogu. Po lekturze, niezależnie od tego, czy diagnozujesz starą, czy nowoczesną aplikację, будешь wiedzieć dokładnie, jak rozwiązać i uniknąć tej częstej bolączki uwierzytelniania.

Przyczyny problemu AADSTS700054

Błąd AADSTS700054 to nie kolejny tajemniczy kod od Microsoftu. To w zasadzie sposób, w jaki Azure mówi: „Twoja aplikacja prosi mnie o coś, na co nie ma pozwolenia”. Zwykle chodzi o typy odpowiedzi. Gdy aplikacja próbuje pobrać token z Azure AD, ale nie została skonfigurowana dla danego „przepływu” (na przykład implicit grant), Azure blokuje żądanie i zgłasza ten błąd.

Dlaczego tak się dzieje? W większości przypadków rejestracja aplikacji nie ma odpowiednich ustawień dla tokenów ID, tokenów dostępu lub obu naraz w punkcie końcowym autoryzacji. Weźmy na przykład aplikację typu Single Page Application (SPA), która próbuje pobierać tokeny przez implicit flow, mimo że nie zostało to włączone w Azure AD. Azure wykrywa niezgodność między tym, o co jest proszona, a tym, na co faktycznie pozwala – i bum: pojawia się AADSTS700054.

Błędy konfiguracji zdarzają się często przy przechodzeniu od starszych metod uwierzytelniania do nowoczesnych rozwiązań. Organizacje, które obsługują jednocześnie starsze aplikacje (nadal korzystające z implicit grant) i nowsze (które powinny używać PKCE i przepływu kodu autoryzacji), są szczególnie narażone. Aktualizujesz uwierzytelnianie w chmurze lub integrujesz nowe usługi Microsoft? Szansa na trafienie na tę przeszkodę rośnie.

Zrozumienie tego błędu pozwala połączyć to, o co prosi Twój kod, z tym, na co jest skonfigurowana aplikacja w Azure. Dlatego w dalszej części przewodnika pokażemy, jak dopasować żądania tokenów aplikacji do oczekiwań Microsoft Identity Platform – i być o krok do przodu w rozwiązywaniu problemów.

Zalecane rozwiązanie problemów z typem odpowiedzi implicit grant

Jeśli AADSTS700054 blokuje Twoją integrację, najszybszym rozwiązaniem jest zwykle skonfigurowanie rejestracji aplikacji z odpowiednimi typami odpowiedzi. Najczęściej oznacza to włączenie ustawień implicit grant – czyli w praktyce zezwolenie aplikacji na pobieranie tokenów bezpośrednio z punktu końcowego autoryzacji.

Oto jak to zrobić w portalu Azure: najpierw przejdź do „Rejestracje aplikacji”, znajdź aplikację, której dotyczy problem, i otwórz sekcję „Uwierzytelnianie”. Poszukaj obszaru „Implicit grant and hybrid flows”. Znajdziesz tam pola wyboru „Access tokens” i „ID tokens”. Zaznacz odpowiednie dla swojego scenariusza – zwykle aplikacje SPA potrzebują co najmniej pola „ID tokens”, a starsze aplikacje mogą wymagać obu.

Nie zaznaczaj jednak wszystkiego w nadziei, że zadziała! Włączaj tylko te opcje, których aplikacja faktycznie potrzebuje, mając na uwadze bezpieczeństwo. Jeśli aplikacja pobiera tokeny przez punkt końcowy autoryzacji – tak jak większość aplikacji działających w przeglądarce – te ustawienia są wymagane. W przypadku innych aplikacji, zwłaszcza tych przechodzących na bezpieczniejsze przepływy (jak PKCE), być może w ogóle nie trzeba ruszać implicit grant.

Po wprowadzeniu zmian większość problemów z AADSTS700054 zwykle ustępuje natychmiast. Jeśli nadal masz trudności, sprawdź zakres uprawnień aplikacji, adresy URI przekierowania oraz to, czy zmiany zostały w pełni propagowane w Twojej dzierżawie. To fundament rozwiązania tego błędu – i przywrócenia pracy użytkownikom (oraz deweloperom).

Najlepsze praktyki bezpieczeństwa, aby unikać błędnej konfiguracji typów odpowiedzi

Dostosowanie ustawień implicit grant może naprawić błąd, owszem, ale nie zawsze jest to najbezpieczniejszy plan długoterminowy. Włączenie przepływu implicit zwiększa ryzyko dla bezpieczeństwa, ponieważ tokeny są zwracane bezpośrednio w odpowiedziach przeglądarki, przez co mogą być łatwiej przechwycone. Dlatego Microsoft, a szczerze mówiąc każdy administrator dbający o bezpieczeństwo, zaleca w większości scenariuszy nowoczesne alternatywy, takie jak Authorization Code Flow with PKCE, zwłaszcza w przypadku nowych lub aktualizowanych aplikacji SPA.

Kiedy zatem włączyć implicit grant? Krótko mówiąc: tylko wtedy, gdy masz starsze aplikacje lub szczególne przypadki, które tego wymagają. We wszystkich pozostałych sytuacjach skonfiguruj aplikacje tak, aby korzystały z przepływu kodu autoryzacji (z PKCE). Dzięki temu tokeny nie trafiają do paska adresu przeglądarki, a powierzchnia ataku znacząco się zmniejsza.

Organizacje, które łączą Power Platform, Microsoft 365 i Dynamics 365, nie mogą pozwolić sobie na pomijanie tych najlepszych praktyk. Błędnie skonfigurowane typy odpowiedzi nie tylko psują logowanie. Mogą otworzyć drzwi atakującym lub w przyszłości przysporzyć problemów z zgodnością z przepisami. Ten przegląd bezpieczeństwa i zarządzania w Power Platform pokazuje, dlaczego tak ważne są ścisła kontrola i znajomość wybranych przepływów, szczególnie gdy deweloperzy-obywatele dodają własne aplikacje i integracje.

Podsumowując: włączaj tylko to, co jest potrzebne, tam gdzie to możliwe preferuj przepływ kodu z PKCE i zabezpieczaj rejestracje aplikacji w ramach szerszej strategii zarządzania. Upewnij się, że wszystkie ustawienia są zgodne z zasadami bezpieczeństwa, które chcesz egzekwować. Twój przyszły ja (i audytorzy) będą wdzięczni.

Rozwiązywanie problemów z AADSTS700054 w nowoczesnych aplikacjach z użyciem MSAL.js

Można by pomyśleć, że przejście na nowoczesne biblioteki uwierzytelniania, takie jak MSAL.js v2+ i PKCE, uwolni cię od „staroszkolnych” błędów, takich jak AADSTS700054, prawda? Nic bardziej mylnego. Nawet nowoczesne aplikacje typu Single Page Application mogą mieć problemy, jeśli ich rejestracja aplikacji lub konfiguracja po stronie klienta nie są zgodne z obecnymi najlepszymi praktykami.

Największym winowajcą są nieaktualne założenia. Deweloperzy mogą zacząć korzystać z MSAL.js, ale pozostawiać starsze identyfikatory URI przekierowania albo przypadkowo żądać typów odpowiedzi (np. id_token), które nie są włączone w Azure AD. Dotyczy to szczególnie sytuacji, gdy manifest aplikacji został skopiowany z innego projektu. Efekt jest taki, że Azure AD zwraca ten paskudny błąd, gdy aplikacja uruchamia przepływ uwierzytelniania.

Jak to debugować? Otwórz narzędzia deweloperskie przeglądarki, przejdź do karty Sieć i obserwuj żądanie autoryzacji. Sprawdź dokładnie, czy response_type odpowiada przepływom, które faktycznie są dozwolone w twojej aplikacji Azure. Jeśli widzisz żądania tokenów, które nie są prawidłowo włączone, wróć do portalu Azure i odpowiednio popraw rejestrację aplikacji.

Pamiętaj: w przypadku MSAL.js v2 i PKCE zazwyczaj w ogóle nie trzeba włączać przepływu implicit. Jeśli jednak twoja aplikacja nadal nie działa, poszukaj zakodowanych na sztywno ustawień „implicit”, literówek w identyfikatorach URI przekierowania lub nieprawidłowych typów grantów. Dokładny przegląd konfiguracji (po stronie Azure i klienta) rozwiązuje większość problemów. Może nie jest to efektowne, ale skuteczne rozwiązywanie problemów oszczędza godziny zgadywania.

Migracja starszych aplikacji z implicit grant na PKCE

Gotowy, by na dobre zostawić przepływ implicit za sobą? Dobra decyzja. Migracja na PKCE (Proof Key for Code Exchange) jest obecnie złotym standardem, a Microsoft zdecydowanie ją zaleca. Ale bądźmy szczerzy: migracja działającej aplikacji używanej przez użytkowników to nigdy nie jest zwykłe przełączenie ustawienia. Potrzebujesz planu, który pozwoli uniknąć przestojów, zminimalizuje zakłócenia logowania i na bieżąco będzie informował wszystkich zainteresowanych.

Pierwszym krokiem jest ocena i inwentaryzacja wszystkich bieżących rejestracji aplikacji korzystających z implicit grant. Następnie przetestuj nowy przepływ oparty na PKCE w środowisku testowym. Oznacza to ustawienie aplikacji tak, aby korzystała z przepływu kodu autoryzacji, aktualizację identyfikatorów URI przekierowania oraz modyfikację plików konfiguracyjnych klienta (np. zastąpienie MSAL.js lub ADAL.js). Przejdź przez pełne cykle logowania i wylogowania oraz odnawiania tokenów. Upewnij się, że działa dla wszystkich typów użytkowników.

Zanim przełączysz produkcję, przygotuj plan wycofania zmian. Może być konieczne tymczasowe pozostawienie włączonych obu przepływów, jeśli migracja nie przebiegnie gładko. Jasno komunikuj się z użytkownikami, bo nie lubią niespodzianek, zwłaszcza gdy ich praca staje z powodu nieogłoszonej zmiany sposobu logowania.

Na koniec zwróć uwagę na problemy, takie jak błędy odnawiania tokenów czy przerwane aktywne sesje po migracji. Jeśli to możliwe, planuj aktualizacje na okresy małego ruchu. Potrzebujesz więcej informacji o wdrażaniu tych zmian w praktyce? Chociaż niektóre zasoby przekierowują dalej, zawsze warto sprawdzić najnowsze podcasty o Microsoft 365 Copilot i architekturze, w których znajdziesz pośrednie wskazówki dotyczące zarządzania zmianami w przedsiębiorstwie (zobacz najnowsze dyskusje tutaj).

Wiarygodne blogi, takie jak Nishant Rana’s Weblog, czyli jak znaleźć sprawdzone rozwiązania

• Nishant Rana’s Weblog: Doskonałe źródło wiedzy o rozwiązywaniu problemów z integracją Azure AD. Nishant omawia szczegółowe scenariusze, rozwiązania krok po kroku, a nawet niszowe przypadki dla Dynamics 365 i Power Platform. Jego przejrzyste poradniki sprawiają, że zawiłe błędy uwierzytelniania przestają być tak przytłaczające.
• KingswaySoft MVP Blog: Blog znany z praktycznych porad dotyczących integracji danych CRM. Prowadzony przez MVP regularnie opisuje nietypowe przypadki uwierzytelniania, co jest istotne dla każdego, kto pracuje z Azure AD i ekosystemem Microsoft 365.
• Top 100 CRM Blogs: Zestawienia tego typu pokazują szersze środowisko techniczne i pomagają odkrywać autorów, którzy regularnie publikują o tożsamości, bezpieczeństwie i rozwiązywaniu problemów w Microsoft. Poszerzenie listy lektur zwiększa szansę na znalezienie rozwiązania dopasowanego do Twojego nietypowego przypadku.

Jak szybko wyszukiwać i przeglądać archiwum, aby znaleźć najnowsze wpisy o problemach z Azure AD

• Korzystaj z szybkiego wyszukiwania: Większość renomowanych blogów technicznych ma pole wyszukiwania, więc warto z niego skorzystać. Wpisz „AADSTS700054”, „Azure AD error” lub „implicit grant”, aby od razu znaleźć wpisy i poradniki dotyczące Twojego problemu. To znacznie szybsze niż ręczne przeglądanie.
• Przeglądaj archiwum i najnowsze aktualizacje: Jeśli nie znajdziesz problemu za pomocą wyszukiwania, przejrzyj archiwum strony lub filtrowane listy „najnowszych wpisów”. Wiele sprawdzonych poradników dotyczących rozwiązywania problemów kryje się w starszych treściach, a czasem najnowszy wpis zawiera dokładnie to rozwiązanie, którego potrzebujesz, w związku z nowymi zmianami w uwierzytelnianiu na platformie Microsoft.
• Łącz filtry, jak zaawansowani użytkownicy: Chcesz pójść o krok dalej? Połącz wyszukiwanie z systemem tagów lub kategorii. Filtrowanie wszystkich wpisów o „Azure AD” albo zawężanie do „app registration” skróci czas rozwiązywania problemów i pozwoli odkryć przypadki oraz rozwiązania, które mogłyby Ci umknąć.