다단계 인증을 위해 Azure Active Directory B2C를 사용하여 Asignio 구성

아티클
01/26/2024

Microsoft Entra ID (Azure AD B2C) 인증을 Asignio와 통합하는 방법을 알아봅니다. 이 통합을 사용하면 암호 없는 소프트 생체 인식 및 다단계 인증 환경을 고객에게 제공할 수 있습니다. Asignio는 사용자 인증을 위해 특허 받은 Asignio 서명과 라이브 얼굴 확인을 사용합니다. 변경 가능한 생체 인식 서명은 옴니채널 인증을 통해 암호, 사기, 피싱 및 자격 증명 다시 사용을 줄입니다.

시작하기 전에

정책 유형 설정을 나타내려면 정책 유형 선택기를 선택합니다. Azure AD B2C에는 사용자가 애플리케이션과 상호 작용하는 방법을 정의하는 두 가지 방법이 있습니다.

미리 정의된 사용자 흐름
구성 가능한 사용자 지정 정책

이 문서의 단계는 각 방법에 따라 다릅니다.

자세히 보기:

필수 구성 요소

Azure 구독
없는 경우 Azure 체험 계정을 구합니다.

Azure 구독에 연결된 Azure AD B2C 테넌트
자습서: Azure Active Directory B2C 테넌트 만들기를 참조하세요.
Asignio에서 발급하는 Asignio 클라이언트 ID 및 클라이언트 암호.
이러한 토큰은 모바일 또는 웹 애플리케이션을 Asignio에 등록하여 가져옵니다.

사용자 지정 정책의 경우

자습서: Azure AD B2C에서 사용자 흐름 및 사용자 지정 정책 만들기 완료

시나리오 설명

이 통합에 포함되는 구성 요소는 다음과 같습니다.

Azure AD B2C – 사용자 자격 증명을 확인하는 권한 부여 서버
웹 또는 모바일 애플리케이션 - Asignio MFA로 보호
Asignio 웹 애플리케이션 - 사용자의 터치 디바이스에 대한 서명 생체 인식 컬렉션

아래 다이어그램은 구현을 보여 줍니다.

Diagram showing the implementation architecture.

사용자가 모바일 또는 웹 애플리케이션에서 Azure AD B2C의 로그인 페이지를 연 다음, 로그인하거나 가입합니다.
Azure AD B2C에서 OIDC(OpenID Connect) 요청을 사용하여 사용자를 Asignio로 리디렉션합니다.
생체 인식 로그인을 위해 사용자를 Asignio 웹 애플리케이션으로 리디렉션합니다. 사용자가 Asignio 서명을 등록하지 않은 경우 SMS OTP(일회용 암호)를 사용하여 인증할 수 있습니다. 인증 후 사용자는 Asignio 서명을 만드는 등록 링크를 받습니다.
사용자는 Asignio 서명 및 얼굴 인증 또는 음성 및 얼굴 인증을 사용하여 인증합니다.
챌린지 응답은 Asignio로 이동합니다.
Asignio에서 Azure AD B2C 로그인에 대한 OIDC 응답을 반환합니다.
Azure AD B2C에서 인증 데이터 수신을 확인하기 위해 인증 확인 요청을 Asignio에 보냅니다.
사용자에게 애플리케이션 액세스 권한이 부여되거나 거부됩니다.

Asignio를 사용하여 애플리케이션 구성

Asignio를 사용하여 애플리케이션을 구성하는 것은 Asignio 파트너 관리 사이트에서 합니다.

asignio.com Asignio 파트너 관리 페이지로 이동하여 조직에 대한 액세스를 요청합니다.
자격 증명을 사용하여 Asignio 파트너 관리에 로그인합니다.
Azure AD B2C 테넌트를 사용하여 Azure AD B2C 애플리케이션에 대한 레코드를 만듭니다. Azure AD B2C를 Asignio와 사용하는 경우 Azure AD B2C에서 연결된 애플리케이션을 관리합니다. Asignio 앱은 Azure Portal의 앱을 나타냅니다.
Asignio 파트너 관리 사이트에서 클라이언트 ID와 클라이언트 암호를 생성합니다.
클라이언트 ID 및 클라이언트 암호를 기록하고 저장합니다. 나중에 사용할 것입니다. Asignio는 클라이언트 암호를 저장하지 않습니다.
인증 후에 사용자가 돌아가는 사이트에 리디렉션 URI를 입력하세요. 다음 URI 패턴을 사용합니다.

