퍼블릭 클라이언트 및 기밀 클라이언트 응용 프로그램

MSAL(Microsoft 인증 라이브러리)은 퍼블릭 클라이언트와 기밀 클라이언트라는 두 가지 형식의 클라이언트를 정의합니다. 클라이언트는 ID 공급자가 할당한 고유 식별자가 있는 소프트웨어 엔터티입니다. 클라이언트 유형은 권한 부여 서버를 사용하여 안전하게 인증하고 중요한 ID 증명 정보를 보유하여 액세스 범위 내에서 사용자에게 액세스하거나 알 수 없도록 하는 기능으로 구분됩니다.

공용 클라이언트 앱	기밀 클라이언트 앱
데스크톱 앱	웹앱
브라우저리스 API	Web API
모바일 앱	서비스/디먼

공용 클라이언트 및 기밀 클라이언트 권한 부여

지정된 클라이언트의 공개 또는 기밀 특성을 검사할 때 해당 클라이언트가 권한 부여 서버에 대한 ID를 증명할 수 있는 능력을 평가하고 있습니다. 이는 권한 부여 서버가 액세스 토큰을 발급하기 위해 클라이언트의 ID를 신뢰할 수 있어야 하기 때문에 중요합니다.

• 공용 클라이언트 애플리케이션은 데스크톱, 브라우저 없는 API, 모바일 또는 클라이언트 쪽 브라우저 앱과 같은 디바이스에서 실행할 수 있습니다. 애플리케이션 비밀을 안전하게 유지하기 위해 신뢰할 수 없으므로 사용자를 대신하여 웹 API에만 액세스할 수 있습니다. 지정된 앱의 소스 또는 컴파일된 바이트 코드가 읽거나 디스어셈블되거나 신뢰할 수 없는 당사자가 검사할 수 있는 모든 위치에서 전송될 때마다 퍼블릭 클라이언트입니다. 또한 공용 클라이언트 흐름만 지원하고 구성 시간 비밀을 보유할 수 없으므로 클라이언트 비밀을 가질 수 없습니다.

• 기밀 클라이언트 애플리케이션은 웹앱, 웹 API 앱 또는 서비스/디먼 앱과 같은 서버에서 실행할 수 있습니다. 사용자 또는 공격자가 액세스하기 어렵기 때문에 구성 시간 비밀을 적절히 보유하여 ID 증명을 어설션할 수 있습니다. 클라이언트 ID는 웹 브라우저를 통해 노출되지만, 비밀은 백채널에서만 전달되고 직접 노출되지 않습니다.

언제 앱 등록에서 공용 클라이언트 흐름을 허용하도록 설정해야 하나요?

빌드하는 클라이언트 애플리케이션의 유형을 결정한 후 앱 등록에서 퍼블릭 클라이언트 흐름을 사용하도록 설정할지 여부를 결정할 수 있습니다. 기본적으로 사용자 또는 개발자가 공용 클라이언트 애플리케이션을 빌드하고 다음 OAuth 권한 부여 프로토콜 또는 기능을 사용하지 않는 한 앱 등록에서 공용 클라이언트 흐름을 사용하지 않도록 설정해야 합니다.

비밀을 확인하고 ID를 증명하는 것의 중요성

다음은 클라이언트가 권한 부여 서버에 대한 ID를 증명할 수 있는 방법의 몇 가지 예입니다.

• Azure 리소스에 대한 관리 ID – 앱 전용 인증 시나리오의 경우 Azure에서 빌드하는 애플리케이션 및 서비스 개발자는 비밀 관리, 회전 및 보호를 플랫폼 자체에 오프로드하는 옵션이 있습니다. 관리 ID를 사용하면 Azure 리소스를 사용하여 ID가 제공되고 삭제되며 전역 관리자를 포함한 누구도 기본 자격 증명에 액세스할 수 없습니다. 관리 ID를 사용하면 비밀 유출 위험을 방지하고 공급자가 보안을 처리하도록 할 수 있습니다.
• 클라이언트 ID 및 비밀 – 이 패턴에서는 클라이언트를 등록할 때 권한 부여 서버에서 값 쌍을 생성합니다. 클라이언트 ID는 애플리케이션을 식별하는 공용 값이지만 클라이언트 암호는 애플리케이션의 ID를 증명하는 데 사용되는 기밀 값입니다.
• 인증서 소유 증명 – PKI(공개 키 인프라)는(X.509 등과 같이 표준을 포함하는) 인터넷을 통한 보안 통신을 가능하게 하고 인터넷 개인 정보 보호의 중추를 형성하는 기본 기술입니다. PKI는 온라인 통신에 관련된 당사자의 ID를 확인하는 디지털 인증서를 발급하는 데 사용되며 웹 트래픽을 보호하는 데 널리 사용되는 HTTPS와 같은 프로토콜을 구동하는 기본 기술입니다. 마찬가지로 인증서를 사용하여 서비스 간에 상호 인증을 사용하도록 설정하여 Azure에서 S2S(서비스 간) 통신을 보호할 수 있습니다. 여기에는 각 서비스가 해당 ID를 증명하는 수단으로 서로 인증서를 제시하는 작업이 포함됩니다.
• 서명된 어설션 – 워크로드 ID 페더레이션에 사용됩니다. 서명된 어설션을 사용하여 Microsoft ID 플랫폼과 신뢰할 수 있는 타사 ID 공급자 토큰을 교환하여 Microsoft Entra 보호 리소스를 호출하는 액세스 토큰을 가져올 수 있습니다. 워크로드 ID 페더레이션을 사용하여 Azure Kubernetes Service, Amazon Web Services EKS, GitHub Actions 등을 비롯한 다양한 페더레이션 시나리오를 사용하도록 설정할 수 있습니다.

