다음을 통해 공유


단일 및 다중 테넌트 앱의 ID 및 계정 유형

이 문서에서는 개발자가 앱에서 Microsoft Entra 테넌트, Microsoft Entra 테넌트 또는 개인 Microsoft 계정을 가진 사용자만 허용할지 여부를 선택할 수 있는 방법을 설명합니다. Microsoft Entra에서 앱을 등록하는 동안 단일 테넌트 또는 다중 테넌트로 앱을 구성할 수 있습니다. 앱이 필요한 권한만 요청하도록 최소 권한 액세스의 제로 트러스트 원칙을 확인합니다.

이 Microsoft ID 플랫폼 특정 ID 형식에 대한 지원을 제공합니다.

Microsoft Entra ID의 애플리케이션 등록에 필요한 부분은 지원되는 계정 유형을 선택하는 것입니다. 관리자 역할의 IT 전문가는 테넌트에서 앱에 동의할 수 있는 사용자를 결정하지만 개발자는 계정 유형에 따라 앱을 사용할 수 있는 사용자를 지정합니다. 테넌트에서 Microsoft Entra ID에 애플리케이션을 등록할 수 없는 경우 관리자는 다른 메커니즘을 통해 이러한 세부 정보를 사용자에게 전달할 수 있는 방법을 제공합니다.

애플리케이션을 등록할 때 지원되는 다음 계정 유형 옵션 중에서 선택합니다.

  • Accounts in this organizational directory only (O365 only - Single tenant)
  • Accounts in any organizational directory (Any Azure AD directory - Multitenant)
  • Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
  • Personal Microsoft accounts only

이 조직 디렉터리의 계정만 - 단일 테넌트

이 조직 디렉터리에서만 계정을 선택하는 경우(O365 전용 - 단일 테넌트) 개발자가 앱을 등록한 테넌트에서 사용자 및 게스트만 허용합니다. 이 옵션은 LOB(기간 업무) 애플리케이션에 가장 일반적입니다.

모든 조직 디렉터리의 계정만 - 다중 테넌트

모든 조직 디렉터리(모든 Microsoft Entra 디렉터리 - 다중 테넌트)에서 계정을 선택하면 Microsoft Entra 디렉터리의 모든 사용자가 다중 테넌트 애플리케이션에 로그인할 수 있습니다. 특정 테넌트에서만 사용자를 허용하려면 id_token tid 클레임이 허용된 테넌트 목록에 있음을 검사 코드에서 이러한 사용자를 필터링합니다. 애플리케이션은 조직 엔드포인트 또는 공통 엔드포인트를 사용하여 사용자의 홈 테넌트에서 사용자를 로그인할 수 있습니다. 게스트 사용자가 다중 테넌트 앱에 로그인하도록 지원하려면 사용자가 게스트인 테넌트에 대해 특정 테넌트 엔드포인트를 사용하여 사용자를 로그인합니다.

모든 조직 계정 및 개인 Microsoft 계정의 계정

조직 계정 및 개인 Microsoft 계정(모든 Microsoft Entra 디렉터리 - 다중 테넌트) 및 개인 Microsoft 계정(예: Skype, Xbox)에서 계정을 선택하면 사용자가 Microsoft Entra 테넌트 또는 소비자 계정의 기본 ID로 애플리케이션에 로그인할 수 있습니다. 앞에서 설명한 대로 다중 테넌트 앱과 동일한 테넌트 필터링 및 엔드포인트 사용량이 이러한 앱에 적용됩니다.

개인 Microsoft 계정만

개인 Microsoft 계정만 선택하면 소비자 계정이 있는 사용자만 앱을 사용할 수 있습니다.

고객 연결 애플리케이션

고객에게 연락하는 Microsoft ID 플랫폼 솔루션을 빌드하는 경우 일반적으로 회사 디렉터리를 사용하지 않으려는 것입니다. 대신 고객이 회사의 회사 리소스에 액세스할 수 없도록 별도의 디렉터리에 있어야 합니다. 이러한 요구 사항을 충족하기 위해 Microsoft는 Microsoft Entra Business to Customer(B2C)를 제공합니다.

Azure AD B2C는 비즈니스-고객 ID를 서비스로 제공합니다. 사용자가 앱에 대한 사용자 이름과 암호를 갖도록 허용할 수 있습니다. B2C는 암호를 줄이기 위해 소셜 ID를 가진 고객을 지원합니다. Azure AD B2C 디렉터리를 고객의 Microsoft Entra ID 또는 SAML(Security Assertion Markup Language)을 지원하는 ID 공급자를 OpenID 커넥트 페더레이션하여 엔터프라이즈 고객을 지원할 수 있습니다. 다중 테넌트 앱과 달리 앱은 회사 자산을 보호하는 고객의 회사 디렉터리를 사용하지 않습니다. 고객은 회사 리소스에 대한 액세스 권한을 앱에 부여하지 않고도 서비스 또는 기능에 액세스할 수 있습니다.

개발자에게만 해당되지 않습니다.

