使用 Azure Active Directory B2C 設定 Asignio 以進行多重要素驗證

這很重要

自 2025 年 5 月 1 日起，Azure AD B2C 將不再可供新客戶購買。在我們的常見問題中深入瞭解。

瞭解如何將 Microsoft Entra ID （Azure AD B2C）驗證與 Asignio 整合。透過這項整合，為客戶提供無密碼、軟式生物識別和多重要素驗證體驗。 Asignio 使用專利的 Asignio 簽章和即時臉部驗證進行用戶驗證。可變更的生物特徵辨識簽章可透過全通路驗證來協助減少密碼、詐騙、網路釣魚和認證重複使用等問題。

開始之前

選擇原則類型選取器，以指出原則類型設定。 Azure AD B2C 有兩種方法可定義使用者與應用程式互動的方式：

預先定義的使用者流程
可設定的自定義原則

本文中的步驟會針對每個方法而有所不同。

瞭解更多資訊：

先決條件

Azure 訂用帳戶。
如果您沒有訂用帳戶，請取得 Azure 免費帳戶

連結至 Azure 訂用帳戶的 Azure AD B2C 租戶
請參閱教學課程：建立 Azure Active Directory B2C 租戶
Asignio 所簽發的 Asignio 用戶端識別碼和客戶端密碼。
這些令牌是透過向 Asignio 註冊您的行動或 Web 應用程式來取得。

針對自訂原則

完成教學課程：在 Azure AD B2C 中建立使用者流程和自定義原則

案例描述

此整合包含下列元件：

Azure AD B2C - 驗證使用者認證的授權伺服器
Web 或行動應用程式 - 使用 Asignio MFA 保護
Asignio Web 應用程式 - 用戶觸控裝置上的簽章生物特徵辨識收集

下圖說明實作。

顯示實作架構的圖表。

使用者在其行動或 Web 應用程式上開啟 Azure AD B2C 登入頁面，然後登入或註冊。
Azure AD B2C 會使用 OpenID Connect （OIDC）要求，將使用者重新導向至 Asignio。
用戶會重新導向至 Asignio Web 應用程式以進行生物特徵辨識登入。如果用戶沒有註冊他們的 Asignio 簽名，他們可以使用 SMS One-Time-Password （OTP）進行身份驗證。驗證之後，使用者會收到註冊連結，以建立其 Asignio 簽章。
使用者會使用 Asignio 簽章和臉部驗證，或語音和臉部驗證進行驗證。
挑戰的回應會傳送給 Asignio。
Asignio 將 OIDC 回應傳回給 Azure AD B2C 的登入程序。
Azure AD B2C 會將驗證驗證要求傳送至 Asignio，以確認收到驗證數據。
使用者會被授與或拒絕應用程式存取權。

使用 Asignio 設定應用程式

使用 Asignio 設定應用程式需透過 Asignio 合作夥伴管理網站進行。

若要要求貴組織的存取權，請移至 asignio.com Asignio 合作夥伴管理頁面。
使用認證登入 Asignio 合作夥伴系統管理。
使用 Azure AD B2C 租用戶，為 Azure AD B2C 應用程式建立記錄。當您搭配 Asignio 使用 Azure AD B2C 時，Azure AD B2C 會管理連線的應用程式。 Asignio 應用程式代表 Azure 入口網站中的應用程式。
在 Asignio 合作夥伴管理網站中，產生用戶端識別碼和客戶端密碼。
記下並儲存用戶端識別碼和客戶端密碼。您稍後會用到這些。 Asignio 不會儲存客戶端密碼。
在您的網站上指定重新導向的 URI，使用者會在驗證之後被重定向到該 URI。使用下列 URI 模式。

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

上傳公司標誌。當使用者登入時，它會出現在 Asignio 驗證上。

在 Azure AD B2C 中註冊 Web 應用程式

在您所管理的租用戶中註冊應用程式，然後他們可以與 Azure AD B2C 互動。

深入瞭解：可在Active Directory B2C 中使用的應用程式類型

在本教學課程中，您要註冊的 https://jwt.ms 是一個 Microsoft Web 應用程式，它的已解碼令牌內容不會離開您的瀏覽器。

