AADSTS900561: błąd Endpoint Only Accepts POST

By Mirko Peters · 2026-04-22 · Updated 2026-07-28

Dowiedz się, czym jest błąd AADSTS900561 (endpoint only accepts POST), dlaczego pojawia się podczas logowania w Microsoft Entra i jak bezpiecznie go diagnozować.

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

Szybka odpowiedź: Błąd AADSTS900561 (endpoint only accepts POST) oznacza, że punkt końcowy uwierzytelniania Microsoft Entra otrzymał żądanie z nieobsługiwaną metodą. Sprawdź przepływ logowania w aplikacji, obsługę przekierowań oraz dokładny adres URL, który jest otwierany, zamiast wielokrotnie zmieniać ustawienia tożsamości obowiązujące w całej dzierżawie.

Czy zdarzyło Ci się natrafić na błąd AADSTS900561 podczas pracy z Microsoft Entra ID lub Azure Active Directory? To ten, który mówi: „Endpoint only accepts POST requests” (punkt końcowy akceptuje tylko żądania POST). Mówiąc prostym językiem: aplikacja próbowała połączyć się z usługą uwierzytelniania Microsoft żądaniem GET, ale serwer oczekuje żądania POST. To jak pukanie do tylnych drzwi, gdy trzeba było skorzystać z wejścia głównego.

Ten błąd pojawia się często podczas tworzenia lub integrowania aplikacji dla Microsoft 365, Azure lub Power Platform. Zwykle występuje w przepływach logowania lub przy próbie uzyskania tokenu z platformy tożsamości Microsoft. Zrozumienie, co wywołuje błąd AADSTS900561, jest kluczowe, ponieważ wskazuje dokładnie, gdzie wywołania uwierzytelniania nie są zgodne z wymaganiami technicznymi Microsoft. Dalej wyjaśnię, dlaczego ten błąd jest zgłaszany i jak wiąże się z innym znanym kodem, AADSTS90056.

Opis błędów AADSTS90056 i AADSTS900561 oraz tło techniczne

Zanim zabierzesz się za naprawę błędu AADSTS900561, warto dokładnie wiedzieć, z czym masz do czynienia. Zarówno AADSTS90056, jak i AADSTS900561 to kody błędów zwracane przez Microsoft Entra ID (dawniej Azure AD), gdy coś jest nie tak w sposobie, w jaki aplikacja komunikuje się z punktami końcowymi uwierzytelniania. W skrócie: AADSTS90056 zwykle wskazuje na nieprawidłowy lub brakujący parametr uwierzytelniania, natomiast AADSTS900561 dotyczy wyłącznie metody HTTP, a konkretnie użycia GET tam, gdzie wymagane jest POST.

Microsoft Entra ID stosuje ścisłe reguły protokołu dla wymiany tokenów i przepływów uwierzytelniania, często opartych na OAuth 2.0. Gdy aplikacja potrzebuje tokenu i wysyła żądanie do punktu końcowego /token, Microsoft oczekuje żądania POST. To nie kaprys – żądania POST pozwalają bezpiecznie przesyłać wrażliwe dane w treści żądania, a nie w adresie URL, co ogranicza ryzyko wycieku i przypadkowego zapisania danych w logach.

Żądania GET to z kolei otwarta księga. Umieszczają Twoje dane bezpośrednio w adresie URL, widocznym dla każdego, kto lub cokolwiek znajduje się po drodze, na przykład dla serwera proxy. To problem bezpieczeństwa, zwłaszcza w usługach korporacyjnych zarządzających tożsamościami i danymi wrażliwymi. Dlatego platforma tożsamości Microsoft wymusza POST przy każdej operacji obejmującej wymianę sekretów, kodów lub danych użytkownika. Jeśli wyślesz GET, platforma go wychwyci i zatrzyma żądanie z błędem AADSTS900561. Znajomość tego tła technicznego pomaga zrozumieć nie tylko, co poszło nie tak, ale także dlaczego ta zasada istnieje i dlaczego nie podlega dyskusji w usługach chmurowych Microsoft.

