다음을 통해 공유

Azure Active Directory B2C에서 OpenID Connect로 웹 로그인

  • 아티클

OpenID Connect는 웹 애플리케이션에 사용자를 안전하게 로그인하는 데 사용할 수 있도록 OAuth 2.0을 기반으로 하여 빌드된 인증 프로토콜입니다. OpenID Connect의 Azure AD B2C(Azure Active Directory B2C) 구현을 사용하여 웹 애플리케이션의 등록, 로그인 및 기타 ID 관리 환경을 Microsoft Entra ID로 아웃소싱할 수 있습니다. 이 가이드에서는 언어에 관계 없이 이 작업을 수행하는 방법을 보여 줍니다. 오픈 소스 라이브러리를 사용하지 않고 HTTP 메시지를 보내고 받는 방법을 설명합니다.

참고 항목

대부분의 오픈 소스 인증 라이브러리는 애플리케이션에 대한 JWT 토큰을 가져와 유효성을 검사합니다. 사용자 고유의 코드를 구현하는 대신 이러한 옵션을 탐색하는 것이 좋습니다. 자세한 내용은 Microsoft 인증 라이브러리(MSAL) 개요 및 Microsoft Identity Web 인증 라이브러리를 참조하세요.

OpenID Connect는 인증 프로토콜로 사용하기 위해 OAuth 2.0 권한 부여 프로토콜을 확장합니다. 이 인증 프로토콜을 통해 Single Sign-On을 수행할 수 있습니다. 클라이언트에서 사용자 ID를 확인하고 사용자에 대한 기본 프로필 정보를 얻을 수 있게 하는 ‘ID 토큰’의 개념을 소개합니다.

또한 OpenID Connect를 사용하면 애플리케이션이 액세스 토큰을 안전하게 획득할 수 있습니다. 액세스 토큰을 사용하여 권한 부여 서버에서 획득하는 리소스에 액세스할 수 있습니다. OpenID Connect는 서버에서 호스트되고 브라우저를 통해 액세스되는 웹 애플리케이션을 빌드하는 경우에 권장됩니다. 토큰에 대한 자세한 내용은 Azure Active Directory B2C의 토큰 개요를 참조하세요.

Azure AD B2C는 단순한 인증 및 권한 부여 보다 더 많은 작업으로 표준 OpenID Connect 프로토콜을 확장합니다. OpenID Connect를 사용하여 등록, 로그인, 프로필 관리와 같은 사용자 환경을 애플리케이션에 추가할 수 있는 사용자 흐름 매개 변수를 도입합니다.

인증 요청 보내기

웹 애플리케이션이 사용자를 인증하고 사용자 흐름을 실행해야 하는 경우 사용자를 /authorize 엔드포인트로 보낼 수 있습니다. 사용자가 사용자 흐름에 따라 동작을 수행합니다.

이 요청에서 클라이언트는 scope 매개 변수에서 사용자로부터 가져와야 할 사용 권한을 나타내며, 실행할 사용자 흐름을 지정합니다. 요청의 작동 방식을 파악하려면 브라우저에 요청을 붙여넣고 실행합니다. 다음을

  • {tenant}를 테넌트로 바꿉니다.
  • 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6을 테넌트에 등록해 두었던 애플리케이션의 앱 ID로 바꿉니다.
  • {application-id-uri}/{scope-name}를 테넌트에 등록한 애플리케이션의 애플리케이션 ID URI 및 범위로 바꿉니다.
  • {policy}를 테넌트에 있는 정책 이름(예: b2c_1_sign_in)으로 바꿉니다.
GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
매개 변수 필수 설명
{tenant} 예 Azure AD B2C 테넌트의 이름. 사용자 지정 도메인을 사용하는 경우 tenant.b2clogin.com를 도메인(예: fabrikam.com)으로 바꿉니다.
{policy} 예 앱이 실행되는 사용자 흐름 또는 정책입니다. Azure AD B2C 테넌트에서 만든 사용자 흐름의 이름을 지정합니다. 예: b2c_1_sign_in, b2c_1_sign_up 또는 b2c_1_edit_profile.
client_id 예 Azure Portal이 애플리케이션에 할당한 애플리케이션 ID입니다.
nonce 예 애플리케이션에서 생성한 요청에 포함된 값이며, 결과 ID 토큰에 클레임으로 포함됩니다. 그러면 애플리케이션에서 이 값을 확인하여 토큰 재생 공격을 완화할 수 있습니다. 값은 일반적으로 요청의 출처를 식별하는 데 사용할 수 있는 임의의 고유 문자열입니다.
response_type 예 OpenID Connect의 ID 토큰을 포함해야 합니다. 웹 API를 호출하기 위한 토큰이 웹 애플리케이션에 필요한 경우 code+id_token을 사용할 수 있습니다.
scope 예 공백으로 구분된 범위 목록입니다. openid 범위는 사용자에게 로그인하고 ID 토큰 형식으로 사용자에 대한 데이터를 가져올 권한을 나타냅니다. offline_access 범위는 웹 애플리케이션에 대한 선택 사항입니다. 새로 고침 토큰은 확장된 시간 동안 리소스에 액세스하기 위한 새로 고침 토큰이 애플리케이션에 필요함을 나타냅니다. https://{tenant-name}/{app-id-uri}/{scope}는 웹 API와 같은 보호된 리소스에 대한 권한을 나타냅니다. 자세한 내용은 액세스 토큰 요청을 참조하세요.
prompt 아니요 필요한 사용자 상호 작용 유형입니다. 현재 유효한 값은 login뿐이며, 이는 사용자가 해당 요청에 대한 자격 증명을 입력하도록 합니다.
redirect_uri 예 서버가 애플리케이션에 인증 응답을 보내는 애플리케이션의 redirect_uri 매개 변수입니다. URL로 인코딩되어야 한다는 점을 제외하고는 Azure Portal에서 등록한 redirect_uri 매개 변수 중 하나와 정확히 일치해야 합니다.
response_mode 아니요 결과 권한 부여 코드를 애플리케이션에 다시 보내는 데 사용되는 메서드입니다. query, form_post 또는 fragment 중 하나일 수 있습니다. 최상의 보안을 위해 form_post 응답 모드를 사용하는 것이 좋습니다.
state 아니요 권한 부여 서버가 토큰 응답에 반환하는 요청에 포함할 수 있는 값입니다. 원하는 모든 콘텐츠의 문자열일 수 있습니다. 일반적으로 교차 사이트 요청 위조 공격을 방지하기 위해 임의로 생성된 고유 값이 사용됩니다. 상태는 인증 요청이 발생하기 전 애플리케이션의 사용자 상태에 대한 정보(예: 사용한 페이지)를 인코드하는 데에도 사용됩니다. Azure Portal에 여러 리디렉션 URL을 등록하지 않으려면 state 매개 변수를 사용하여 다양한 요청으로 인해 애플리케이션의 응답을 Azure AD B2C 서비스와 구분할 수 있습니다.
login_hint 아니요 로그인 페이지의 로그인 이름 필드를 미리 채우는 데 사용할 수 있습니다. 자세한 내용은 로그인 이름 미리 채우기를 참조하세요.
domain_hint 아니요 로그인에 사용해야 하는 소셜 ID 공급자에 대한 힌트를 Azure AD B2C에 제공합니다. 유효한 값이 포함된 경우 사용자는 ID 공급자 로그인 페이지로 직접 이동합니다. 자세한 내용은 소셜 공급자로 로그인 리디렉션을 참조하세요.
사용자 지정 매개 변수 아니요 사용자 지정 정책에 사용할 수 있는 사용자 지정 매개 변수입니다. 예를 들어 동적 사용자 지정 페이지 콘텐츠 URI또는 키-값 클레임 해결 프로그램입니다.

이 시점에서 워크플로를 완료하도록 사용자에게 요청합니다. 사용자는 사용자 이름 및 암호를 입력하거나, 소셜 ID로 로그인하거나, 디렉터리에 가입해야 할 수 있습니다. 사용자 흐름이 정의된 방법에 따라 따라야 하는 단계의 수가 다를 수 있습니다.

사용자가 사용자 흐름을 완료하면 response_mode 매개 변수에 지정된 메서드를 사용하여 표시된 redirect_uri 매개 변수에서 애플리케이션에 대한 응답이 반환됩니다. 응답은 사용자 흐름과 관계없이 앞의 경우 각각에 대해 동일합니다.

