MSAL4J 범위
MSAL의 주요 기능은 무엇인가요?
보호된 리소스에 액세스하기 위해 클라이언트 애플리케이션에 대한 STS(보안 토큰 서비스)에서 토큰을 획득합니다.
MSAL4J란?
MSAL은 많은 프로그래밍 언어 및 플랫폼에서 사용할 수 있습니다. MSAL4J는 Java 가상 머신에서 실행되는 모든 애플리케이션에서 사용하도록 설계되었습니다.
MSAL은 토큰 획득을 위해 어떤 표준 프로토콜을 따르나요?
MSAL은 OAuth2 프로토콜의 사용자 지정 버전을 구현하고 있습니다. 또한 일부 특정 시나리오의 경우 내부적으로 다른 프로토콜(예: WS-Trust)을 사용할 수 있습니다.
MSAL은 OAuth2 프로토콜을 사용하는 토큰 획득을 위한 일반 라이브러리인가요?
아니요. MSAL은 ADFS(Microsoft Entra ID, Active Directory Federation Services) 및 Azure Active Directory B2C용 클라이언트 라이브러리입니다. 일반 OAuth2 프로토콜 사양에 대한 확장으로 간주되고 다른 STS에서 지원되지 않는 ADAL에 필요한 "리소스"와 같은 몇 가지 사용자 지정 개념이 있습니다.
API 확장
생성자에 false를 전달하여 기관 유효성 검사를 해제해야 하나요?
그것은 당신이 말하는 권세의 유형에 따라 달라집니다. ADFS인 경우 ADFS가 현재 기관 유효성 검사를 지원하지 않으므로 false를 전달해야 합니다. Microsoft Entra ID 경우 여전히 false를 전달하는 옵션이 있지만, 특히 제3자(예: 401 챌린지를 통해)에서 권한 주소를 받는 경우 true로 권장됩니다. 이는 애플리케이션과 사용자가 악의적인 엔드포인트로 리디렉션되어 자격 증명을 입력하지 못하도록 보호하기 위한 것입니다.
호출해야 하는 AcquireToken의 오버로드는 무엇인가요?
사용하는 클라이언트 애플리케이션의 유형과 토큰이 필요한 시나리오에 따라 달라집니다. 토큰 획득에 설명된 지침을 참조하세요.
Debugging
MSAL 사용 실패의 일반적인 이유는 무엇인가요?
MSAL의 문제에는 여러 가지 이유가 있을 수 있습니다. 일반적인 원인은 다음과 같습니다.
- 컴퓨터에 연결 문제가 있습니다.
- 애플리케이션/사용자가 Microsoft Entra ID 또는 ADFS에서 제대로 구성되지 않았습니다.
- 작업에 잘못된 API를 사용하고 있습니다(MSAL에는 AcquireToken 메서드에 대해 몇 가지 유사한 오버로드가 있습니다).
- MSAL에 버그가 있습니다! 예, 항상 가능합니다. 위의 항목 중 오류가 발생하는 이유가 없다고 확신하는 경우 Microsoft에 보고해 주시면 버그를 조사하고 수정하겠습니다( 있는 경우).
ADAL에서 문제를 진단하는 데 사용할 수 있는 도구는 무엇인가요?
사용할 수 있는 몇 가지 진단 도구는 다음과 같습니다.
- MSAL 샘플: 가장 좋은 도구는 MSAL과 함께 게시된 샘플 집합입니다(라이브러리 리포지토리 내부 및 AzureSamples GitHub 조직에서 사용할 수 있는 샘플). 애플리케이션에 가장 가까운 샘플을 찾아 컴퓨터에서 다운로드하여 실행해 보세요. 샘플이 제대로 작동하는 경우 애플리케이션에서 샘플 앱의 동일한 단계를 따라야 합니다.
- MSAL 진단 로그: 로깅을 사용하도록 설정할 수 있습니다. 그러면 MSAL의 내부 단계에 대한 정보가 포함된 일부 로그가 작성됩니다. 로그를 분석하여 문제를 찾을 수 있습니다. 또한 MSAL 팀에 문의하는 경우 분석에 도움이 되도록 로그를 보내야 합니다. 공식 설명서에서 MSAL 로그를 켜는 방법에 대한 지침을 찾을 수 있습니다.
- 네트워크 추적: Fiddler와 같은 도구를 사용하여 MSAL이 서버와 만드는 모든 http 통신을 기록합니다. Fiddler는 특히 Windows 데스크톱 컴퓨터에서 사용하기 쉽습니다. 문제 진단에 관련된 경우 MSAL 팀과 네트워크 추적 파일을 공유하세요.
MSAL에서 예외로 반환되는 오류 종류와 사용자에게 보고되는 종류는 무엇인가요?
대부분의 오류는 예외의 형태로 MSAL에서 반환됩니다. 그러나 MSAL이 브라우저 컨트롤에 오류를 표시하는 경우는 제한적입니다. 이러한 경우는 클라이언트의 유효성을 검사할 수 없거나 기관 서버에 연결할 수 없는 경우에 주로 발생합니다.
MSAL 내에 어떤 종류의 재시도 논리가 있나요?
아니요. 작업이 실패하면 MSAL은 예외를 통해 오류를 보고합니다. 예외에는 오류 코드와 인증 기관에서 오류가 반환되는 경우의 상태 코드도 포함됩니다. 이러한 경우 개발자는 예외에서 상태 코드(주로 응답의 http 상태 코드를 반영함)를 검사하고 재시도 여부를 결정하는 것이 개발자의 작업입니다. 502는 일반적으로 재시도를 보증하는 상태 코드입니다.
MSAL 릴리스 모델
MSAL은 새 버전을 얼마나 자주 릴리스하나요?
미리 결정된 일정은 없습니다. 우리는 버그를 수정하고 고객을 차단 해제하기 위해 매우 정기적으로 서비스 릴리스를 게시하려고합니다. 주 릴리스는 일반적으로 더 오래 걸리며 주 버전의 일반 공급 전에 몇 가지 미리 보기 버전을 릴리스합니다.
MSAL 버전의 호환성 모델은 무엇인가요?
목표는 주 버전 내에서 이전 버전과의 호환성을 유지하는 것입니다. 이를 위해 버그만 수정하거나 서비스 릴리스에서 새로운 기능(부 버전 증가)을 추가하려고 합니다. 그러나 주 버전 간에는 호환성이 보장되지 않습니다. 특정 플랫폼 또는 시나리오에 대한 지원을 추가하거나 제거할 수 있으므로, 프로덕션 코드에서 전환하기 전에 변경 내용의 범위를 완전히 이해하고 새 버전을 완전히 테스트하는 것이 좋습니다.