Podsumowując, jeśli podczas uwierzytelniania widzisz którykolwiek z tych kodów, Twoja aplikacja wysyła żądanie niezgodne z zasadami. Mając na uwadze kontekst bezpieczeństwa i niezawodny przepływ protokołu, łatwiej będzie Ci ustalić, co naprawić i dlaczego ma to znaczenie w profesjonalnych środowiskach aplikacyjnych.

Typowe przyczyny i rozwiązania problemów z uwierzytelnianiem AADSTS900561

Jeśli pojawia się błąd AADSTS900561, niemal na pewno w sposobie, w jaki aplikacja łączy się z punktem końcowym tokenów Microsoft, jest jakiś błąd. Jedną z głównych przyczyn jest źle skonfigurowana rejestracja aplikacji lub błędny identyfikator URI przekierowania w Azure AD. Jeśli zarejestrowany identyfikator URI przekierowania nie zgadza się z tym, którego faktycznie używa aplikacja, albo brakuje w nim wymaganych elementów, możesz przypadkowo wywołać żądanie GET zamiast oczekiwanego POST.

Kolejnym klasycznym błędem jest sposób zakodowania samego przepływu uwierzytelniania. Niektórzy programiści przypadkowo używają GET podczas wywoływania punktu końcowego /token, zwłaszcza gdy ręcznie budują żądania albo źle zrozumieli bibliotekę, z której korzystają. W OAuth 2.0 z Microsoft Entra ostatnie pobranie tokenu zawsze powinno być wysyłane jako POST, nigdy jako GET. Jeśli Twój przepływ wysyła w tym kroku GET, błąd AADSTS900561 pojawi się od razu.

Jak to naprawić? Zacznij od ponownego sprawdzenia identyfikatorów URI przekierowania zarówno w rejestracji aplikacji w portalu Azure, jak i w lokalnej konfiguracji aplikacji. Upewnij się, że są identyczne, aż do protokołu (http lub https) i ścieżki. Jeśli korzystasz z bibliotek MSAL lub ADAL, sprawdź, czy nie używasz starej wersji i czy Twój kod nie nadpisuje domyślnego zachowania POST. Jeśli masz własny kod uwierzytelniania, przeanalizuj wywołania HTTP i upewnij się, że do punktu końcowego tokenu zawsze wysyłane jest żądanie POST.

Potrzebujesz pomocy z kodem? Oto szybka wskazówka: w JavaScript, przy użyciu fetch lub axios, upewnij się, że wywołanie /token wygląda mniej więcej tak: method: 'POST'. Jeśli w logach lub w przeglądarce widzisz komunikat „endpoint only accepts post”, to sygnał, by sprawdzić każdy krok kodu między autoryzacją a wymianą tokenu, szczególnie jeśli aplikacja przełącza logikę między front-endem a back-endem. Aby lepiej poznać zagrożenia związane z tożsamością i praktyczne rozwiązania w zakresie zarządzania, zapoznaj się z tym odcinkiem o tożsamości jako płaszczyźnie kontroli w zabezpieczeniach Azure.

Debugowanie i najlepsze praktyki zapobiegania błędom AADSTS900561

Przyjrzyjmy się temu, jak namierzyć ten błąd i upewnić się, że więcej Cię nie dopadnie. Jeśli uruchamiasz aplikację typu SPA (single page app) w React, Vue lub Angular, otwórz narzędzia deweloperskie przeglądarki. Przejdź do karty Sieć (Network), wykonaj proces logowania i uważnie obserwuj żądania GET kierowane do punktu końcowego /token. Gdy je zobaczysz, znajdziesz winowajcę.

