Active Directory B2C에서 사용할 수 있는 애플리케이션 유형

Azure AD B2C(Azure Active Directory B2C)는 다양한 최신 애플리케이션 아키텍처에 대한 인증을 지원합니다. 모두 업계 표준 프로토콜 OAuth 2.0 또는 OpenID Connect를 기반으로 합니다. 이 문서에서는 원하는 언어 또는 플랫폼에 관계없이 빌드할 수 있는 애플리케이션 유형을 설명합니다. 또한 애플리케이션 빌드를 시작하기 전에 개략적인 시나리오를 이해하는 데 도움이 됩니다.

Azure AD B2C를 사용하는 모든 애플리케이션은 Azure Portal을 사용하여 Azure AD B2C 테넌트에 등록해야 합니다. 애플리케이션 등록 프로세스는 다음과 같은 값을 수집하고 할당합니다.

• 애플리케이션을 고유하게 식별하는 애플리케이션 ID 입니다.
• 응답을 애플리케이션으로 다시 전송하는 데 사용할 수 있는 회신 URL 입니다.

Azure AD B2C로 전송되는 각 요청은 Azure AD B2C의 동작을 제어하는 사용자 흐름 (기본 제공 정책) 또는 사용자 지정 정책을 지정합니다. 두 정책 유형 모두 사용자 지정이 가능한 사용자 환경 집합을 만들 수 있습니다.

모든 애플리케이션의 상호 작용은 비슷한 상위 수준 패턴을 따릅니다.

1. 애플리케이션은 정책을 실행하기 위해 사용자를 v2.0 엔드포인트로 안내합니다.
2. 사용자가 정책 정의에 따라 정책을 완료합니다.
3. 애플리케이션은 v2.0 엔드포인트에서 보안 토큰을 받습니다.
4. 애플리케이션은 보안 토큰을 사용하여 보호된 정보 또는 보호된 리소스에 액세스합니다.
5. 리소스 서버는 보안 토큰의 유효성을 검사하여 액세스 권한을 부여할 수 있는지 확인합니다.
6. 애플리케이션은 정기적으로 보안 토큰을 새로 고칩니다.

이러한 단계는 빌드하는 애플리케이션 유형에 따라 약간 다를 수 있습니다.

웹 애플리케이션

웹 서버에서 호스트되고 브라우저를 통해 액세스되는 웹 애플리케이션(.NET, PHP, Java, Ruby, Python 및 Node.js포함)의 경우 Azure AD B2C는 모든 사용자 환경에 대해 OpenID Connect 를 지원합니다. OpenID Connect의 Azure AD B2C 구현에서 웹 애플리케이션은 Microsoft Entra ID에 인증 요청을 발급하여 사용자 환경을 시작합니다. 요청의 결과는 . id_token입니다. 이 보안 토큰은 사용자의 ID를 나타냅니다. 또한 클레임 형식으로 사용자에 대한 정보를 제공합니다.

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Azure AD B2C 토큰 참조에서 애플리케이션에서 사용할 수 있는 토큰 및 클레임 유형에 대해 자세히 알아봅니다.

웹 애플리케이션에서 정책 의 각 실행은 다음과 같은 개략적인 단계를 수행합니다.

1. 사용자가 웹 애플리케이션을 찾습니다.
2. 웹 애플리케이션은 사용자를 실행할 정책을 나타내는 Azure AD B2C로 리디렉션합니다.
3. 사용자가 정책을 완료합니다.
4. Azure AD B2C는 브라우저에 id_token 반환합니다.
5. 리디렉션 URI에 id_token가 게시됩니다.
6. id_token 유효성이 검사되고 세션 쿠키가 설정됩니다.
7. 보안 페이지가 사용자에게 반환됩니다.

id_token Microsoft Entra ID에서 받은 공개 서명 키를 사용하여 유효성을 검사하면 사용자의 ID를 확인할 수 있습니다. 또한 이 프로세스는 후속 페이지 요청에서 사용자를 식별하는 데 사용할 수 있는 세션 쿠키를 설정합니다.

이 시나리오의 작동을 확인하려면 시작 섹션에서 웹 애플리케이션 로그인 코드 샘플 중 하나를 사용해 보세요.