response_mode=fragment 를 사용한 성공적인 응답은 다음과 같습니다.

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
매개 변수 설명
id_token 애플리케이션이 요청한 ID 토큰입니다. ID 토큰을 사용하여 사용자 ID를 확인하고 사용자와 세션을 시작할 수 있습니다.
코드 response_type=code+id_token을 사용한 경우 애플리케이션에서 요청한 권한 부여 코드입니다. 애플리케이션은 권한 부여 코드를 사용하여 대상 리소스에 대한 액세스 토큰을 요청할 수 있습니다. 권한 부여 코드는 일반적으로 약 10분 후에 만료됩니다.
state state 매개 변수가 요청에 포함된 경우 동일한 값이 응답에 표시됩니다. 애플리케이션은 요청의 상태 값과 응답의 state 값이 같은지 확인해야 합니다.

애플리케이션에서 적절하게 처리할 수 있도록 redirect_uri 매개 변수에 오류 응답을 보낼 수도 있습니다.

GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response
매개 변수 설명
error 발생하는 오류 유형을 분류하는 데 사용할 수 있는 코드입니다.
error_description 인증 오류의 근본 원인을 식별하도록 도울 수 있는 특정 오류 메시지입니다.
state state 매개 변수가 요청에 포함된 경우 동일한 값이 응답에 표시됩니다. 애플리케이션은 요청의 상태 값과 응답의 state 값이 같은지 확인해야 합니다.

ID 토큰 유효성 검사

ID 토큰을 받는 것만으로는 사용자를 인증할 수 없습니다. ID 토큰의 서명에 대한 유효성을 검사하고 애플리케이션의 요구 사항에 따라 토큰의 클레임을 확인합니다. Azure AD B2C는 JWT(JSON 웹 토큰) 및 공개 키 암호화를 사용하여 토큰에 서명하고 토큰이 유효한지 확인합니다.

참고 항목

대부분의 오픈 소스 인증 라이브러리는 애플리케이션에 대한 JWT 토큰의 유효성을 검사합니다. 고유한 유효성 검사 논리를 구현하는 것보다 이러한 옵션을 탐색하는 것이 좋습니다. 자세한 내용은 Microsoft 인증 라이브러리(MSAL) 개요 및 Microsoft Identity Web 인증 라이브러리를 참조하세요.

Azure AD B2C에는 애플리케이션이 런타임에 Azure AD B2C에 대한 정보를 가져올 수 있게 해주는 OpenID Connect 메타데이터 엔드포인트가 있습니다. 이 정보에는 엔드포인트, 토큰 콘텐츠 및 토큰 서명 키가 포함됩니다. 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 토큰의 acr 클레임에 포함됩니다. 사용자 흐름을 나타내는 클레임을 참조하세요. 다른 옵션은 요청을 실행할 때 state 매개 변수의 값에 사용자 흐름을 인코딩한 다음 이를 디코딩하여 어떤 사용자 흐름을 사용할지 결정하는 것입니다. 두 방법 중 하나는 유효합니다.

OpenID Connect 메타데이터 엔드포인트에서 메타데이터 문서를 가져오면 RSA-256 공개 키를 사용하여 ID 토큰의 서명에 대한 유효성을 검사할 수 있습니다. 해당 엔드포인트에 나열된 키가 여러 개 있을 수 있으며, 각 키는 kid 클레임으로 식별됩니다. ID 토큰의 헤더에는 kid 클레임도 포함되어 있으며, 이는 이러한 키 중에서 ID 토큰 서명에 사용된 키를 나타냅니다.

Azure AD B2C에서 토큰을 확인하려면 지수(e) 및 모듈러스(n)를 사용하여 공개 키를 생성해야 합니다. 이렇게 하려면 선택한 프로그래밍 언어로 공개 키를 생성하는 방법을 알아야 합니다. RSA 프로토콜을 사용한 공개 키 생성에 대한 공식 문서는 https://tools.ietf.org/html/rfc3447#section-3.1 페이지에서 확인할 수 있습니다.

ID 토큰의 서명에 대한 유효성을 검사한 후에는 확인해야 할 여러 가지 클레임이 있습니다. 예를 들면 다음과 같습니다.

  • nonce 클레임의 유효성을 검사하여 토큰 재생 공격을 방지합니다. 해당 값이 로그인 요청에 지정된 값이어야 합니다.
  • aud 클레임의 유효성을 검사하여 애플리케이션에 대한 ID 토큰이 발급되었는지 확인합니다. 해당 값이 애플리케이션의 애플리케이션 ID여야 합니다.
  • iat 및 exp 클레임의 유효성을 검사하여 ID 토큰이 만료되지 않았는지 확인합니다.