Czasami problem wynika z nieprawidłowej konfiguracji biblioteki uwierzytelniania. Na przykład w MSAL.js użycie loginRedirect zamiast acquireTokenSilent lub błędna konfiguracja biblioteki może powodować wysłanie żądania GET zamiast POST. Aktualizacja MSAL.js do najnowszej wersji i ponowne sprawdzenie ustawień inicjalizacji może zaoszczędzić mnóstwo kłopotów. Frameworki bywają wymagające, ale dokumentacja Microsoftu jasno wskazuje, że żądania tokenu muszą używać metody POST.

Nie lekceważ też logów Azure. Sprawdź logi logowania Azure AD, aby zobaczyć szczegółowe ślady żądań. Zobaczysz, który punkt końcowy został wywołany, jaka metoda została użyta i czy są oznaczenia niezgodności protokołu. Jeśli potrzebujesz zaawansowanej diagnostyki, narzędzia takie jak Fiddler pozwolą szczegółowo przeanalizować ruch HTTP, a Application Insights wskaże na stosie wywołań dokładne miejsce problemu.

Zapobieganie jest lepsze niż gaszenie pożarów. Zawsze testuj przepływy uwierzytelniania w środowisku deweloperskim i testowym, zanim wdrożysz je na produkcję. Upewnij się, że każdy fragment kodu wymieniający kod autoryzacji na token działa po stronie serwera, z użyciem metody POST, zgodnie z przewodnikiem OAuth 2.0. Wymiana kodów w przeglądarce to typowy sposób na wywołanie błędu AADSTS900561 i stworzenie luk w zabezpieczeniach.

Jeśli pracujesz w większych środowiskach Microsoft 365 lub Azure, przyjrzyj się swojemu podejściu do zarządzania. Entra ID stanowi obecnie podstawę wielu krytycznych mechanizmów dostępu, więc utrzymanie ścisłych zasad i zgodność kodu z najlepszymi praktykami Microsoftu znacznie ułatwiają pracę. Informacje o projektowaniu zarządzania, które nie pozwoli na przeoczenie istotnych kwestii, znajdziesz w tym odcinku o strategii zarządzania przedsiębiorstwem w Azure, który warto obejrzeć.

A jeśli Twoja aplikacja jest częścią Power Platform lub po prostu korzysta z konektorów, zarządzaj tożsamościami i konektorami z rozwagą, aby uniknąć dryfu architektury i nieoczekiwanych błędów uprawnień. Praktyczne wskazówki znajdziesz w tym materiale: najlepsze praktyki zabezpieczeń i zarządzania w Power Platform.

Podsumowując: poznaj swoje przepływy uwierzytelniania, weryfikuj każde żądanie i utrzymuj narzędzia w aktualnej wersji. Jeśli mimo to błąd się pojawi, będziesz wiedział, gdzie szukać i jak raz na zawsze go wyeliminować.

Praktyczna lista kontrolna

• Potwierdź dokładny rezultat dla użytkownika oraz zakres, którego dotyczy zmiana.
• Wybierz najwęższą bezpieczną konfigurację lub sposób komunikacji.
• Przetestuj działanie przed szerokim wdrożeniem.
• Udokumentuj właścicieli, działania następcze i punkty przeglądu.

Często zadawane pytania

Jaki jest najlepszy pierwszy krok?

Określ scenariusz użytkownika i konkretny rezultat, którego potrzebujesz. Zapobiega to zbędnym zmianom i daje wyraźniejsze, bardziej niezawodne wdrożenie.

🎧 Warto też posłuchać

• Identity Governance w Entra zapewnia kontekst zarządzania wokół administrowania tożsamością.
• Microsoft Entra Private Access – Simply Explained wyjaśnia nowoczesną architekturę tożsamości i dostępu.
• Privileged Identity Management (PIM) – Simply Explained dodaje kontekst dostępu uprzywilejowanego dla administratorów Entra.

Ostatni przegląd: lipiec 2026.