클라이언트 ID 증명은 언제 중요합니까?

중요한 데이터 또는 리소스에 대한 액세스 권한을 부여하기 전에 클라이언트 애플리케이션의 신뢰성과 권한 부여를 모두 확인해야 하는 경우 클라이언트 ID 증명이 중요합니다. 일부 사례:

• API 액세스 제어 – 요금제(예: 청구) 또는 중요한 데이터 또는 리소스를 노출하는 API가 있는 경우 액세스 권한을 부여하기 전에 클라이언트의 ID를 확인합니다. 예를 들어 이는 권한 있는 애플리케이션만 API에 액세스할 수 있도록 하고 데이터 통신 API 사용량에 대해 올바른 고객에게 요금이 청구되도록 하는 경우에 중요합니다.
• 앱 가장으로부터 사용자 보호 – 중요한 데이터 또는 서비스에 액세스하는 서비스 배포 사용자 연결 애플리케이션(예: 백 엔드 기반 웹앱)이 있는 경우 클라이언트 비밀을 사용하여 해당 애플리케이션에서 사용하는 리소스를 보호하면 악의적인 행위자가 합법적인 클라이언트를 피싱하여 데이터를 유출하거나 액세스를 남용하는 것을 방지할 수 있습니다.
• S2S 통신 – 서로 통신해야 하는 여러 백 엔드 서비스(예: 다운스트림 API)가 있는 경우 각 서비스의 ID를 확인하여 해당 기능을 수행하는 데 필요한 리소스에만 액세스할 수 있는 권한이 있는지 확인할 수 있습니다.

일반적으로 클라이언트 ID 증명은 사용자와 독립적으로 또는 사용자 외에 클라이언트를 인증하고 권한을 부여해야 하는 경우에 중요합니다.

기밀 클라이언트: 비밀 관리 모범 사례

관리 ID를 사용하여 배포 및 보안 – 관리 ID는 Microsoft Entra 인증을 지원하는 리소스에 연결할 때 사용할 애플리케이션에 대해 Microsoft Entra ID에 자동으로 관리 ID를 제공합니다. 애플리케이션은 관리 ID를 사용하여 자격 증명을 관리할 필요 없이 Microsoft Entra ID 앱 전용 토큰을 가져올 수 있습니다. 이렇게 하면 보안 및 복원력을 높이면서 비밀 관리와 관련된 많은 복잡성을 제거할 수 있습니다. 관리 ID를 사용하는 경우 대부분의 경우 다음 모범 사례가 모두 이미 처리되어 있지는 않습니다.

보안 스토리지 – Key Vault 또는 암호화된 구성 파일 같은 보안 위치에 클라이언트 비밀을 저장합니다. 일반 텍스트 또는 체크 인 파일로 버전 제어 시스템에 클라이언트 비밀을 저장하지 마세요.

액세스 제한 - 권한 있는 담당자만 클라이언트 비밀에 대한 액세스를 제한합니다. 역할 기반 액세스 제어를 사용하여 클라이언트 비밀에 대한 액세스를 운영 업무를 수행하는 데 필요한 사용자로만 제한합니다.

클라이언트 비밀 순환 – 필요에 따라 또는 예약된 기준에서 클라이언트 비밀 순환은 손상된 비밀이 무단 액세스를 얻는데 사용될 위험을 최소화 할 수 있습니다. 적용된 경우 키를 계속 사용하도록 제안하는 기간은 사용되는 암호화 알고리즘의 강도 및/또는 표준 또는 규정 준수 사례를 준수하는 데 영향을 받습니다.

긴 비밀 및 강한 암호화 사용 – 이전 지점과 긴밀하게 관계가 있습니다. 전송 중(유선) 및 미사용(디스크 에서)를 위한 강한 암호화 알고리즘을 사용하면 높은 엔트로피 비밀이 무차별 암호로 유지되지 않도록 할 수 있습니다. AES-128 이상과 같은 알고리즘은 미사용 데이터를 보호하는 데 도움이 될 수 있지만 RSA-2048 이상은 전송 중인 데이터를 효율적으로 보호하는 데 도움이 될 수 있습니다. 끊임없이 진화하는 사이버 보안 특성 때문에 보안 전문가와 상의하고 알고리즘 선택을 주기적으로 검토하는 것이 항상 모범 사례입니다.