간단한 로그인을 용이하게 하는 것 외에도 웹 애플리케이션은 백 엔드 웹 서비스에 액세스해야 할 수도 있습니다. 이 경우 웹 애플리케이션은 권한 부여 코드 및 새로 고침 토큰을 사용하여 약간 다른 OpenID Connect 흐름을 수행하고 토큰을 획득할 수 있습니다. 이 시나리오는 다음 Web API 섹션에 설명되어 있습니다.

단일 페이지 애플리케이션

많은 최신 웹 애플리케이션은 클라이언트 쪽 단일 페이지 애플리케이션("SPA")으로 빌드됩니다. 개발자는 JavaScript 또는 SPA 프레임워크(예: Angular, Vue 또는 React)를 사용하여 작성합니다. 이러한 애플리케이션은 웹 브라우저에서 실행되며 기존 서버 쪽 웹 애플리케이션과 다른 인증 특성을 갖습니다.

Azure AD B2C는 단일 페이지 애플리케이션이 사용자를 로그인하고 토큰을 가져와 백 엔드 서비스 또는 웹 API에 액세스할 수 있도록 하는 두 가지 옵션을 제공합니다.

권한 부여 코드 흐름(PKCE 사용)

OAuth 2.0 권한 부여 코드 흐름(PKCE 포함)을 사용하면 애플리케이션이 인증된 사용자 및 보호된 API를 호출하는 데 필요한 액세스 토큰을 나타내기 위해 ID 토큰에 대한 권한 부여 코드를 교환할 수 있습니다. 또한 해당 사용자와의 상호 작용 없이 사용자를 대신하여 리소스에 대한 장기 액세스를 제공하는 새로 고침 토큰을 반환합니다.

이 방법을 사용하는 것이 좋습니다 . 수명이 제한된 새로 고침 토큰을 사용하면 애플리케이션이 Safari ITP와 같은 최신 브라우저 쿠키 개인 정보 제한 사항에 적응할 수 있습니다.

이 흐름을 활용하기 위해 애플리케이션은 MSAL.js 2.x와 같이 이를 지원하는 인증 라이브러리를 사용할 수 있습니다.

암시적 권한 부여 흐름

MSAL.js 1.x와 같은 일부 라이브러리는 암시적 허용 흐름만 지원하거나 암시적 흐름을 사용하도록 애플리케이션이 구현됩니다. 이러한 경우 Azure AD B2C는 OAuth 2.0 암시적 흐름을 지원합니다. 암시적 권한 부여 흐름을 사용하면 애플리케이션에서 ID 및 액세스 토큰을 가져올 수 있습니다. 권한 부여 코드 흐름과 달리 암시적 권한 부여 흐름은 새로 고침 토큰을 반환하지 않습니다.

이 인증 흐름에는 Electron 및 React-Native와 같은 플랫폼 간 JavaScript 프레임워크를 사용하는 애플리케이션 시나리오가 포함되지 않습니다. 이러한 시나리오에는 네이티브 플랫폼과의 상호 작용을 위한 추가 기능이 필요합니다.

웹 API들

Azure AD B2C를 사용하여 애플리케이션의 RESTful 웹 API와 같은 웹 서비스를 보호할 수 있습니다. 웹 API는 토큰을 사용하여 들어오는 HTTP 요청을 인증하여 OAuth 2.0을 사용하여 데이터를 보호할 수 있습니다. 웹 API의 호출자는 HTTP 요청의 권한 부여 헤더에 토큰을 추가합니다.

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

그런 다음 웹 API는 토큰을 사용하여 API 호출자의 ID를 확인하고 토큰에 인코딩된 클레임에서 호출자에 대한 정보를 추출할 수 있습니다. Azure AD B2C 토큰 참조에서 앱에서 사용할 수 있는 토큰 및 클레임 유형에 대해 자세히 알아봅니다.

웹 API는 웹 애플리케이션, 데스크톱 및 모바일 애플리케이션, 단일 페이지 애플리케이션, 서버 쪽 디먼 및 기타 웹 API를 비롯한 다양한 유형의 클라이언트에서 토큰을 받을 수 있습니다. 다음은 웹 API를 호출하는 웹 애플리케이션에 대한 전체 흐름의 예입니다.