註冊 Web 應用程式

完成教學課程：在 Azure Active Directory B2C 中註冊 Web 應用程式一文中的步驟。

在 Azure AD B2C 中將 Asignio 設定為識別提供者

如需以下指示，請使用 Microsoft Entra 租用戶搭配 Azure 訂用帳戶。

至少以 Azure AD B2C 租用戶的 B2C IEF 原則管理員身分登入 Azure 入口網站。
在 Azure 入口網站工具列中，選取 [ 目錄 + 訂用帳戶]。
在 入口網站設定 | 目錄 + 訂閱中，在 目錄名稱 清單中，找出您的 Microsoft Entra 目錄。
選取 [切換]。
在 Azure 入口網站的左上角，選取 [所有服務]。
搜尋並選取 [Azure AD B2C]。
在 Azure 入口網站中，搜尋並選取 [Azure AD B2C]。
在左側功能表中，選取 [ 識別提供者]。
選取 新增 OpenID Connect 提供者。
選取 [識別提供者類型>OpenID Connect]。
針對名稱，輸入 Asignio 登入資訊，或您選擇的名稱。
針對 [元數據 URL]，輸入 https://authorization.asignio.com/.well-known/openid-configuration。
針對 [用戶端識別碼]，輸入您產生的用戶端識別碼。
針對 [客戶端密碼]，輸入您產生的客戶端密碼。
針對 [範圍]，使用 openid 電子郵件設定檔。
針對 [回應類型]，請使用 程序代碼。
針對 [回應模式]，請使用查詢。
請在「網域提示」中使用 https://asignio.com。
請選擇 [確定]。
選取 [對應此身分識別提供者的宣告]。
對於 [使用者識別碼]，使用 sub。
針對 [顯示名稱]，請使用 name。
針對 [指定名稱]，請使用 given_name。
針對 Surname，請使用 family_name。
對於 [電子郵件]，使用 email。
選取 [儲存]。

建立使用者流程原則

在您的 Azure AD B2C 租戶中，於 [原則] 底下，選取 [使用者流程]。
選取 新使用者流程。
選取 [註冊並登入 使用者流程類型]。
選取 [建議的版本]。
選取 ，創建。
輸入使用者流程名稱，例如 AsignioSignupSignin。
在 [ 識別提供者] 底下，針對 [ 本機帳戶]，選取 [ 無]。此動作會停用電子郵件和密碼驗證。
針對 [自訂識別提供者]，選取已建立的 Asignio Identity 提供者。
選取 ，創建。

測試您的使用者流程

在 Azure AD B2C 租用戶中，選取 [使用者流程]。
選取已建立的使用者流程。
針對 [應用程式]，選取您註冊的 Web 應用程式。 回覆 URL 為 https://jwt.ms。
選取 [執行使用者流程]。
瀏覽器會重新導向至 Asignio 登入頁面。
登入畫面隨即出現。
在底部，選取 [Asignio] 驗證。

如果您有 Asignio 簽章，請完成驗證的提示。如果沒有，請提供裝置電話號碼，以透過SMS OTP進行驗證。使用連結來註冊您的 Asignio 簽章。

瀏覽器會重新導向至 https://jwt.ms。 Azure AD B2C 傳回的令牌內容隨即出現。

建立 Asignio 政策金鑰

將產生的客戶端密碼儲存在 Azure AD B2C 租使用者中。
登入 Azure 入口網站。
在入口網站工具列中，選取 [目錄 + 訂用帳戶]。
在 入口網站設定上 |目錄 + 訂用帳戶，在 [目錄名稱] 清單中，找出您的 Azure AD B2C 目錄。
選取 [切換]。
在 Azure 入口網站的左上角，選取 [所有服務]。
搜尋並選取 [Azure AD B2C]。
在 [概觀] 頁面上，選取 [ 身分識別體驗架構]。
選取 [原則金鑰]。
選取 ，然後新增。
針對 [選項]，選取 [ 手動]。
輸入政策金鑰的名稱。前置詞 B2C_1A_ 會附加至索引鍵名稱。
在 [ 秘密] 中，輸入您注意到的 [客戶端密碼]。
針對 [ 金鑰使用方式]，選取 [ 簽章]。
選取 ，創建。