비밀 하드 코딩 방지 – 원본 코드에서 클라이언트 비밀을 하드 코딩 하지 마세요. 소스 코드에서 비밀을 방지하면 소스 코드에 액세스하는 잘못된 행위자의 값을 최소화할 수 있습니다. 또한 이러한 비밀이 실수로 안전하지 않은 리포지토리로 푸시되거나 소스 액세스를 가질 수 있지만 비밀 액세스는 할 수 없는 프로젝트 기여자가 사용할 수 있게 되는 것을 방지할 수 있습니다.

유출된 비밀에 대한 리포지토리 모니터링 – 소스 코드를 처리할 때 잘못된 체크 인이 발생하는 것은 불행한 사실입니다. Git 사전 커밋 후크는 우발적인 체크 인을 방지하는 데 권장되는 방법이지만 모니터링 대신 사용할 수는 없습니다. 리포지토리의 자동화된 모니터링은 유출된 비밀을 식별할 수 있으며 손상된 자격 증명을 순환하는 계획을 통해 보안 인시던트를 줄이는 데 도움이 될 수 있습니다.

의심스러운 활동 모니터링 – 클라이언트 비밀과 관련한 의심스러운 활동 로그 및 감사 추적을 모니터링 합니다. 가능한 경우 자동화된 경고 및 응답 프로세스를 사용하여 직원에게 알리고 클라이언트 비밀과 관련된 비정상적인 활동에 대한 비상 사태를 정의합니다.

클라이언트 비밀을 염두해 두고 애플리케이션 설계 – 보안 모델은 가장 약한 링크 만큼만 강력합니다. 보안 자격 증명 또는 토큰을 기밀 클라이언트에서 공개 클라이언트로 전달하지 마세요. 이 경우 클라이언트 비밀 데이터를 공용 클라이언트로 이동하여 기밀 클라이언트를 가장할 수 있습니다.

신뢰할 수 있는 원본의 최신 라이브러리 및 SDK 사용 – Microsoft ID 플랫폼은 애플리케이션을 안전하게 유지하면서 생산성을 높이도록 설계된 다양한 클라이언트 및 서버 SDK 및 미들웨어를 제공합니다. Microsoft.Identity.Web 같은 라이브러리는 Microsoft ID 플랫폼의 웹앱 및 API에 인증 및 권한 부여를 추가하는 작업을 간소화합니다. 종속성을 업데이트된 상태로 유지하면 애플리케이션 및 서비스가 최신 보안 혁신 및 업데이트를 활용할 수 있습니다.

클라이언트 유형 및 해당 기능 비교

다음은 공용 클라이언트 앱과 기밀 클라이언트 앱 간의 몇 가지 유사점과 차이점입니다.

• 두 앱 유형 모두 사용자 토큰 캐시를 유지하고 토큰을 자동으로 획득할 수 있습니다(토큰이 캐시에 있는 경우). 기밀 클라이언트 앱에는 앱 자체에서 획득한 토큰에 대한 앱 토큰 캐시도 있습니다.
• 두 앱 유형 모두 사용자 계정을 관리하고 사용자 토큰 캐시에서 계정을 가져오거나, 식별자에서 계정을 가져오거나, 계정을 제거할 수 있습니다.
• MSAL에서 퍼블릭 클라이언트 앱에는 별도의 인증 흐름을 통해 토큰을 획득하는 네 가지 방법이 있습니다. 기밀 클라이언트 앱에는 토큰을 획득하는 세 가지 방법과 ID 공급자 권한 엔드포인트의 URL을 계산하는 한 가지 방법이 있습니다. 클라이언트 ID는 애플리케이션 생성 시 한 번 전달되며 앱이 토큰을 획득할 때 다시 전달할 필요가 없습니다. 자세한 내용은 토큰 획득을 참조하세요.

공용 클라이언트는 보호된 리소스에 대한 사용자 위임 액세스를 사용하도록 설정하는 데 유용하지만 자체 애플리케이션 ID를 증명할 수는 없습니다. 반면 기밀 클라이언트는 사용자 및 애플리케이션 인증 및 권한 부여를 모두 수행할 수 있으며, 비밀을 공용 클라이언트 또는 다른 타사와 공유하지 않도록 보안을 염두에 두고 빌드해야 합니다.

S2S 통신과 같은 일부 경우 관리 ID와 같은 인프라는 서비스의 개발 및 배포를 간소화하는 데 크게 도움이 되며 일반적으로 비밀 관리와 관련된 복잡성을 많이 제거합니다. 관리 ID를 사용할 수 없는 경우 비밀을 확보하고 관련 보안 인시던트와 대응하기 위한 정책, 예방 조치 및 비상 사태가 있어야 합니다.

참고 항목

애플리케이션 구성 및 인스턴스화에 대한 자세한 내용은 다음을 참조하세요.

• 클라이언트 응용 프로그램 구성 옵션
• MSAL.NET을 사용하여 클라이언트 응용 프로그램 인스턴스화
• MSAL.js를 사용하여 클라이언트 응용 프로그램 인스턴스화