다음을 통해 공유

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

  • 아티클

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

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

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

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

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

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

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

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

OAuth 권한 부여 프로토콜/기능 퍼블릭 클라이언트 애플리케이션 유형 예제/참고 사항
네이티브 인증 디자인 요소, 로고 배치 및 레이아웃을 포함하여 사용자 인터페이스를 완전히 사용자 지정해야 하는 애플리케이션을 Microsoft Entra 외부 ID 일관되고 브랜드화된 모양을 보장합니다. 참고: 네이티브 인증은 Microsoft Entra 외부 ID 테넌트에서 앱 등록에만 사용할 수 있습니다. 여기서 자세히 알아보세요.
디바이스 코드 흐름 스마트 TV, IoT 디바이스 또는 프린터와 같이 입력이 제한된 디바이스에서 실행되는 애플리케이션
리소스 소유자 암호 자격 증명 흐름 사용자가 Entra 호스팅 로그인 웹 사이트로 리디렉션하고 Entra가 사용자 암호를 안전하게 처리하도록 하는 대신 사용자가 직접 입력하는 암호를 처리하는 애플리케이션. ROPC 흐름을 사용하지 않는 것이 좋습니다. 대부분의 시나리오에서는 권한 부여 코드 흐름과 같은 보다 안전한 대안을 사용할 수 있으며 권장됩니다.
Windows 통합 인증 흐름 웹 계정 관리자 대신 Windows 통합 인증 흐름을 사용하여 Windows 또는 Windows 도메인에 연결된 컴퓨터(Microsoft Entra ID 또는 Microsoft Entra 조인됨)에서 실행되는 데스크톱 또는 모바일 애플리케이션 사용자가 Microsoft Entra 자격 증명으로 Windows PC 시스템에 로그인한 후 자동으로 로그인되어야 하는 데스크톱 또는 모바일 애플리케이션

비밀을 확인하고 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를 사용할 수 없는 경우 비밀을 확보하고 관련 보안 인시던트와 대응하기 위한 정책, 예방 조치 및 비상 사태가 있어야 합니다.

참고 항목

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