Azure Active Directory B2C에서 OAuth 2.0 암시적 흐름을 사용하여 단일 페이지 애플리케이션 로그인
대부분의 최신 애플리케이션에는 주로 JavaScript로 작성되는 SPA(단일 페이지 앱) 프런트엔드가 있습니다. 앱은 종종 React, Angular 또는 Vue.js과 같은 프레임워크를 사용하여 작성됩니다. 주로 브라우저에서 실행되는 SPA 및 기타 JavaScript 앱에는 인증에 대한 몇 가지 추가 과제가 있습니다.
이러한 앱의 보안적인 특성은 기존의 서버 기반 웹 애플리케이션과 차이가 있습니다.
많은 권한 부여 서버 및 ID 공급자에서 CORS(원본 간 리소스 공유) 요청을 지원하지 않습니다.
앱에서 전체 페이지 브라우저를 리디렉션하면 사용자 환경에 침투할 수 있습니다.
SPA를 지원하기 위해 권장되는 방법은 PKCE를 사용하는 OAuth 2.0 인증 코드 흐름입니다.
MSAL.js 1.x 같은 일부 프레임워크는 암시적 권한 부여 흐름만 지원합니다. 이러한 경우 Azure AD B2C(Azure Active Directory B2C)는 OAuth 2.0 권한 부여 암시적 부여 흐름을 지원합니다. 흐름은 OAuth 2.0 사양의 섹션 4.2에 설명되어 있습니다. 암시적 흐름에서 앱은 서버 간 교환 없이 Azure AD B2C 인증 엔드포인트에서 직접 토큰을 받습니다. 모든 인증 논리 및 세션 처리는 페이지 리디렉션 또는 팝업 상자를 사용하여 JavaScript 클라이언트에서 전적으로 수행됩니다.
Azure AD B2C는 표준 OAuth 2.0 암시적 흐름을 확장하여 단순한 인증 및 권한 부여보다 더 많은 작업을 수행합니다. Azure AD B2C는 정책 매개 변수를 도입했습니다. 정책 매개 변수를 사용하면 OAuth 2.0을 통해 가입, 로그인 및 프로필 관리 사용자 흐름과 같은 정책을 앱에 추가할 수 있습니다. 이 문서의 HTTP 요청 예에서는 {tenant}.onmicrosoft.com이 예로 사용되었습니다. 테넌트가 있는 경우 {tenant}를 해당 테넌트의 이름으로 바꿉니다. 또한 사용자 흐름이 생성되어 있어야 합니다.
다음 그림은 암시적 로그인 흐름을 보여 줍니다. 각 단계는 이 문서의 뒷부분에서 자세히 설명합니다.
인증 요청 보내기
웹 애플리케이션이 사용자를 인증하고 사용자 흐름을 실행해야 하는 경우 사용자를 Azure AD B2C의 /authorize 엔드포인트로 보냅니다. 사용자가 사용자 흐름에 따라 동작을 수행합니다.
이 요청에서 클라이언트는 실행하기 위해 scope 매개 변수 및 사용자 흐름에서 사용자로부터 가져와야 할 사용 권한을 나타냅니다. 요청의 작동 방식에 대해 이해하려면 요청을 브라우저에 붙여 넣고 실행합니다. 다음을
{tenant}를 Azure AD B2C 테넌트의 이름으로 바꿉니다.90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6을 테넌트에 등록해 두었던 애플리케이션의 앱 ID로 바꿉니다.{policy}를 테넌트에서 만든 정책 이름으로 바꿉니다(예:b2c_1_sign_in).
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
HTTP GET 요청의 매개 변수는 아래 표에 설명되어 있습니다.
| 매개 변수 | 필수 | 설명 |
|---|---|---|
| {tenant} | 예 | Azure AD B2C 테넌트의 이름 |
| {policy} | 예 | 실행하려는 사용자 흐름의 이름입니다. Azure AD B2C 테넌트에서 만든 사용자 흐름의 이름을 지정합니다. 예: b2c_1_sign_in, b2c_1_sign_up 또는 b2c_1_edit_profile. |
| client_id | 예 | Azure Portal이 애플리케이션에 할당한 애플리케이션 ID입니다. |
| response_type | 예 | OpenID Connect 로그인을 위한 id_token이 포함되어야 합니다. 응답 유형 token을 포함할 수도 있습니다. token을 사용하면 앱에서 권한 부여 엔드포인트에 대한 두 번째 요청을 수행하지 않고도 권한 부여 엔드포인트에서 액세스 토큰을 즉시 받을 수 있습니다. token 응답 형식을 사용하는 경우 scope 매개 변수에는 토큰을 발급할 리소스를 나타내는 범위가 포함되어야 합니다. |
| redirect_uri | 아니요 | 앱이 인증 응답을 보내고 받을 수 있는 앱의 리디렉션 URI입니다. URL로 인코드되어야 한다는 점을 제외하고 포털에서 등록한 애플리케이션에 추가한 리디렉션 URI 중 하나와 정확히 일치해야 합니다. |
| response_mode | 아니요 | 결과 토큰을 앱으로 다시 보내는 데 사용할 메서드를 지정합니다. 암시적 흐름의 경우 fragment를 사용합니다. |
| scope | 예 | 공백으로 구분된 범위 목록입니다. 단일 범위 값은 요청 중인 두 가지 권한을 모두 Microsoft Entra ID에 나타냅니다. openid 범위는 사용자에게 로그인하고 ID 토큰 형식으로 사용자에 대한 데이터를 가져올 권한을 나타냅니다. offline_access 범위는 웹앱에 대한 선택 사항입니다. 리소스에 장기간 액세스하기 위한 새로 고침 토큰이 앱에 필요함을 나타냅니다. |
| state | 아니요 | 또한 토큰 응답에 반환되는 요청에 포함된 값입니다. 사용하려는 콘텐츠의 문자열일 수 있습니다. 일반적으로 교차 사이트 요청 위조 공격을 방지하기 위해 임의로 생성된 고유 값이 사용됩니다. 상태는 인증 요청이 발생하기 전 앱의 사용자 상태에 대한 정보(예: 사용자가 있었던 페이지 또는 실행된 사용자 흐름)를 인코드하는 데에도 사용됩니다. |
| nonce | 예 | 앱에서 생성한 요청에 포함된 값이며, 결과 ID 토큰에 클레임으로 포함됩니다. 그러면 앱에서 이 값을 확인하여 토큰 재생 공격을 완화할 수 있습니다. 값은 일반적으로 요청의 출처를 식별하는 데 사용할 수 있는 임의의 고유 문자열입니다. |
| prompt | 아니요 | 필요한 사용자 상호 작용의 형식입니다. 현재 유효한 값은 login뿐이며, 이 매개 변수는 사용자가 해당 요청에 대한 자격 증명을 입력하도록 합니다. Single Sign-On은 적용되지 않습니다. |
이는 흐름의 대화형 부분입니다. 사용자가 정책의 워크플로를 완료해야 합니다. 사용자는 사용자 이름 및 암호를 입력하거나, 소셜 ID로 로그인하거나, 로컬 계정에 가입하는 등 특정한 단계를 수행해야 할 수 있습니다. 사용자 작업은 사용자 흐름을 정의한 방식에 따라 다릅니다.
사용자가 사용자 흐름을 완료하면 Azure AD B2C에서 앱에 대한 응답을 redirect_uri를 통해 반환합니다. response_mode 매개 변수에 지정된 메서드를 사용합니다. 실행된 사용자 흐름과 관계 없이 사용자 작업 시나리오 각각에 대한 응답은 정확히 동일합니다.
성공적인 응답
response_mode=fragment 및 response_type=id_token+token을 사용하는 성공적인 응답은 다음과 같으며, 쉽게 읽을 수 있도록 줄 바꿈이 적용되었습니다.
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
| 매개 변수 | 설명 |
|---|---|
| access_token | 앱이 Azure AD B2C에서 요청한 액세스 토큰입니다. |
| token_type | 토큰 형식 값입니다. Azure AD B2C는 전달자유형만 지원합니다. |
| expires_in | 액세스 토큰이 유효한 시간(초)입니다. |
| scope | 토큰이 유효한 범위입니다. 또한 나중에 사용할 수 있도록 범위를 사용하여 토큰을 캐시할 수도 있습니다. |
| id_token | 앱이 요청한 ID 토큰입니다. ID 토큰을 사용하여 사용자 ID를 확인하고 사용자와 세션을 시작할 수 있습니다. ID 토큰 및 해당 내용에 대한 자세한 내용은 Azure AD B2C 토큰 참조를 참조하세요. |
| state | state 매개 변수가 요청에 포함된 경우 동일한 값이 응답에 표시됩니다. 앱에서 요청 및 응답의 state 값이 동일한지 확인해야 합니다. |
오류 응답
오류 응답은 앱에서 적절히 처리할 수 있도록 리디렉션 URI에 보낼 수도 있습니다.
GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response
| 매개 변수 | 설명 |
|---|---|
| error | 발생하는 오류 유형을 분류하는 데 사용하는 코드입니다. |
| error_description | 인증 오류의 근본 원인을 식별하도록 도울 수 있는 특정 오류 메시지입니다. |
| state | state 매개 변수가 요청에 포함된 경우 동일한 값이 응답에 표시됩니다. 앱에서 요청 및 응답의 state 값이 동일한지 확인해야 합니다. |
ID 토큰 유효성 검사
ID 토큰을 받는 것만으로는 사용자를 인증할 수 없습니다. ID 토큰의 서명에 대한 유효성을 검사하고 앱의 요구 사항에 따라 토큰의 클레임을 확인합니다. Azure AD B2C는 JWT(JSON 웹 토큰) 및 공개 키 암호화를 사용하여 토큰에 서명하고 토큰이 유효한지 확인합니다.
사용하려는 언어에 따라 JWT의 유효성을 검사하는 데 사용할 수 있는 다양한 오픈 소스 라이브러리가 있습니다. 사용자 고유의 유효성 검사 논리를 구현하는 대신 사용 가능한 오픈 소스 라이브러리를 탐색하는 것이 좋습니다. 이 문서의 정보를 통해 이러한 라이브러리를 올바르게 사용하는 방법을 알아볼 수 있습니다.
Azure AD B2C에는 OpenID Connect 메타데이터 엔드포인트가 있습니다. 앱에서 런타임에 Azure AD B2C에 대한 정보를 가져오는 데 엔드포인트를 사용할 수 있습니다. 이 정보에는 엔드포인트, 토큰 콘텐츠 및 토큰 서명 키가 포함됩니다. Azure AD B2C 테넌트의 각 사용자 흐름에 대한 JSON 메타데이터 문서가 있습니다. 예를 들어 fabrikamb2c.onmicrosoft.com 테넌트의 b2c_1_sign_in 사용자 흐름에 대한 메타데이터 문서는 다음 위치에 있습니다.
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration
이 구성 문서의 속성 중 하나가 jwks_uri입니다. 동일한 사용자 흐름에 대한 값은 다음과 같습니다.
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys
ID 토큰에 서명하는 데 사용된 사용자 흐름(및 메타데이터를 가져올 위치)을 결정하기 위해 다음과 같은 옵션을 사용할 수 있습니다.
사용자 흐름 이름이
id_token의acr클레임에 포함됩니다. ID 토큰에서 클레임을 구문 분석하는 방법에 대한 내용은 Azure AD B2C 토큰 참조를 참조하세요.요청을 발급할 때
state매개 변수의 값으로 사용자 흐름을 인코딩합니다.state매개 변수를 디코딩하여 어떤 사용자 흐름이 사용되었는지 확인하는 것입니다.
OpenID Connect 메타데이터 엔드포인트에서 메타데이터 문서를 가져오면 이 엔드포인트에 있는 RSA-256 공개 키를 사용하여 ID 토큰의 서명에 대한 유효성을 검사할 수 있습니다. 지정된 시간에 이 엔드포인트에 나열된 키가 여러 개 있을 수 있으며, 각 키는 kid로 식별됩니다. id_token의 헤더에는 kid 클레임도 포함되어 있으며, 이는 이러한 키 중에서 ID 토큰 서명에 사용된 키를 나타냅니다. 토큰 유효성을 검사하는 방법을 포함하여 자세한 내용은 Azure AD B2C 토큰 참조를 참조하세요.
ID 토큰의 서명에 대한 유효성을 검사한 후에는 확인해야 할 몇 가지 클레임이 있습니다. 예시:
nonce클레임의 유효성을 검사하여 토큰 재생 공격을 방지합니다. 해당 값이 로그인 요청에 지정된 값이어야 합니다.aud클레임의 유효성을 검사하여 앱에 대한 ID 토큰이 발급되었는지 확인합니다. 해당 값이 앱의 애플리케이션 ID여야 합니다.iat및exp클레임의 유효성을 검사하여 ID 토큰이 만료되지 않았는지 확인합니다.
수행해야 하는 몇 가지 추가 유효성 검사는 OpenID Connect 핵심 사양(영문)에서 자세히 설명하고 있습니다. 시나리오에 따라 추가 클레임의 유효성을 검사할 수도 있습니다. 몇 가지 일반적인 유효성 검사는 다음과 같습니다.
사용자 또는 조직이 앱에 등록했는지 확인합니다.
사용자에게 적절한 권한 부여 및 권한이 있는지 확인합니다.
Microsoft Entra 다단계 인증을 사용하는 등 특정 강도의 인증이 발생했는지 확인합니다.
ID 토큰의 클레임에 대한 자세한 내용은 Azure AD B2C 토큰 참조를 참조하세요.
ID 토큰의 유효성을 검사한 후에는 사용자가 포함된 세션을 시작할 수 있습니다. 앱에서 ID 토큰의 클레임을 사용하여 사용자 관련 정보를 가져올 수 있으며, 이 정보는 표시, 레코드, 권한 부여 등에 사용될 수 있습니다.
액세스 토큰 가져오기
웹앱에서 사용자 흐름만 실행해야 하는 경우 다음 몇 가지 섹션을 건너뛸 수 있습니다. 다음 섹션의 정보는 Web API에 대해 인증된 호출을 수행해야 하며 Azure AD B2C 자체로 보호되는 웹앱에만 적용할 수 있습니다.
이제 사용자를 SPA에 로그인했으므로 Microsoft Entra ID로 보호되는 웹 API를 호출하기 위한 액세스 토큰을 가져올 수 있습니다. token 응답 형식을 사용하여 토큰을 이미 받았더라도 이 메서드를 사용하여 사용자가 다시 로그인하도록 리디렉션하지 않고도 추가 리소스에 대한 토큰을 얻을 수 있습니다.
일반적인 웹앱 흐름에서는 /token 엔드포인트에 요청합니다. 그러나 엔드포인트는 CORS 요청을 지원하지 않으므로 새로 고침 토큰을 가져오기 위해서는 AJAX를 호출해야 합니다. 대신 숨겨진 HTML iFrame 요소에서 암시적 흐름을 사용하여 다른 웹 API에 대한 새 토큰을 가져올 수 있습니다. 다음은 쉽게 읽을 수 있도록 줄 바꿈을 적용한 예제입니다.
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none
| 매개 변수 | 필수? | 설명 |
|---|---|---|
| {tenant} | Required | Azure AD B2C 테넌트의 이름 |
| {policy} | Required | 실행할 사용자 흐름입니다. Azure AD B2C 테넌트에서 만든 사용자 흐름의 이름을 지정합니다. 예: b2c_1_sign_in, b2c_1_sign_up 또는 b2c_1_edit_profile. |
| client_id | Required | Azure Portal에서 앱에 할당된 애플리케이션 ID입니다. |
| response_type | Required | OpenID Connect 로그인을 위한 id_token 이 포함되어야 합니다. token 응답 형식이 포함될 수도 있습니다. 여기서 token을 사용하면 앱에서 권한 부여 엔드포인트에 대한 두 번째 요청을 수행하지 않고도 권한 부여 엔드포인트에서 액세스 토큰을 즉시 받을 수 있습니다. token 응답 형식을 사용하는 경우 scope 매개 변수에는 토큰을 발급할 리소스를 나타내는 범위가 포함되어야 합니다. |
| redirect_uri | 권장 | 앱이 인증 응답을 보내고 받을 수 있는 앱의 리디렉션 URI입니다. URL로 인코딩해야 한다는 점을 제외하고는 포털에서 등록한 리디렉션 URI 중 하나와 정확히 일치해야 합니다. |
| scope | Required | 공백으로 구분된 범위 목록입니다. 토큰을 가져오려면 원하는 리소스에 필요한 모든 범위를 포함합니다. |
| response_mode | 권장 | 결과 토큰을 앱으로 다시 보내는 데 사용되는 메서드를 지정합니다. 암시적 흐름의 경우 fragment를 사용합니다. 다른 두 가지 모드(query 및 form_post)를 지정할 수 있지만 암시적 흐름에서는 작동하지 않습니다. |
| state | 권장 | 토큰 응답에 반환되는 요청에 포함된 값입니다. 사용하려는 콘텐츠의 문자열일 수 있습니다. 일반적으로 교차 사이트 요청 위조 공격을 방지하기 위해 임의로 생성된 고유 값이 사용됩니다. 또한 state(상태)는 인증 요청이 발생하기 전에 앱에서 사용자 상태에 대한 정보를 인코딩하는 데에도 사용됩니다. 예를 들어 사용자가 있던 페이지 또는 보기입니다. |
| nonce | Required | 앱에서 생성한 요청에 포함된 값이며, 결과 ID 토큰에 클레임으로 포함됩니다. 그러면 앱에서 이 값을 확인하여 토큰 재생 공격을 완화할 수 있습니다. 값은 일반적으로 요청의 출처를 식별하는 데 사용할 수 있는 임의의 고유 문자열입니다. |
| prompt | Required | 숨겨진 iFrame에서 토큰을 새로 고치고 가져오려면 prompt=none을 사용하여 iFrame이 로그인 페이지에 머물지 않고 즉시 반환되는지 확인합니다. |
| login_hint | Required | 숨겨진 iFrame에서 토큰을 새로 고치고 가져오려면 사용자가 지정된 시간에 가질 수 있는 여러 세션을 구분하기 위해 이 힌트에 해당 사용자의 사용자 이름을 포함합니다. preferred_username 클레임을 사용하여 이전 로그인에서 사용자 이름을 추출할 수 있습니다(preferred_username 클레임을 수신하기 위해서는 profile 범위가 필요함). |
| domain_hint | Required | consumers 또는 organizations일 수 있습니다. 숨겨진 iFrame에서 토큰을 새로 고치고 가져오려면 요청에 domain_hint 값을 포함합니다. 이전 로그인의 ID 토큰에서 tid 클레임을 추출하여 사용할 값을 결정합니다(tid 클레임을 수신하기 위해 profile 범위가 필요함). tid 클레임 값이 9188040d-6c67-4c5b-b112-36a304b66dad인 경우 domain_hint=consumers를 사용합니다. 그렇지 않으면 domain_hint=organizations를 사용합니다. |
prompt=none 매개 변수를 설정하면 이 요청이 즉시 성공하거나 실패하고 애플리케이션으로 돌아갑니다. 성공적인 응답은 response_mode 매개 변수에 지정된 메서드를 사용하여 리디렉션 URI를 통해 앱으로 보내집니다.
성공적인 응답
response_mode=fragment를 사용한 성공적인 응답은 다음과 같습니다.
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
| 매개 변수 | 설명 |
|---|---|
| access_token | 앱이 요청한 토큰입니다. |
| token_type | 토큰 형식은 항상 Bearer(전달자)입니다. |
| state | state 매개 변수가 요청에 포함된 경우 동일한 값이 응답에 표시됩니다. 앱에서 요청 및 응답의 state 값이 동일한지 확인해야 합니다. |
| expires_in | 액세스 토큰의 유효 기간(초)입니다. |
| scope | access_token이 유효한 범위입니다. |
오류 응답
오류 응답은 앱에서 적절히 처리할 수 있도록 리디렉션 URI에 보낼 수도 있습니다. prompt=none의 경우 예상되는 오류는 다음 예과 같습니다.
GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently
| 매개 변수 | 설명 |
|---|---|
| error | 발생하는 오류 유형을 분류하는 데 사용할 수 있는 오류 코드 문자열입니다. 문자열을 사용하여 오류에 대응할 수도 있습니다. |
| error_description | 인증 오류의 근본 원인을 식별하도록 도울 수 있는 특정 오류 메시지입니다. |
iFrame 요청에 이러한 오류를 수신하면, 사용자는 새 토큰을 얻기 위해 대화형으로 다시 로그인해야 합니다.
새로 고침 토큰
ID 토큰 및 액세스 토큰은 모두 짧은 기간 후에 만료됩니다. 이러한 토큰을 정기적으로 새로 고치려면 앱을 준비해야 합니다. 암시적 흐름에서는 보안상의 이유로 새로 고침 토큰을 얻을 수 없습니다. 두 가지 유형의 토큰을 새로 고치려면 숨겨진 HTML iframe 요소에서 암시적 흐름을 사용합니다. 권한 부여 요청에 prompt=none 매개 변수를 포함합니다. 새 id_token 값을 받으려면 response_type=id_token, scope=openid 및 nonce 매개 변수를 사용해야 합니다.
로그아웃 요청 보내기.
사용자를 앱에서 로그아웃하도록 하려면 사용자를 Azure AD B2C의 로그아웃 엔드포인트로 리디렉션합니다. 그런 다음, 앱에서 사용자의 세션을 지울 수 있습니다. 사용자를 리디렉션하지 않으면 Azure AD B2C를 사용하여 유효한 Single Sign-On 세션이 있기 때문에 해당 사용자가 자격 증명을 다시 입력하지 않고 앱에 다시 인증할 수 있습니다.
ID 토큰 유효성 검사에서 설명한 동일한 OpenID Connect 메타데이터 문서에 나열된 end_session_endpoint로 사용자를 리디렉션할 수 있습니다. 예시:
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
| 매개 변수 | 필수 | 설명 |
|---|---|---|
| {tenant} | 예 | Azure AD B2C 테넌트의 이름. |
| {policy} | 예 | 애플리케이션에서 사용자를 로그아웃하는 데 사용하려는 사용자 흐름입니다. 앱이 사용자를 로그인하는 데 사용한 것과 동일한 사용자 흐름이어야 합니다. |
| post_logout_redirect_uri | 아니요 | 성공적으로 로그아웃한 후에 사용자가 리디렉션되는 URL입니다. 포함되어 있지 않으면 Azure AD B2C 사용자에게 일반 메시지를 표시합니다. |
| state | 아니요 | state 매개 변수가 요청에 포함된 경우 동일한 값이 응답에 표시됩니다. 애플리케이션은 요청의 상태 값과 응답의 state 값이 같은지 확인해야 합니다. |
참고 항목
사용자를 end_session_endpoint로 전달하면 Azure AD B2C로 사용자의 Single Sign-On 상태 중 일부를 지웁니다. 그러나 사용자의 소셜 ID 공급자 세션에서 사용자를 서명하지 않습니다. 사용자가 후속 로그인 중에 동일한 ID 공급자를 선택하면 자격 증명을 입력하지 않고도 다시 인증됩니다. 사용자가 Azure AD B2C 애플리케이션에서 로그아웃하려는 경우 반드시 Facebook과 같은 계정에서 완전히 로그아웃하려는 것은 아닙니다. 그러나 로컬 계정의 경우 사용자의 세션이 제대로 종료됩니다.
다음 단계
코드 샘플: JavaScript SPA에서 Azure AD B2C를 사용하여 로그인을 참조하세요.