Rozwiązywanie błędu AADSTS900144 (brakujący parametr) w Azure AD

By Mirko Peters · 2026-04-21

Nikt nie lubi natrafiać na mur w postaci błędów uwierzytelniania, ale błąd AADSTS900144 o brakującym parametrze w Azure AD to jedna z klasycznych przeszkód, które frustrują wszystkich, od deweloperów aplikacji po administratorów IT. Ten artykuł wyjaśnia dokładnie, co stoi za tym błędem, co sprawdzić w pierwszej kolejności i jakie kroki podjąć, aby przywrócić dostęp użytkownikom. Omówimy przyczyny

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

Nikt nie lubi natrafiać na mur w postaci błędów uwierzytelniania, ale błąd AADSTS900144 o brakującym parametrze w Azure AD to jedna z klasycznych przeszkód, które frustrują wszystkich, od deweloperów aplikacji po administratorów IT. Ten artykuł wyjaśnia dokładnie, co stoi za tym błędem, co sprawdzić w pierwszej kolejności i jakie kroki podjąć, aby przywrócić dostęp użytkownikom. Omówimy przyczyny i sposoby ich usunięcia, od typowych pomyłek w parametrach po szczegółowe spojrzenie na przepływy OAuth i integracje aplikacji w chmurze.

Niezależnie od tego, czy wspierasz usługi Microsoft 365, Azure, Power Platform czy dowolne rozwiązanie łączące się z Entra ID, znajdziesz wskazówki dotyczące poprawek po stronie klienta i serwera. Praktyczne rozwiązywanie problemów, sprawdzone w warunkach korporacyjnych dobre praktyki oraz dodatkowe linki do materiałów o zarządzaniu chmurą pomogą Ci zapobiegać kłopotom, gdy ten błąd znowu się pojawi.

Dlaczego w uwierzytelnianiu Azure AD pojawia się komunikat „AADSTS900144”?

Błąd „AADSTS900144: Request body must contain the following parameter” pojawia się, gdy w żądaniu uwierzytelniania wysyłanym do Azure Active Directory (lub Microsoft Entra ID) brakuje kluczowych danych. Mówiąc prosto: Azure szuka w żądaniu tokenu informacji takich jak grant_type czy client_id, nie może ich znaleźć albo są obecne, ale źle sformatowane lub umieszczone w niewłaściwym miejscu.

Ten błąd najczęściej występuje w przepływach OAuth 2.0, szczególnie gdy użytkownicy lub aplikacje logują się przez usługi chmurowe przedsiębiorstwa. Zwykle dzieje się tak, bo coś jest nie tak z parametrami treści żądania wysyłanego podczas wymiany kodu autoryzacji na token. Jeśli obowiązkowy parametr zostanie pominięty, błędnie zapisany lub umieszczony poza oczekiwaną treścią POST, Azure AD zatrzymuje całą operację z kodem AADSTS900144.

Z tym błędem możesz spotkać się podczas integrowania własnych aplikacji biznesowych, rejestrowania nowych aplikacji w Azure lub gdy klienci desktopowi (na przykład Microsoft Teams) napotykają problemy z uwierzytelnianiem. Czasem już samo wklejenie tekstu z błędem albo szybka zmiana w rejestracji aplikacji może rozsynchronizować parametry. Komunikat może wyglądać enigmatycznie, ale to sposób, w jaki Azure mówi: „Wróć, sprawdź dokładnie swoje żądanie i popraw to, czego brakuje”.

Jeśli pracujesz z aplikacjami wielodzierżawczymi, pamiętaj, że niezgodności w kontekście dzierżawy lub w punktach końcowych usług mogą wywoływać podobne zamieszanie. Czasem wygląda to tak, jakby parametr faktycznie brakował, choć w rzeczywistości żądanie trafiło w niewłaściwe miejsce. Zrozumienie tych mechanizmów przyspiesza rozwiązywanie problemów i zmniejsza stres zespołów wsparcia.

Typowe problemy z parametrami treści żądania i szybkie poprawki

Błąd AADSTS900144 niemal zawsze sprowadza się do czegoś pominiętego lub umieszczonego w niewłaściwym miejscu w żądaniu tokenu. Kluczowe parametry, takie jak client_id i grant_type, to najczęstsi podejrzani. Jeśli aplikacja pominie choćby jeden wymagany parametr, punkt końcowy tokenu Azure AD odrzuci żądanie. Upewnij się, że używasz metody HTTP POST, ponieważ żądania GET i inne metody tutaj nie zadziałają.

Zacznij od sprawdzenia, czy aplikacja wysyła żądania z typem zawartości application/x-www-form-urlencoded. Zdumiewające, jak często niewłaściwy typ zawartości powoduje, że Azure AD szuka parametrów, których nie potrafi odczytać. Następnie otwórz dowolne narzędzie do obsługi żądań HTTP (Postman, curl lub nawet Fiddler) i sprawdź surową treść: czy client_id, grant_type, client_secret i pozostałe parametry faktycznie znajdują się w ładunku, a nie jako wartości ciągu zapytania ani ukryte w nagłówkach?

Jeśli modyfikujesz rejestrację aplikacji, pamiętaj, że oczekiwane parametry mogą się różnić w zależności od przepływu przyznawania uprawnień. Na przykład użycie przepływu z kodem autoryzacji oznacza, że trzeba dodatkowo podać code. Nie zawsze jest to oczywiste, dlatego przed uznaniem sprawy za zamkniętą zawsze porównaj typ przyznawania uprawnień z dokumentacją Azure.