애플리케이션 등록에서 앱에 로그인할 수 있는 사용자를 정의하는 동안 최종 말은 개별 사용자 또는 사용자의 홈 테넌트의 관리자로부터 나옵니다. 테넌트 관리자는 로그인할 수 있는 사용자보다 앱을 더 많이 제어하려고 하는 경우가 많습니다. 예를 들어 앱에 조건부 액세스 정책을 적용하거나 애플리케이션을 사용할 수 있는 그룹을 제어할 수 있습니다. 테넌트 관리자가 이 컨트롤을 사용하도록 설정하려면 Microsoft ID 플랫폼 엔터프라이즈 앱이라는 두 번째 개체가 있습니다. 엔터프라이즈 앱은 서비스 주체라고 도 합니다.

다른 테넌트 또는 다른 소비자 계정의 사용자가 있는 앱

다음 다이어그램에서 두 테넌트(가상 조직의 경우 Adatum 및 Contoso)의 예를 사용하는 것처럼 지원되는 계정 유형에는 조직 디렉터리 사용자를 허용할 수 있도록 다중 테넌트 애플리케이션에 대한 모든 조직 디렉터리 옵션의 계정이 포함됩니다. 즉, 사용자가 Microsoft Entra ID의 네이티브 ID를 사용하여 애플리케이션에 로그인할 수 있도록 허용합니다. 테넌트에서 처음 사용자가 앱에 인증하면 서비스 주체가 테넌트에 자동으로 만들어집니다.

다이어그램은 다중 테넌트 애플리케이션에서 조직 디렉터리 사용자를 허용하는 방법을 보여줍니다.

애플리케이션 등록 또는 애플리케이션 개체는 하나뿐입니다. 그러나 모든 테넌트에는 사용자가 앱에 로그인할 수 있는 엔터프라이즈 앱 또는 SP(서비스 주체)가 있습니다. 테넌트 관리자는 테넌트에서 앱이 작동하는 방식을 제어할 수 있습니다.

다중 테넌트 앱 고려 사항

다중 테넌트 앱은 앱이 공통 또는 조직 엔드포인트를 사용하는 경우 사용자의 홈 테넌트에서 사용자를 로그인합니다. 앱에는 다음 다이어그램과 같이 하나의 앱 등록이 있습니다. 이 예제에서는 애플리케이션이 Adatum 테넌트에 등록됩니다. Adatum의 사용자 A와 Contoso의 사용자 B는 Adatum의 사용자 A가 Adatum 데이터에 액세스하고 Contoso의 사용자 B가 Contoso 데이터에 액세스하는 것으로 예상하여 앱에 로그인할 수 있습니다.

다이어그램은 앱이 공통 또는 조직 엔드포인트를 사용하는 경우 다중 테넌트 앱이 사용자의 홈 테넌트에서 사용자를 로그인하는 방법을 보여줍니다.

개발자는 테넌트 정보를 별도로 유지해야 합니다. 예를 들어 Contoso 데이터가 Microsoft Graph에서 온 경우 Contoso의 사용자 B는 Contoso의 Microsoft Graph 데이터만 볼 수 있습니다. Contoso의 사용자 B가 Adatum 테넌트의 Microsoft Graph 데이터에 액세스할 가능성은 없습니다. Microsoft 365에는 실제 데이터 분리가 있기 때문입니다.

위의 다이어그램에서 Contoso의 사용자 B는 애플리케이션에 로그인할 수 있으며 애플리케이션의 Contoso 데이터에 액세스할 수 있습니다. 애플리케이션은 공통(또는 조직) 엔드포인트를 사용할 수 있으므로 사용자가 기본적으로 테넌트에 로그인하여 초대 프로세스가 필요하지 않습니다. 사용자는 애플리케이션을 실행하고 로그인할 수 있으며 사용자 또는 테넌트 관리자가 동의를 부여한 후에 작동합니다.

외부 사용자와의 공동 작업

엔터프라이즈에서 엔터프라이즈 구성원이 아닌 사용자가 엔터프라이즈의 데이터에 액세스할 수 있도록 하려는 경우 Microsoft Entra Business to Business(B2B) 기능을 사용합니다. 다음 다이어그램에 설명된 것처럼 엔터프라이즈는 사용자를 테넌트에서 게스트 사용자가 되도록 초대할 수 있습니다. 사용자가 초대를 수락하면 초대하는 테넌트가 보호하는 데이터에 액세스할 수 있습니다. 사용자는 테넌트에 별도의 자격 증명을 만들지 않습니다.

다이어그램은 기업이 게스트 사용자를 테넌트에 초대하는 방법을 보여줍니다.

게스트 사용자는 홈 테넌트, 개인 Microsoft 계정 또는 기타 IDP(ID 공급자) 계정에 로그인하여 인증합니다. 게스트는 전자 메일을 사용하여 일회성 암호로 인증할 수도 있습니다. 게스트가 인증한 후 초대하는 테넌트의 Microsoft Entra ID는 초대하는 테넌트의 데이터에 액세스하기 위한 토큰을 제공합니다.

개발자는 애플리케이션에서 게스트 사용자를 지원할 때 이러한 고려 사항을 염두에 두어야 합니다.

  • 게스트 사용자에 로그인할 때 테넌트별 엔드포인트를 사용해야 합니다. 공통, 조직 또는 소비자 엔드포인트는 사용할 수 없습니다.
  • 게스트 사용자 ID는 홈 테넌트 또는 다른 IDP의 사용자 ID와 다릅니다. oid 게스트 사용자에 대한 토큰의 클레임은 홈 테넌트에 있는 동일한 개인의 oid 클레임과 다릅니다.

다음 단계