1. 웹 애플리케이션은 정책을 실행하고 사용자는 사용자 환경을 완료합니다.
2. Azure AD B2C는 (OpenID Connect) id_token 및 권한 부여 코드를 브라우저에 반환합니다.
3. 브라우저는 리디렉션 URI에 id_token 권한 부여 코드를 게시합니다.
4. 웹 서버는 세션 쿠키의 유효성을 id_token 검사하고 설정합니다.
5. 웹 서버는 Azure AD B2C에 access_token 권한 부여 코드, 애플리케이션 클라이언트 ID 및 클라이언트 자격 증명을 제공하여 요청합니다.
6. 및 access_tokenrefresh_token 웹 서버로 반환됩니다.
7. 웹 API는 권한 부여 헤더에서 access_token 호출됩니다.
8. 웹 API는 토큰의 유효성을 검사합니다.
9. 보안 데이터는 웹 애플리케이션에 반환됩니다.

권한 부여 코드, 새로 고침 토큰 및 토큰 가져오기 단계에 대해 자세히 알아보려면 OAuth 2.0 프로토콜에 대해 읽어보세요.

Azure AD B2C를 사용하여 웹 API를 보호하는 방법을 알아보려면 시작 섹션에서 웹 API 자습서를 확인하세요.

모바일 및 네이티브 애플리케이션

모바일 및 데스크톱 애플리케이션과 같은 디바이스에 설치된 애플리케이션은 종종 사용자를 대신하여 백 엔드 서비스 또는 웹 API에 액세스해야 합니다. 사용자 지정된 ID 관리 환경을 네이티브 애플리케이션에 추가하고 Azure AD B2C 및 OAuth 2.0 권한 부여 코드 흐름을 사용하여 백 엔드 서비스를 안전하게 호출할 수 있습니다.

이 흐름에서 애플리케이션은 정책을 실행하고 사용자가 정책을 완료한 authorization_code 후 Microsoft Entra ID에서 수신합니다. 현재 authorization_code 로그인한 사용자를 대신하여 백 엔드 서비스를 호출할 수 있는 애플리케이션의 권한을 나타냅니다. 그런 다음 애플리케이션은 백그라운드에서 a 및 authorization_codea를 교환 access_token 할 refresh_token 수 있습니다. 애플리케이션은 HTTP 요청에서 access_token 백 엔드 웹 API에 인증하는 데 사용할 수 있습니다. 또한 이전 버전이 refresh_token 만료되면 새 access_token 항목을 가져오는 데 사용할 수 있습니다.

디먼/서버 쪽 애플리케이션

장기 실행 프로세스를 포함하거나 사용자가 없는 상태에서 작동하는 애플리케이션도 웹 API와 같은 보안 리소스에 액세스할 수 있는 방법이 필요합니다. 이러한 애플리케이션은 사용자의 위임된 ID가 아닌 ID를 사용하고 OAuth 2.0 클라이언트 자격 증명 흐름을 사용하여 토큰을 인증하고 가져올 수 있습니다. 클라이언트 자격 증명 흐름은 on-behalf-flow와 동일하지 않으며 서버 간 인증에는 on-behalf-flow를 사용하면 안 됩니다.

Azure AD B2C의 경우 OAuth 2.0 클라이언트 자격 증명 흐름 은 현재 공개 미리 보기로 제공됩니다. 그러나 Microsoft Graph 애플리케이션 또는 사용자 고유/token에 대해 Microsoft Entra ID 및 Microsoft ID 플랫폼 https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token 엔드포인트()를 사용하여 클라이언트 자격 증명 흐름을 설정할 수 있습니다. 자세한 내용은 Microsoft Entra 토큰 참조 문서를 참조하세요.

지원되지 않는 애플리케이션 유형

Web API 체인(On-Behalf-of 흐름)

많은 아키텍처에는 다른 다운스트림 웹 API를 호출해야 하는 웹 API가 포함되며, 둘 다 Azure AD B2C로 보호됩니다. 이 시나리오는 Web API 백 엔드가 있고 Microsoft Graph API와 같은 Microsoft 온라인 서비스를 호출하는 네이티브 클라이언트에서 일반적입니다.

이 연결된 웹 API 시나리오는 OAuth 2.0 JWT 전달자 자격 증명 부여(on-behalf-of 흐름이라고도 함)를 사용하여 지원될 수 있습니다. 그러나 On-Behalf-of 흐름은 현재 Azure AD B2C에서 구현되지 않습니다.

다음 단계

Azure Active Directory B2C에서 사용자 흐름에서 제공하는 기본 제공 정책에 대해 자세히 알아봅니다.