v1.0의 애플리케이션 유형

Azure AD(Azure Active Directory)는 산업 표준 프로토콜 OAuth 2.0 또는 OpenID Connect를 기반으로 하는 다양한 최신 앱 아키텍처에 대한 인증을 지원합니다.

다음 다이어그램에서는 시나리오 및 애플리케이션 유형과 다양한 구성 요소를 추가할 수 있는 방법을 보여 줍니다.

다음은 Azure AD에서 지원하는 5가지 기본 애플리케이션 시나리오입니다.

• SPA(단일 페이지 애플리케이션) : 사용자가 Azure AD로 보호되는 단일 페이지 애플리케이션에 로그인해야 합니다.
• 웹 브라우저에서 웹 애플리케이션으로: 사용자는 Azure AD로 보호되는 웹 애플리케이션에 로그인해야 합니다.
• 네이티브 애플리케이션-웹 API: 휴대폰, 태블릿 또는 PC에서 실행되는 네이티브 애플리케이션은 Azure AD로 보호되는 웹 API에서 리소스를 가져오기 위해 사용자를 인증해야 합니다.
• 웹 애플리케이션-웹 API: 웹 애플리케이션은 Azure AD로 보호되는 웹 API에서 리소스를 가져와야 합니다.
• 디먼 또는 서버 애플리케이션-웹 API: 디먼 애플리케이션 또는 웹 사용자 인터페이스가 없는 서버 애플리케이션은 Azure AD로 보호되는 웹 API에서 리소스를 가져와야 합니다.

링크를 따라 각 앱 유형에 대해 자세히 알아보고 코드 작업을 시작하기 전에 상위 수준 시나리오를 이해합니다. v1.0 엔드포인트 또는 v2.0 엔드포인트에서 작동하는 특정 앱을 작성할 때 알아야 할 차이점에 대해 알아볼 수도 있습니다.

다양한 언어 및 플랫폼을 사용하여 여기에 설명된 앱 및 시나리오를 개발할 수 있습니다. 이러한 샘플은 모두 코드 샘플 가이드에서 사용할 수 있는 전체 코드 샘플( 시나리오별 v1.0 코드 샘플 및 시나리오별 v2.0 코드 샘플)에 의해 지원됩니다. 해당 GitHub 샘플 리포지토리에서 직접 코드 샘플을 다운로드할 수도 있습니다.

또한 애플리케이션에 엔드 투 엔드 시나리오의 특정 부분 또는 세그먼트가 필요한 경우 대부분의 경우 해당 기능을 독립적으로 추가할 수 있습니다. 예를 들어 웹 API를 호출하는 네이티브 애플리케이션이 있는 경우 웹 API를 호출하는 웹 애플리케이션을 쉽게 추가할 수 있습니다.

앱 등록

Azure AD v1.0 엔드포인트를 사용하는 앱 등록

Azure AD에 인증을 아웃소싱하는 모든 애플리케이션은 디렉터리에 등록되어야 합니다. 이 단계에서는 애플리케이션이 있는 URL, 인증 후 회신을 보낼 URL, 애플리케이션을 식별하는 URI 등을 포함하여 애플리케이션에 대해 Azure AD에 알려야 합니다. 이 정보는 몇 가지 주요 이유로 필요합니다.

• Azure AD는 로그온을 처리하거나 토큰을 교환할 때 애플리케이션과 통신해야 합니다. Azure AD와 애플리케이션 간에 전달되는 정보에는 다음이 포함됩니다.

  • 애플리케이션 ID URI - 애플리케이션의 식별자입니다. 이 값은 인증 중에 Azure AD로 전송되어 호출자가 토큰을 원하는 애플리케이션을 나타냅니다. 또한 이 값은 애플리케이션이 의도한 대상임을 알 수 있도록 토큰에 포함됩니다.
  • 회신 URL 및 리디렉션 URI - 웹 API 또는 웹 애플리케이션의 경우 회신 URL은 인증에 성공한 경우 토큰을 포함하여 Azure AD가 인증 응답을 보내는 위치입니다. 네이티브 애플리케이션의 경우 리디렉션 URI는 Azure AD가 OAuth 2.0 요청에서 사용자 에이전트를 리디렉션하는 고유 식별자입니다.
  • 애플리케이션 ID - 애플리케이션이 등록될 때 Azure AD에서 생성되는 애플리케이션의 ID입니다. 인증 코드 또는 토큰을 요청할 때 인증 중에 애플리케이션 ID 및 키가 Azure AD로 전송됩니다.
  • 키 - 웹 API를 호출하기 위해 Azure AD에 인증할 때 애플리케이션 ID와 함께 전송되는 키입니다.