또한 수행해야 하는 몇 가지 추가 유효성 검사가 있습니다. 유효성 검사는 OpenID Connect 핵심 사양(영문)에 자세히 설명되어 있습니다. 시나리오에 따라 추가 클레임의 유효성을 검사하는 것이 좋을 수도 있습니다. 몇 가지 일반적인 유효성 검사는 다음과 같습니다.

  • 사용자/조직이 애플리케이션에 등록했는지 확인합니다.
  • 사용자에게 적절한 권한 부여/권한이 있는지 확인합니다.
  • Microsoft Entra 다단계 인증과 같은 특정 강도의 인증이 발생했는지 확인합니다.

ID 토큰의 유효성을 검사한 후에는 사용자가 포함된 세션을 시작할 수 있습니다. 애플리케이션에서 ID 토큰의 클레임을 사용하여 사용자 관련 정보를 가져올 수 있으며, 이 정보의 용도로 표시, 레코드 및 권한 부여가 있습니다.

토큰 가져오기

웹 애플리케이션에서 사용자 흐름만 실행해야 하는 경우 다음 몇 가지 섹션을 건너뛸 수 있습니다. 이러한 섹션은 Azure AD B2C 자체로 보호되는 웹 API에 대해 인증된 호출을 수행해야 하는 웹 애플리케이션에만 적용됩니다.

response_type=code+id_token을 사용하여 POST 요청을 /token 엔드포인트로 보내 원하는 리소스에 대한 토큰에 대해 얻은 권한 부여 코드를 사용할 수 있습니다. Azure AD B2C에서는 요청에서 범위를 지정하는 방식으로 평소처럼 다른 API에 대한 액세스 토큰을 요청할 수 있습니다.

앱의 자체 백 엔드 Web API에 대한 액세스 토큰을 요청할 수도 있습니다. 이 경우 앱의 클라이언트 ID를 요청된 범위로 사용하여 해당 클라이언트 ID가 "대상 그룹"인 액세스 토큰을 만듭니다.

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
매개 변수 필수 설명
{tenant} 예 Azure AD B2C 테넌트의 이름
{policy} 예 권한 부여 코드를 획득하는 데 사용된 사용자 흐름입니다. 이 요청에 다른 사용자 흐름을 사용할 수 없습니다. 이 매개 변수는 POST 본문이 아니라 쿼리 문자열에 추가합니다.
client_id 예 Azure Portal이 애플리케이션에 할당한 애플리케이션 ID입니다.
client_secret 예(웹앱) Azure Portal에서 생성한 애플리케이션 암호입니다. 웹앱 시나리오의 이 흐름에서는 클라이언트가 클라이언트 암호를 안전하게 저장할 수 있으므로 클라이언트 암호가 사용됩니다. 네이티브 앱(공용 클라이언트) 시나리오의 경우 클라이언트 암호를 안전하게 저장할 수 없으므로 이 흐름에서 사용되지 않습니다. 클라이언트 암호를 사용하는 경우 주기적으로 변경합니다.
코드 예 사용자 흐름의 시작 부분에서 얻은 권한 부여 코드입니다.
grant_type 예 권한 유형입니다. 인증 코드 흐름의 경우 authorization_code이어야 합니다.
redirect_uri 아니요 권한 부여 코드를 받은 애플리케이션의 redirect_uri 매개 변수입니다.
scope 아니요 공백으로 구분된 범위 목록입니다. openid 범위는 사용자에게 로그인하고 id_token 매개 변수의 형식으로 사용자에 대한 데이터를 가져올 권한을 나타냅니다. 이는 클라이언트와 동일한 애플리케이션 ID로 표시되는 애플리케이션 자체의 백 엔드 웹 API에 토큰을 가져오는 데 사용할 수 있습니다. offline_access 범위는 확장된 시간 동안 리소스에 액세스하기 위한 새로 고침 토큰이 애플리케이션에 필요함을 나타냅니다.