[https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp].

회사 로고를 업로드합니다. 사용자가 로그인하면 Asignio 인증에 표시됩니다.

Azure AD B2C에서 웹 애플리케이션 등록

관리하는 테넌트에서 애플리케이션을 등록한 다음 Azure AD B2C와 상호 작용할 수 있습니다.

자세한 정보: Active Directory B2C에서 사용할 수 있는 애플리케이션 형식

이 자습서에서는 브라우저에서 나가지 않는 디코딩된 토큰 콘텐츠가 있는 Microsoft 웹 애플리케이션인 https://jwt.ms를 등록합니다.

웹 애플리케이션을 등록하고 ID 토큰 암시적 부여를 사용하도록 설정

자습서: Azure Active Directory B2C에서 웹 애플리케이션 등록 완료

Azure AD B2C에서 Asignio를 ID 공급자로 구성

다음 지침은 Azure 구독에서 Microsoft Entra 테넌트 를 사용합니다.

Azure AD B2C 테넌트의 전역 관리자로 Azure Portal에 로그인합니다.
Azure Portal 도구 모음에서 디렉터리 + 구독을 선택합니다.
포털 설정 | 디렉터리 + 구독의 디렉터리 이름 목록에서 Microsoft Entra 디렉터리를 찾습니다.
전환을 선택합니다.
Azure Portal의 왼쪽 위에서 모든 서비스를 선택합니다.
Azure AD B2C를 검색하고 선택합니다.
Azure Portal에서 Azure AD B2C를 검색하고 선택합니다.
왼쪽 메뉴에서 ID 공급자를 선택합니다.
새 OpenID Connect 공급자를 선택합니다.
ID 공급자 유형>OpenID Connect를 차례로 선택합니다.
이름에 Asignio 로그인 또는 선택한 이름을 입력합니다.
메타데이터 URL에 https://authorization.asignio.com/.well-known/openid-configuration을 입력합니다.
클라이언트 ID에 생성한 클라이언트 ID를 입력합니다.
클라이언트 암호에 생성한 클라이언트 암호를 입력합니다.
범위에 openID 이메일 프로필을 사용합니다.
응답 유형의 경우 code를 사용합니다.
응답 모드에 쿼리를 사용합니다.
도메인 힌트에 https://asignio.com을 사용합니다.
확인을 선택합니다.
이 ID 공급자의 클레임 매핑을 선택합니다.
사용자 ID에는 sub를 사용합니다.
표시 이름에 이름을 사용합니다.
지정된 이름으로 given_name을 사용합니다.
성으로 family_name을 사용합니다.
이메일에 email을 사용합니다.
저장을 선택합니다.

사용자 흐름 정책 만들기

Azure AD B2C 테넌트에서, 정책 아래 사용자 흐름을 선택합니다.
새 사용자 흐름을 선택합니다.
가입 및 로그인 사용자 흐름 유형을 선택합니다.
권장 버전을 선택합니다.
만들기를 실행합니다.
AsignioSignupSignin과 같은 사용자 흐름 이름을 입력합니다.
ID 공급자에서 로컬 계정에 대해 없음을 선택합니다. 이 작업은 이메일 및 암호 인증을 사용하지 않도록 설정합니다.
사용자 지정 ID 공급자의 경우 생성된 Asignio ID 공급자를 선택합니다.
만들기를 실행합니다.

사용자 흐름 테스트

Azure AD B2C 테넌트에서 사용자 흐름을 선택합니다.
만든 사용자 흐름을 선택합니다.
애플리케이션에 대해 등록한 웹 애플리케이션을 선택합니다. 회신 URL은 https://jwt.ms입니다.
사용자 흐름 실행을 선택합니다.
브라우저가 Asignio 로그인 페이지로 리디렉션됩니다.
로그인 화면이 나타납니다.
아래쪽에서 Asignio 인증을 선택합니다.

Asignio 서명이 있는 경우 인증하라는 프롬프트를 완료합니다. 그렇지 않은 경우 SMS OTP를 통해 인증할 디바이스 전화번호를 입력합니다. 링크를 사용하여 Asignio 서명을 등록합니다.

브라우저가 https://jwt.ms로 리디렉션됩니다. Azure AD B2C에서 반환된 토큰 내용이 표시됩니다.

Asignio 정책 키 만들기