• Azure AD는 애플리케이션에 디렉터리 데이터, 조직의 다른 애플리케이션 등에 액세스하는 데 필요한 권한이 있는지 확인해야 합니다.

자세한 내용은 앱을 등록하는 방법을 알아봅니다.

단일 테넌트 및 다중 테넌트 앱

Azure AD와 개발 및 통합할 수 있는 두 가지 애플리케이션 범주가 있다는 것을 이해하면 프로비저닝이 더 명확해집니다.

• 단일 테넌트 애플리케이션 - 단일 테넌트 애플리케이션은 한 조직에서 사용하기 위한 것입니다. 일반적으로 엔터프라이즈 개발자가 작성한 LoB(기간 업무) 애플리케이션입니다. 단일 테넌트 애플리케이션은 한 디렉터리의 사용자만 액세스할 수 있어야 하며, 따라서 하나의 디렉터리에서만 프로비전되어야 합니다. 이러한 애플리케이션은 일반적으로 조직의 개발자가 등록합니다.
• 다중 테넌트 애플리케이션 - 다중 테넌트 애플리케이션은 하나의 조직뿐만 아니라 많은 조직에서 사용하기 위한 것입니다. 일반적으로 ISV(Independent Software Vendor)가 작성한 SaaS(Software-as-a-Service) 애플리케이션이 이에 해당합니다. 다중 테넌트 애플리케이션을 사용할 각 디렉터리에 프로비전해야 하며, 이를 등록하려면 사용자 또는 관리자의 동의가 필요합니다. 이러한 동의 프로세스는 애플리케이션이 디렉터리에 등록되고 Graph API 또는 다른 웹 API에 대한 액세스 권한이 제공되면 시작됩니다. 다른 조직의 사용자 또는 관리자가 애플리케이션을 사용하기 위해 등록하면 애플리케이션에 필요한 권한을 표시하는 대화 상자가 표시됩니다. 그러면 사용자 또는 관리자가 애플리케이션에 동의하여 애플리케이션에 명시된 데이터에 대한 액세스 권한을 부여하고 마지막으로 해당 디렉터리에 애플리케이션을 등록할 수 있습니다. 자세한 내용은 동의 프레임워크 개요를 참조하세요.

단일 테넌트 또는 다중 테넌트 앱을 개발할 때 추가 고려 사항

단일 테넌트 애플리케이션 대신 다중 테넌트 애플리케이션을 개발할 때 몇 가지 추가 고려 사항이 발생합니다. 예를 들어 여러 디렉터리의 사용자가 애플리케이션을 사용할 수 있도록 하는 경우 해당 사용자가 있는 테넌트를 결정하는 메커니즘이 필요합니다. 단일 테넌트 애플리케이션은 사용자에 대한 자체 디렉터리에서만 확인해야 하며, 다중 테넌트 애플리케이션은 Azure AD의 모든 디렉터리에서 특정 사용자를 식별해야 합니다. 이 작업을 수행하기 위해 Azure AD는 모든 다중 테넌트 애플리케이션이 테넌트별 엔드포인트 대신 로그인 요청을 직접 보낼 수 있는 공통 인증 엔드포인트를 제공합니다. 이 엔드포인트는 Azure AD의 모든 디렉터리에 대해 https://login.microsoftonline.com/common입니다. 반면, 테넌트별 엔드포인트는 https://login.microsoftonline.com/contoso.onmicrosoft.com일 수 있습니다. 로그인, 로그아웃 및 토큰 유효성 검사 중에 여러 테넌트 처리에 필요한 논리가 필요하기 때문에 애플리케이션을 개발할 때 공통 엔드포인트를 고려해야 합니다.

현재 단일 테넌트 애플리케이션을 개발 중이지만 많은 조직에서 사용할 수 있도록 하려는 경우 Azure AD에서 애플리케이션 및 해당 구성을 쉽게 변경하여 다중 테넌트를 가능하게 만들 수 있습니다. 또한 Azure AD는 단일 테넌트 또는 다중 테넌트 애플리케이션에서 인증을 제공하는지 여부에 관계없이 모든 디렉터리에 있는 모든 토큰에 동일한 서명 키를 사용합니다.

이 문서에 나열된 각 시나리오에는 프로비전 요구 사항을 설명하는 하위 섹션이 포함되어 있습니다. Azure AD에서 애플리케이션을 프로비전하는 방법과 단일 및 다중 테넌트 애플리케이션 간의 차이점에 대한 자세한 내용은 Azure Active Directory와 애플리케이션 통합을 참조하세요. Azure AD의 일반적인 애플리케이션 시나리오를 이해하려면 계속 읽어 보세요.

다음 단계

• 다른 Azure AD 인증 기본 사항에 대해 자세히 알아보기