將 Asignio 設定為識別提供者

小提示

開始之前，請確定已設定 Azure AD B2C 原則。如果沒有，請遵循自定義原則入門套件中的指示。

若要讓使用者使用 Asignio 登入，請將 Asignio 定義為 Azure AD B2C 透過端點進行通訊的宣告提供者。端點提供宣告，Azure AD B2C 用來使用裝置上的數位識別碼來確認使用者驗證。

將 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">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
         <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>


         <!-- trying to add additional claim-->
         <!--Insert b2c-extensions-app application ID here, for example: 00001111-aaaa-2222-bbbb-3333cccc4444-->
         <Item Key="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
         <!--Insert b2c-extensions-app application ObjectId here, for example: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb-->
         <Item Key="aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"></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/00001111-aaaa-2222-bbbb-3333cccc4444</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 應用程式識別碼來設定 client_id 。
使用您所建立的原則金鑰更新 client_secret 區段。例如，B2C_1A_AsignioSecret：
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
```
儲存變更。

新增使用者旅程圖

身分識別提供者不在登入頁面中。

如果您有自定義的使用者旅程，請繼續設定信任方策略；否則，請複製範本使用者流程。
從初學者包中，打開 LocalAccounts/ TrustFrameworkBase.xml。
找出並複製包含 Id=SignUpOrSignIn 元素的內容。
開啟 LocalAccounts/ TrustFrameworkExtensions.xml。
找出 UserJourneys 元素。如果沒有，請新增一個。
將 UserJourney 元素內容貼上作為 UserJourneys 元素的子項目。
重新命名使用者旅程 ID。例如： Id=AsignioSUSI 。

深入瞭解：使用者旅程圖

將識別提供者新增至使用者旅程圖

將新的識別提供者新增至使用者旅程圖。

在使用者旅程圖中，尋找包含 Type=CombinedSignInAndSignUp 或 Type=ClaimsProviderSelection 的協調流程步驟元素。這通常是第一個協調流程步驟。 ClaimsProviderSelections 元素具有使用者用來登入的識別提供者清單。元素的順序會控制登入按鈕的順序。
新增 ClaimsProviderSelection XML 元素。
將 TargetClaimsExchangeId 的值設定為易記名稱。
新增 ClaimsExchange 元素。
將識別碼設定為目標宣告交換識別碼的值。
將 TechnicalProfileReferenceId 的值更新為您所建立技術設定檔的識別碼。

下列 XML 示範使用者旅程與識別提供者的協調。

    <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 元素。
將 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 入口網站。
在入口網站工具列中，選取 [目錄 + 訂用帳戶]。
在 入口網站設定上 |目錄 + 訂用帳戶，在 [目錄名稱] 清單中，找出您的 Azure AD B2C 目錄。
選取 [切換]。
在 Azure 入口網站中，搜尋並選取 [Azure AD B2C]。
在 [原則] 底下，選取 [ 身分識別體驗架構]。
選取上傳客製化政策。
上傳您依下列順序變更的兩個原則檔案：

擴充原則，例如 TrustFrameworkExtensions.xml
信賴憑證者原則，例如 SignUpOrSignin.xml

測試您的自定義原則

在您的 Azure AD B2C 租戶中，於 [原則] 底下，選取 [身分識別體驗架構]。
在 [自定義原則] 底下，選取 [AsignioSUSI]。
針對 [應用程式]，選取您註冊的 Web 應用程式。 回覆 URL 為 https://jwt.ms。
選取 [立即執行]。
瀏覽器會重新導向至 Asignio 登入頁面。
登入畫面隨即出現。
在底部，選取 [Asignio] 驗證。

如果您有 Asignio 簽章，系統會提示您使用您的 Asignio 簽章進行驗證。如果沒有，請提供裝置電話號碼，以透過SMS OTP進行驗證。使用連結來註冊您的 Asignio 簽章。

瀏覽器會重新導向至 https://jwt.ms。 Azure AD B2C 傳回的令牌內容隨即出現。

後續步驟

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-12-18