KO
English
Deutsch
Español
Français
Italiano
Português
Nederlands
Polski
Bahasa Indonesia
Русский
Українська
العربية
עברית
日本語AADSTS900561: 엔드포인트는 POST만 허용 오류
By Mirko Peters · · Updated
AADSTS900561 엔드포인트는 POST만 허용 오류의 의미, Microsoft Entra 로그인 중 발생하는 이유, 그리고 안전하게 문제를 해결하는 방법을 알아봅니다.
Automatically translated with AI from the original post. Read the English original
빠른 답변: AADSTS900561 엔드포인트는 POST만 허용 오류는 Microsoft Entra 인증 엔드포인트가 지원되지 않는 메서드로 보낸 요청을 받았다는 뜻입니다. 테넌트 전체의 ID 설정을 반복해서 바꾸기보다는 애플리케이션의 로그인 흐름, 리디렉션 처리, 그리고 실제로 열리는 정확한 URL을 확인하십시오.
Microsoft Entra ID나 Azure Active Directory로 작업하다가 AADSTS900561 오류를 본 적이 있으신가요? “Endpoint only accepts POST requests.”라고 나오는 바로 그 오류입니다. 쉽게 말해, 앱이 GET 요청으로 Microsoft 인증 서비스에 접근하려 했지만 서버는 POST를 기대한다는 뜻입니다. 정문으로 들어가야 할 자리에 뒷문을 두드린 것과 같습니다.
이 오류는 Microsoft 365, Azure, Power Platform용 앱을 개발하거나 연동할 때 자주 나타납니다. 주로 로그인 흐름이나 Microsoft ID 플랫폼에서 토큰을 받으려 할 때 발생합니다. AADSTS900561 오류를 일으키는 원인을 이해하면 인증 호출이 Microsoft의 기술 요구 사항과 어디서 어긋나는지 바로 알 수 있습니다. 다음으로 이 오류가 왜 발생하는지, 그리고 또 다른 익숙한 오류 코드인 AADSTS90056과 어떻게 연관되는지 자세히 살펴보겠습니다.
AADSTS90056과 AADSTS900561의 오류 설명 및 배경
AADSTS900561 문제를 해결하기 전에 어떤 상황인지 정확히 파악해 두면 도움이 됩니다. AADSTS90056과 AADSTS900561은 앱이 인증 엔드포인트와 통신하는 방식에 문제가 있을 때 Microsoft Entra ID(이전 명칭: Azure AD)가 반환하는 오류 코드입니다. 간단히 말하면, AADSTS90056은 보통 잘못되었거나 누락된 인증 매개 변수를 가리키고, AADSTS900561은 HTTP 메서드 문제, 특히 POST가 필요한 곳에 GET을 사용한 경우에 초점을 맞춥니다.
Microsoft Entra ID는 주로 OAuth 2.0을 기반으로 하는 토큰 교환과 인증 흐름에 엄격한 프로토콜 규칙을 적용합니다. 앱이 /token 엔드포인트를 호출해 토큰을 받아야 할 때 Microsoft는 POST 요청을 기대합니다. 이는 단순히 까다롭게 구는 것이 아닙니다. POST 요청은 민감한 데이터를 URL이 아닌 요청 본문에 담아 안전하게 보낼 수 있어, 유출이나 의도치 않은 로깅 위험을 줄여 줍니다.
반면 GET 요청은 내용이 그대로 드러나는 열린 책과 같습니다. 요청 정보가 URL에 그대로 붙어 있어 경로상의 누구든 또는 어떤 프록시든 볼 수 있습니다. 특히 ID와 민감한 데이터를 관리하는 엔터프라이즈 서비스에서는 보안상 중대한 문제입니다. 그래서 Microsoft ID 플랫폼은 비밀 값, 코드 또는 사용자 정보를 교환하는 모든 작업에 POST를 강제합니다. GET을 보내면 플랫폼이 이를 감지하고 AADSTS900561 오류로 요청을 차단합니다. 이러한 기술적 배경을 알면 무엇을 잘못했는지뿐 아니라 왜 이 규칙이 존재하는지, 그리고 Microsoft 클라우드 서비스 전반에서 이 규칙이 왜 타협할 수 없는지도 이해할 수 있습니다.
요약하면, 인증 중에 이 두 코드 중 하나가 보인다면 앱이 규칙에 맞지 않는 요청을 보내고 있다는 뜻입니다. 이 오류 코드 뒤에 있는 보안과 안정적인 프로토콜 흐름의 맥락을 이해하면, 무엇을 수정해야 하고 전문적인 앱 환경에서 그것이 왜 중요한지 훨씬 명확하게 파악할 수 있습니다.
AADSTS900561 인증 문제의 일반적인 원인과 해결 방법
AADSTS900561이 나타난다면 앱이 Microsoft 토큰 엔드포인트에 요청하는 방식에 실수가 있을 가능성이 높습니다. 가장 흔한 원인 중 하나는 잘못 구성된 애플리케이션 등록이나 Azure AD의 잘못된 리디렉션 URI입니다. 등록된 리디렉션 URI가 앱이 실제로 사용하는 값과 일치하지 않거나 필수 정보가 빠져 있다면, 의도치 않게 예상된 POST 대신 GET 요청을 발생시킬 수 있습니다.
또 다른 전형적인 실수는 인증 흐름 자체를 코딩하는 방식에 있습니다. 특히 요청을 직접 작성하려고 하거나 사용하는 라이브러리를 잘못 이해한 경우, 일부 개발자는 /token 엔드포인트를 호출할 때 실수로 GET을 사용합니다. Microsoft Entra를 사용하는 OAuth 2.0에서 최종 토큰 획득 단계는 항상 GET이 아닌 POST로 보내야 합니다. 이 단계에서 워크플로가 GET을 보내면 AADSTS900561 오류가 바로 나타납니다.
그럼 어떻게 고쳐야 할까요? 먼저 Azure 포털의 앱 등록과 로컬 애플리케이션 구성에 있는 리디렉션 URI를 다시 확인하세요. 프로토콜(http 또는 https)과 경로까지 정확히 일치하는지 꼼꼼히 봐야 합니다. MSAL이나 ADAL 라이브러리를 사용 중이라면 오래된 버전을 쓰고 있지 않은지, 그리고 기본 POST 동작을 덮어쓰는 코드를 작성하지 않았는지 확인하세요. 자체 인증 코드를 사용한다면 HTTP 호출을 점검해서 토큰 엔드포인트에 항상 POST 요청이 전송되는지 확인하세요.
코드 관련 도움이 필요하신가요? 간단한 팁을 하나 드리겠습니다. JavaScript에서 fetch나 axios를 사용한다면 /token 호출이 method: 'POST' 같은 형태인지 확인하세요. 로그나 브라우저에서 "endpoint only accepts post" 메시지가 보인다면, 인증 단계부터 토큰 교환 단계까지 코드가 거치는 모든 과정을 점검할 때입니다. 특히 앱이 프런트엔드와 백엔드 로직을 오갈 때 더 주의하세요. 신원 기반 위험과 실제 거버넌스 해결 방법을 더 깊이 알고 싶다면 Azure 보안의 컨트롤 플레인으로서의 ID를 다룬 이 에피소드를 확인해 보세요.
AADSTS900561 오류를 방지하기 위한 디버깅 및 모범 사례
이 오류를 추적하고 다시 발생하지 않도록 하는 방법을 살펴보겠습니다. React, Vue, Angular를 사용하는 단일 페이지 앱(SPA)을 실행 중이라면 브라우저의 개발자 도구를 여세요. 네트워크 탭을 열고 로그인 흐름을 실행한 뒤, /token 엔드포인트로 향하는 GET 요청을 주의 깊게 살펴보세요. 그 요청이 보이면 원인을 찾은 것입니다.
때로는 인증 라이브러리가 올바르게 설정되지 않아서 이 문제가 발생합니다. 예를 들어 MSAL.js에서 acquireTokenSilent를 쓰려던 자리에 loginRedirect를 사용하거나 라이브러리를 잘못 구성하면 POST 대신 GET 요청이 발생할 수 있습니다. MSAL.js를 최신 버전으로 업데이트하고 초기화 설정을 다시 확인하면 많은 어려움을 덜 수 있습니다. 프레임워크마다 까다로운 부분이 있지만, 토큰 요청에 POST가 필요하다는 점은 Microsoft 문서에 분명히 나와 있습니다.
Azure 로그도 놓치지 마세요. 자세한 요청 추적 정보는 Azure AD 로그인 로그에서 확인할 수 있습니다. 여기서 호출된 엔드포인트, 사용된 메서드, 프로토콜 불일치 여부를 나타내는 플래그를 볼 수 있습니다. 심층 진단이 필요하다면 Fiddler 같은 도구로 HTTP 트래픽을 한 줄씩 분석하거나, Application Insights로 호출 스택을 추적해 문제 지점을 바로 찾을 수 있습니다.
문제가 생긴 뒤에 수습하기보다 미리 예방하는 것이 낫습니다. 인증 흐름은 운영 환경에 적용하기 전에 개발 및 스테이징 환경에서 항상 테스트하세요. 인증 코드를 토큰으로 교환하는 모든 코드는 OAuth 2.0 표준에 따라 서버 측에서 POST 방식으로 실행되도록 하세요. 브라우저에서 코드를 교환하는 것은 AADSTS900561 오류를 일으키고 보안 취약점을 만드는 전형적인 방법입니다.
규모가 큰 Microsoft 365 또는 Azure 환경에서 일하신다면 거버넌스 접근 방식을 점검해 보세요. Entra ID는 이제 많은 핵심 액세스의 기반이므로, 정책을 엄격하게 유지하고 코드가 Microsoft 모범 사례를 따르도록 하면 관리가 훨씬 수월해집니다. 허점이 생기지 않도록 거버넌스를 설계하는 방법은 이 Azure 엔터프라이즈 거버넌스 전략 에피소드에서 자세히 다루고 있으니 한번 살펴보실 만합니다.
앱이 Power Platform의 일부이거나 커넥터만 사용하더라도, ID와 커넥터를 신중하게 관리해 아키텍처 드리프트와 예상치 못한 권한 오류를 피하세요. 실질적인 가이드는 이 자료에서 확인할 수 있습니다: Power Platform 보안 및 거버넌스 모범 사례.
결론적으로, 인증 흐름을 정확히 이해하고, 모든 요청을 검증하며, 도구를 최신 상태로 유지하세요. 그래도 오류가 발생하더라도 어디를 살펴봐야 하고 어떻게 근본적으로 해결할지 정확히 알 수 있을 것입니다.
실무 체크리스트
- 정확한 사용자 결과와 영향 범위를 확인하세요.
- 가장 좁고 안전한 구성 또는 커뮤니케이션 방식을 선택하세요.
- 광범위하게 배포하기 전에 사용자 경험을 테스트하세요.
- 담당자, 후속 조치, 검토 지점을 문서화하세요.
자주 묻는 질문
가장 먼저 해야 할 일은 무엇인가요?
사용자 시나리오와 필요한 구체적인 결과를 파악하세요. 그래야 불필요한 변경을 피하고 더 명확하고 안정적인 구현을 할 수 있습니다.
🎧 함께 들으면 좋은 에피소드
- Identity Governance in Entra는 ID 관리를 둘러싼 거버넌스 맥락을 제공합니다.
- Microsoft Entra Private Access – Simply Explained는 최신 ID 및 액세스 아키텍처를 설명합니다.
- Privileged Identity Management (PIM) – Simply Explained는 Entra 관리자를 위한 특권 액세스 맥락을 더해 줍니다.
마지막 검토: 2026년 7월.