W aplikacjach wielodzierżawczych uważaj na wysyłanie żądań do punktu końcowego /common, gdy docelowa dzierżawa wymaga konkretnego identyfikatora GUID lub innej wartości. W przeciwnym razie Twój „brakujący parametr” może być po prostu źle skierowanym żądaniem. Kierowanie żądań pod niewłaściwy adres, szczególnie w scenariuszach międzydzierżawczych, potrafi zmylić nawet doświadczonych deweloperów, dlatego zawsze sprawdzaj punkt końcowy i parametry razem. Gdy to naprawisz, w większości przypadków uciążliwy błąd AADSTS900144 zniknie na Twoich oczach.

Rozwiązywanie problemów po stronie klienta: czyszczenie buforowanych poświadczeń i resetowanie aplikacji

Czasem problem nie leży w kodzie, tylko w lokalnym komputerze, który zakłóca przepływ uwierzytelniania. Buforowane poświadczenia i stare pliki cookie mogą przechowywać nieaktualne tokeny lub uszkodzone dane parametrów, szczególnie w aplikacjach desktopowych, takich jak Microsoft Teams czy Outlook. Wtedy użytkownicy nadal widzą komunikat AADSTS900144, nawet po naprawieniu problemów po stronie zaplecza.

Najprostszym pierwszym krokiem jest usunięcie zapisanych poświadczeń. W systemie Windows użyj Menedżera poświadczeń, aby usunąć buforowane tokeny powiązane z Twoim kontem. W aplikacjach webowych usunięcie plików cookie i danych witryny w przeglądarce może uruchomić czyste ponowne uwierzytelnienie. W uporczywych przypadkach, szczególnie w usłudze Microsoft Teams, spróbuj lokalnego resetu: wyloguj się ze wszystkich miejsc, zamknij aplikację i usuń foldery pamięci podręcznej przed ponownym uruchomieniem. Niektórzy użytkownicy mogą potrzebować całkowitego usunięcia profilu konta Teams z ustawień urządzenia, aby mieć pewność, że nie pozostały żadne ślady, a następnie ponownej instalacji Teams od zera.

Jeśli wspierasz innych użytkowników, przygotuj prostą listę kontrolną: wyczyść poświadczenia, zamknij aplikację, wyczyść pamięć podręczną, a następnie zaloguj się ponownie. Ogranicza to przestoje i zamieszanie u użytkowników biznesowych, którzy chcą po prostu wrócić do pracy z aplikacjami. Zespoły wsparcia IT powinny zawsze upewnić się, że wszystkie stare dane uwierzytelniające zostały usunięte, zanim zaczną szukać przyczyny głębiej, ponieważ pozostałe nieaktualne dane są jedną z głównych przyczyn uporczywych błędów AADSTS900144.

Jeśli zajmujesz się zarządzaniem usługą Microsoft Teams lub powtarzającymi się problemami z uwierzytelnianiem, warto pamiętać, że same poprawki techniczne nie „rozwiązują” zagadnienia zarządzania. Aby lepiej zrozumieć, dlaczego zarządzanie nigdy nie jest zakończone i jak wdrożyć je w praktyce, zajrzyj do tego przewodnika o zarządzaniu Teams i iluzji kontroli lub sprawdź ten poradnik dotyczący automatyzacji cyklu życia Teams, zawierający praktyczne strategie.

Najlepsze praktyki zapobiegania błędowi AADSTS900144 w aplikacjach przedsiębiorstwa

Zapobieganie błędowi AADSTS900144 sprowadza się przede wszystkim do dyscypliny w zakresie żądań OAuth i konfiguracji aplikacji. Wyrób sobie nawyk weryfikowania wszystkich wymaganych parametrów, szczególnie client_id i grant_type, zanim wyślesz żądania do punktu końcowego tokenu Azure AD. Zautomatyzowane kontrole w potoku wdrożeniowym pozwolą wychwycić brakujące lub nieprawidłowo sformatowane parametry, zanim trafią na środowisko produkcyjne, i oszczędzą Ci mnóstwa zgłoszeń w przyszłości.

Użyj narzędzi deweloperskich usługi Microsoft Entra ID, aby zasymulować żądania uwierzytelniania i zobaczyć, co widzi Azure AD. Pozwala to wykryć nie tylko brakujące parametry, ale też niezgodne punkty końcowe lub zasady, które mogą blokować poprawne żądania w określonych dzierżawach. Konfiguracja testów jednostkowych z atrapami punktów końcowych Entra ID dodatkowo ograniczy liczbę niespodzianek, ujawniając problemy z parametrami na etapie programowania, a nie w momencie uruchomienia.

W organizacjach o rozbudowanym zarządzaniu lub wielu zespołach programistycznych połącz weryfikację z praktykami infrastruktury jako kodu. Stosuj kontrole schematów w szablonach wdrożeniowych ARM lub Bicep, aby wymusić uwzględnienie wszystkich wymaganych parametrów OAuth podczas rejestracji aplikacji. Zmniejsza to ryzyko rozbieżności i błędnych konfiguracji, szczególnie gdy aplikacje ewoluują.

W podejściu nastawionym na bezpieczeństwo zachowaj czujność wobec udzielania zgód OAuth i egzekwowania zasad. Atakujący chętnie wykorzystują luźne ustawienia zgód, dlatego zablokuj zgody udzielane przez użytkowników, wymagaj zatwierdzonych wydawców i wymuszaj procesy zatwierdzania przez administratorów. Solidne omówienie tych zagrożeń i sposobów ich ograniczania znajdziesz w analizie ataków na zgody OAuth w usłudze Entra ID. Jeśli udoskonalasz procesy zarządzania, warto wykorzystać automatyzację, RBAC i Azure Policy. Zobacz ten przewodnik strategiczny dotyczący zarządzania w przedsiębiorstwie w Azure, który zawiera wskazówki projektowe i praktyczne mechanizmy kontroli.