성공적인 토큰 응답은 다음과 같습니다.

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
매개 변수 설명
not_before 토큰이 유효해지는 epoch 시간입니다.
token_type 토큰 형식 값입니다. 유일하게 지원되는 유형은 Bearer입니다.
access_token 사용자가 요청한 서명된 JWT 토큰입니다.
scope 토큰의 유효 범위입니다.
expires_in 액세스 토큰이 유효한 시간(초)입니다.
expires_on 액세스 토큰이 유효하지 않은 Epoch 시간입니다.
refresh_token OAuth 2.0 새로 고침 토큰입니다. 애플리케이션은 현재 토큰이 만료된 후 이 토큰을 사용하여 더 많은 토큰을 획득할 수 있습니다. 새로 고침 토큰은 오랜 시간 동안 리소스에 대한 액세스를 유지하는 데 사용할 수 있습니다. 새로 고침 토큰을 받으려면 권한 부여 및 토큰 요청 모두에서 offline_access 범위를 사용해야 합니다.

오류 응답은 다음과 같습니다.

{
    "error": "invalid_grant",
    "error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}
매개 변수 설명
error 발생하는 오류 유형을 분류하는 데 사용할 수 있는 코드입니다.
error_description 인증 오류의 근본 원인을 식별하도록 도울 수 있는 메시지입니다.

토큰 사용

액세스 토큰을 성공적으로 얻은 후에는 Authorization 헤더에 포함하여 백 엔드 웹 API에 대한 요청에서 토큰을 사용할 수 있습니다.

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

토큰 새로 고침

액세스 토큰 및 ID 토큰은 수명이 짧습니다. 만료되면 새로 고쳐야 리소스에 계속 액세스할 수 있습니다. 액세스 토큰을 새로 고치면 Azure AD B2C는 새 토큰을 반환합니다. 새로 고친 액세스 토큰에는 업데이트된 nbf(이전은 아님), iat(발급 시간) 및 exp(만료) 클레임 값이 있습니다. 다른 모든 클레임 값은 이전 액세스 토큰의 값과 유사합니다.

토큰을 새로 고치려면 다른 POST 요청을 /token 엔드포인트에 제출하면 됩니다. 이번에는 code 매개 변수 대신 refresh_token 매개 변수를 제공합니다.

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
매개 변수 필수 설명
{tenant} 예 Azure AD B2C 테넌트의 이름
{policy} 예 원래의 새로 고침 토큰을 얻는 데 사용된 사용자 흐름입니다. 이 요청에 다른 사용자 흐름을 사용할 수 없습니다. 이 매개 변수는 POST 본문이 아니라 쿼리 문자열에 추가합니다.
client_id 예 Azure Portal이 애플리케이션에 할당한 애플리케이션 ID입니다.
client_secret 예(웹앱) Azure Portal에서 생성한 애플리케이션 암호입니다. 웹앱 시나리오의 이 흐름에서는 클라이언트가 클라이언트 암호를 안전하게 저장할 수 있으므로 클라이언트 암호가 사용됩니다. 네이티브 앱(공용 클라이언트) 시나리오의 경우 클라이언트 암호를 안전하게 저장할 수 없으므로 이 호출에서 사용되지 않습니다. 클라이언트 암호를 사용하는 경우 주기적으로 변경해야 합니다.
grant_type 예 권한 유형입니다. 이 인증 코드 흐름 부분의 경우 refresh_token이어야 합니다.
refresh_token 예 흐름의 두 번째 부분에서 얻은 원래의 새로 고침 토큰입니다. 새로 고침 토큰을 받으려면 권한 부여 및 토큰 요청 모두에서 offline_access 범위를 사용해야 합니다.
redirect_uri 아니요 권한 부여 코드를 받은 애플리케이션의 redirect_uri 매개 변수입니다.
scope 아니요 공백으로 구분된 범위 목록입니다. openid 범위는 사용자에게 로그인하고 ID 토큰 형식으로 사용자에 대한 데이터를 가져올 권한을 나타냅니다. 클라이언트와 동일한 애플리케이션 ID로 표시되는 애플리케이션 자체의 백 엔드 웹 API에 토큰을 보내는 데 사용할 수 있습니다. offline_access 범위는 확장된 시간 동안 리소스에 액세스하기 위한 새로 고침 토큰이 애플리케이션에 필요함을 나타냅니다.

성공적인 토큰 응답은 다음과 같습니다.

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}
매개 변수 설명
not_before 토큰이 유효해지는 epoch 시간입니다.
token_type 토큰 형식 값입니다. 유일하게 지원되는 유형은 Bearer입니다.
access_token 요청된 서명된 JWT 토큰입니다.
scope 토큰의 유효 범위입니다.
expires_in 액세스 토큰이 유효한 시간(초)입니다.
refresh_token OAuth 2.0 새로 고침 토큰입니다. 애플리케이션은 현재 토큰이 만료된 후 이 토큰을 사용하여 추가 토큰을 획득할 수 있습니다. 새로 고침 토큰은 오랜 시간 동안 리소스에 대한 액세스를 유지하는 데 사용할 수 있습니다.
refresh_token_expires_in 새로 고침 토큰이 유효한 시간(초)입니다.