생성된 클라이언트 암호를 Azure AD B2C 테넌트에 저장합니다.
Azure Portal에 로그인합니다.
포털 도구 모음에서 디렉터리 + 구독을 선택합니다.
포털 설정 | 디렉터리 + 구독의 디렉터리 이름 목록에서 Azure AD B2C 디렉터리를 찾습니다.
전환을 선택합니다.
Azure Portal의 왼쪽 위에서 모든 서비스를 선택합니다.
Azure AD B2C를 검색하고 선택합니다.
개요 페이지에서 ID 경험 프레임워크를 선택합니다.
정책 키를 선택합니다.
추가를 선택합니다.
옵션에서 수동을 선택합니다.
정책 키의 정책 키 이름을 입력합니다. 접두사 B2C_1A_가 키 이름에 추가됩니다.
비밀에 기록해 둔 클라이언트 암호를 입력합니다.
키 사용으로는 서명을 선택합니다.
만들기를 실행합니다.

Asignio를 ID 공급자로 구성

팁

시작하기 전에 Azure AD B2C 정책이 구성되어 있는지 확인합니다. 구성되어 있지 않은 경우 사용자 지정 정책 시작 팩의 지침을 따릅니다.

사용자가 Asignio를 사용하여 로그인하려면 Azure AD B2C에서 엔드포인트를 통해 통신하는 클레임 공급자로 Asignio를 정의합니다. 엔드포인트는 Azure AD B2C가 디바이스에서 디지털 ID를 사용하여 사용자 인증을 확인하는 데 사용하는 클레임을 제공합니다.

Asignio를 클레임 공급자로 추가

GitHub에서 사용자 지정 정책 스타터 팩을 가져온 다음, Azure AD B2C 테넌트 이름을 사용하여 LocalAccounts 스타터 팩의 XML 파일을 업데이트합니다.

zip active-directory-b2c-custom-policy-starterpack을 다운로드하거나 리포지토리를 복제합니다.
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
LocalAccounts 디렉터리의 파일에서 문자열 yourtenant를 Azure AD B2C 테넌트 이름으로 바꿉니다.
LocalAccounts/ TrustFrameworkExtensions.xml을 엽니다.
ClaimsProviders 요소를 찾습니다. 없는 경우 TrustFrameworkPolicy 루트 요소 아래에 추가합니다.

다음 예제와 유사한 새 ClaimsProvider를 추가:

 <ClaimsProvider>
   <Domain>contoso.com</Domain>
   <DisplayName>Asignio</DisplayName>
   <TechnicalProfiles>
     <TechnicalProfile Id="Asignio-Oauth2">
       <DisplayName>Asignio</DisplayName>
       <Description>Login with your Asignio account</Description>
       <Protocol Name="OAuth2" />
       <Metadata>
         <Item Key="ProviderName">authorization.asignio.com</Item>
         <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>
         <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>
         <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>
         <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>
         <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
         <Item Key="HttpBinding">POST</Item>
         <Item Key="scope">openid profile email</Item>
         <Item Key="UsePolicyInRedirectUri">0</Item>
         <!-- Update the Client ID below to the Asignio Application ID -->
         <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
         <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>


         <!-- trying to add additional claim-->
         <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111-->
         <Item Key="11111111-1111-1111-1111-111111111111"></Item>
         <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->
         <Item Key="22222222-2222-2222-2222-222222222222"></Item>
         <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->
         <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->
         <!-- The commented key below specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to     sign in. -->
         <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
       </Metadata>
       <CryptographicKeys>
         <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
       </CryptographicKeys>
       <OutputClaims>
         <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
         <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
         <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
         <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authorization.asignio.com" />
         <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
         <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
         <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
         <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
         <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
       </OutputClaims>
       <OutputClaimsTransformations>
         <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
         <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
         <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
         <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
       </OutputClaimsTransformations>
       <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
     </TechnicalProfile>
   </TechnicalProfiles>
 </ClaimsProvider>