오류 응답은 다음과 같습니다.

{
    "error": "invalid_grant",
    "error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}
매개 변수 설명
error 발생하는 오류 유형을 분류하는 데 사용할 수 있는 코드입니다.
error_description 인증 오류의 근본 원인을 식별하도록 도울 수 있는 메시지입니다.

로그아웃 요청 보내기.

애플리케이션에서 사용자를 로그아웃시키려는 경우 애플리케이션의 쿠키를 삭제하거나 그렇지 않은 경우 사용자로 세션을 지우는 것은 충분하지 않습니다. 로그아웃하려면 Azure AD B2C로 사용자를 리디렉션합니다. 그러지 않으면 사용자가 자격 증명을 다시 입력하지 않고 애플리케이션을 다시 인증할 수 있습니다. 자세한 내용은 Azure AD B2C 세션 동작을 참조하세요.

사용자를 로그아웃하려면 앞에서 설명한 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%2Fjwt.ms%2F
매개 변수 필수 설명
{tenant} 예 Azure AD B2C 테넌트의 이름. 사용자 지정 도메인을 사용하는 경우 tenant.b2clogin.com를 도메인(예: fabrikam.com)으로 바꿉니다.
{policy} 예 권한 부여 요청에 지정한 사용자 흐름입니다. 예를 들어 사용자가 b2c_1_sign_in 사용자 흐름으로 로그인한 경우 로그아웃 요청에 b2c_1_sign_in를 지정합니다.
id_token_hint 아니요 이전에 발급된 ID 토큰으로 최종 사용자의 클라이언트와의 현재 인증된 세션에 대한 힌트로서 로그아웃 엔드포인트로 전달됩니다. id_token_hint는 Azure AD B2C 애플리케이션 설정에서 post_logout_redirect_uri가 등록된 회신 URL인지 확인합니다. 자세한 내용은 로그아웃 리디렉션 보안을 참조하세요.
client_id 아니요* Azure Portal이 애플리케이션에 할당한 애플리케이션 ID입니다.

*Application 격리 SSO 구성 및 로그아웃 요청이 No로 설정된 경우 ID 토큰 필요를 사용할 때 필요합니다.
post_logout_redirect_uri 아니요 성공적으로 로그아웃한 후에 사용자가 리디렉션되는 URL입니다. 포함되어 있지 않으면 Azure AD B2C 사용자에게 일반 메시지를 표시합니다. id_token_hint를 제공하지 않는 한 Azure AD B2C 애플리케이션 설정에서 이 URL을 회신 URL로 등록해서는 안 됩니다.
state 아니요 권한 부여 요청에 state 매개 변수를 포함하는 경우 권한 부여 서버는 post_logout_redirect_uri에 대한 응답에서 동일한 값을 반환합니다. 애플리케이션은 요청의 상태 값과 응답의 state 값이 같은지 확인해야 합니다.

로그아웃 요청 시 Azure AD B2C는 Azure AD B2C 쿠키 기반 세션을 무효화하고 페더레이션된 ID 공급자에서 로그아웃을 시도합니다. 자세한 내용은 Single Sign-out을 참조하세요.

로그아웃 리디렉션 보안

로그아웃 후 사용자는 애플리케이션에 대해 지정하는 회신 URL에 관계없이 post_logout_redirect_uri 매개 변수에 지정된 URI로 리디렉션됩니다. 그러나 유효한 id_token_hint가 전달되고 로그아웃 요청에서 ID 토큰 요구가 켜져 있는 경우 Azure AD B2C는 리디렉션을 수행하기 전 post_logout_redirect_uri 값이 애플리케이션의 구성된 리디렉션 URI 중 하나와 일치하는지 확인합니다. 애플리케이션에 일치하는 회신 URL이 구성되지 않은 경우 오류 메시지가 표시되고 사용자는 리디렉션되지 않습니다.

로그아웃 요청에 필요한 ID 토큰을 설정하려면 Azure Active Directory B2C에서 세션 동작 구성을 참조하세요.

다음 단계