적어둔 Asignio 애플리케이션 ID로 client_id를 설정합니다.
client_secret 섹션을 만든 정책 키로 업데이트합니다. 예: B2C_1A_AsignioSecret
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
```
변경 내용을 저장합니다.

사용자 경험 추가

ID 공급자가 로그인 페이지에 없습니다.

사용자 지정 사용자 경험이 있는 경우 계속해서 신뢰 당사자 정책을 구성하고, 없다면 템플릿 사용자 경험을 복사합니다.
시작 팩에서 LocalAccounts/TrustFrameworkBase.xml을 엽니다.
Id=SignUpOrSignIn이 포함된 UserJourney 요소의 콘텐츠를 찾아서 복사합니다.
LocalAccounts/ TrustFrameworkExtensions.xml을 엽니다.
UserJourneys 요소를 찾습니다. 없는 경우 하나를 추가합니다.
UserJourney 요소 콘텐츠를 UserJourneys 요소의 자식 항목으로 붙여넣습니다.]
사용자 경험 ID의 이름을 바꿉니다. 예: Id=AsignioSUSI.

자세히 알아보기: 사용자 경험

사용자 경험에 ID 공급자 추가

사용자 경험에 새 ID 공급자를 추가합니다.

사용자 경험의 Type=CombinedSignInAndSignUp 또는 Type=ClaimsProviderSelection을 포함하는 오케스트레이션 단계 요소를 찾습니다. 일반적으로 첫 번째 오케스트레이션 단계입니다. ClaimsProviderSelections 요소에는 사용자가 로그인하는 ID 공급자 목록이 있습니다. 요소의 순서는 로그인 단추의 순서를 제어합니다.
ClaimsProviderSelection XML 요소를 추가합니다.
TargetClaimsExchangeId의 값을 친숙한 이름으로 설정합니다.
ClaimsExchange 요소를 추가합니다.
Id를 대상 클레임 교환 ID 값으로 설정합니다.
TechnicalProfileReferenceId 값을 만든 기술 프로필의 ID로 업데이트합니다.

다음 XML은 ID 공급자를 사용하는 사용자 경험의 오케스트레이션을 보여줍니다.

    <UserJourney Id="AsignioSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Check if the user has selected to sign in using one of the social providers -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent            in the token. -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>socialIdpAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect from the user. So, in that case, create the user in the directory if one does not already exist (verified using objectId which would be set from the last step if account was created in the directory. -->
        <OrchestrationStep Order="6" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

신뢰 당사자 정책 구성

신뢰 당사자 정책(예: SignUpSignIn.xml)은 Azure AD B2C가 실행하는 사용자 경험을 지정합니다.

신뢰 당사자에서 DefaultUserJourney 요소를 찾습니다.
ID 공급자를 추가한 사용자 경험 ID와 일치하도록 ReferenceId를 업데이트합니다.

다음 예제에서는 AsignioSUSI 사용자 경험에 대해 ReferenceId가 AsignioSUSI으로 설정됩니다.

   <RelyingParty>
        <DefaultUserJourney ReferenceId="AsignioSUSI" />
        <TechnicalProfile Id="PolicyProfile">
          <DisplayName>PolicyProfile</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
            <OutputClaim ClaimTypeReferenceId="givenName" />
            <OutputClaim ClaimTypeReferenceId="surname" />
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
            <OutputClaim ClaimTypeReferenceId="identityProvider" />
            <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
            <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

사용자 지정 정책 업로드

Azure Portal에 로그인합니다.
포털 도구 모음에서 디렉터리 + 구독을 선택합니다.
포털 설정 | 디렉터리 + 구독의 디렉터리 이름 목록에서 Azure AD B2C 디렉터리를 찾습니다.
전환을 선택합니다.
Azure Portal에서 Azure AD B2C를 검색하고 선택합니다.
정책에서 Identity Experience Framework를 선택합니다.
사용자 지정 정책 업로드를 선택합니다.
변경한 정책 파일 2개를 다음 순서로 업로드합니다.

확장 정책(예: TrustFrameworkExtensions.xml)
신뢰 당사자 정책(예: SignUpOrSignin.xml)

사용자 지정 정책 테스트

Azure AD B2C 테넌트의 정책에서 Identity Experience Framework를 선택합니다.
사용자 지정 정책 아래에서 AsignioSUSI를 선택합니다.
애플리케이션에 등록한 웹 애플리케이션을 선택합니다. 회신 URL은 https://jwt.ms입니다.
지금 실행을 선택합니다.
브라우저가 Asignio 로그인 페이지로 리디렉션됩니다.
로그인 화면이 나타납니다.
아래쪽에서 Asignio 인증을 선택합니다.

Asignio 서명이 있는 경우 Asignio 서명을 사용하여 인증하라는 메시지가 표시됩니다. 그렇지 않은 경우 SMS OTP를 통해 인증할 디바이스 전화번호를 입력합니다. 링크를 사용하여 Asignio 서명을 등록합니다.

브라우저가 https://jwt.ms로 리디렉션됩니다. Azure AD B2C에서 반환된 토큰 콘텐츠가 표시됩니다.

다음을 통해 공유