使用 Azure Active Directory B2C 設定 Trusona Authentication Cloud

這很重要

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

在本範例教學課程中，您將瞭解如何整合 Azure AD B2C 驗證與 Trusona Authentication Cloud。 這是一項雲端式服務，可讓使用者使用 點選和移至 體驗進行驗證，而不需要任何類型的行動驗證器應用程式。

將 Trusona Authentication Cloud 與 Azure AD B2C 整合的優點包括：

• 以更佳的用戶體驗提供強式驗證

  • 較快樂的用戶，他們花更多的時間在線上
  • 降低流失和放棄，增加收入
  • 較高的保留期、存留期值 （LTV）

• 降低企業執行成本

  • 減少帳戶接管和帳戶共用
  • 減少詐騙並降低手動的詐騙分析操作頻率
  • 減少外包手動檢閱的支出

• 消除密碼

  • 不再重設密碼
  • 減少客服中心投訴
  • 使用通行密鑰進行快速、簡單、順暢的登入

先決條件

若要開始使用，您需要：

• Trusona Authentication Cloud 試用帳戶。 若要要求帳戶， 請連絡 Trusona。
• Azure 訂用帳戶。 如果您沒有訂用帳戶，可以取得免費帳戶。
• 連結至 Azure 訂用帳戶的 Azure AD B2C 租戶。

• 完成開始使用 Azure AD B2C 中的自定義原則一文中的步驟。

案例描述

Web 驗證標準 - WebAuthn 會實作新式作系統和瀏覽器，以支援透過手指列印、Windows hello 或外部 FIDO 裝置進行驗證，例如 USB、藍牙和一次性密碼 （OTP）。

在此案例中，Trusona 會作為 Azure AD B2C 的識別提供者（IdP）來啟用無密碼驗證。 下列元件組成解決方案：

• Azure AD B2C 合併登入與註冊策略。
• Trusona Authentication Cloud 已新增至 Azure AD B2C 作為 IdP。

步驟	說明
1.	用戶嘗試透過瀏覽器登入 Web 應用程式。
2.	Web 應用程式會重新導向至 Azure AD B2C 註冊和登入原則。
3.	Azure AD B2C 會將使用者重新導向驗證至 Trusona Authentication Cloud OpenID Connect （OIDC） IdP。
4.	使用者會看到要求輸入其使用者名稱的登入網頁，通常是電子郵件位址。
5.	使用者輸入其電子郵件地址，然後選取 [ 繼續] 按鈕。 如果在 Trusona Authentication Cloud 中找不到使用者帳戶，則會將回應傳送至瀏覽器，以在裝置上起始 WebAuthn 註冊程式。 否則，回應會傳送至開始 WebAuthn 驗證程式的瀏覽器。
6.	系統會要求用戶選取要使用的認證。 通行碼與網路應用程式的網域或硬體安全金鑰相關聯。 用戶選取認證之後，OS 會要求使用者使用生物特徵辨識、密碼或 PIN 來確認其身分識別。 這將啟用 Secure Enclave/Trusted Execution 環境，並產生由與所選憑證相關聯的私鑰所簽署的身份驗證聲明。
7.	驗證判斷提示會傳回 Trusona 雲端服務以進行驗證。
8.	驗證之後，Trusona Authentication Cloud （IdP） 會建立 OIDC 標識符令牌，然後將它轉送至 Azure AD B2C（服務提供者）。 Azure AD B2C 會根據 Trusona 的 OpenID 探索檔中的值，驗證令牌和簽發者的簽章。 這些詳細數據是在 IdP 設定期間設定的。 驗證之後，Azure AD B2C 會發出 OIDC id_token（視範圍而定），並使用令牌將使用者重新導向回起始的應用程式。
9.	Web 應用程式（或其用來實作驗證的開發人員連結庫）會擷取令牌，並驗證 Azure AD B2C 令牌的真實性。 如果是這種情況，它會擷取宣告，並將其傳遞至 Web 應用程式以取用。
10.	驗證時，會授與/拒絕使用者存取權。

步驟 1：使用 Trusona Authentication Cloud 上線

1. 登入 Trusona 入口網站。

2. 從左側導覽面板中，選取 [ 設定]

3. 在 [設定] 功能表中，選取滑桿以 啟用 OIDC。

4. 選取適當的 輸入 ，並提供 重新導向URLhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp。

5. 產生 秘密金鑰，並 複製 金鑰以用於您的 Azure AD B2C 設定。

   備註

   1. Trusona 入口網站支援自助式註冊。 註冊之後，系統會將您指派給具有只讀許可權的 Trusona 帳戶。 之後，Trusona 會將您指派到正確的帳戶，並根據您組織的門戶使用者訪問控制原則，將您的許可權提升至讀寫許可權。
   2. Microsoft Entra ID 的初始網域名稱用作用戶端重新導向的主機。

   

步驟 2：在 Azure AD B2C 中註冊 Web 應用程式

您的應用程式必須先在您的客戶租用戶中註冊後，才能與 Azure AD B2C 互動。 本教學課程說明如何使用 Azure 入口網站註冊 Web 應用程式。 基於本教學課程等測試目的，您要註冊 https://jwt.ms，這是一個Microsoft擁有的 Web 應用程式，其會顯示令牌譯碼的內容（令牌的內容永遠不會離開瀏覽器）。 若要在您的 Azure AD B2C 租用戶中註冊 Web 應用程式，請使用我們新的整合應用程式註冊體驗。

1. 登入 Azure 入口網站。

2. 如果您有多個租用戶的存取權，請使用頂端功能表中的 [設定] 圖示，從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租用戶。

3. 在 Azure 入口網站中，搜尋並選取 [Azure AD B2C]。

4. 選取 [應用程式註冊]，然後選取 [[新增註冊]。

5. 輸入應用程式的 [名稱]。 例如 ，jwt ms。

6. 在 支援的帳戶類型下，選取 任何身分提供者或組織目錄中的帳戶（用於驗證具有使用者流程的使用者）。

7. 在 [重新導向 URI] 底下，選取 [Web]，然後在 [URL] 文本框中輸入 https://jwt.ms 。

   重新導向 URI 是授權伺服器所在的端點，在此情況下，Azure AD B2C 會將用戶傳送至該端點。 完成與用戶的互動之後，會在成功授權時傳送存取令牌或授權碼。 在實際執行應用程式中，其通常是您應用程式執行所在之可公開存取的端點，例如 https://contoso.com/auth-response。 基於本教學課程等測試目的，您可以將它設定為 https://jwt.ms，這是一個Microsoft擁有的Web應用程式，其會顯示令牌的已譯碼內容（令牌的內容永遠不會離開瀏覽器）。 在應用程式開發期間，您可能會新增一個應用程式本機接聽的端點，例如 https://localhost:5000。 您可以隨時在已註冊的應用程式中新增及修改重新導向 URI。

   下列限制適用於重新導向統一資源標識碼 （URI）：

   • 除非您使用 localhost 重新導向 URL，否則回覆 URL 的開頭必須是配置 https。
   • 回覆 URL 會區分大小寫。 其大小寫必須符合您執行中應用程式之 URL 路徑的大小寫。 例如，如果您的應用程式在其路徑 .../abc/response-oidc中包含 ，請勿在回覆 URL 中指定 .../ABC/response-oidc 。 因為網頁瀏覽器會將路徑視為區分大小寫，因此如果重新導向至.../abc/response-oidc的大小寫不相符的 URL，則與.../ABC/response-oidc相關聯的 Cookie 可能會被排除。
   • 回覆 URL 應該包括或排除結尾正斜線，因為您的應用程式預期該字元。 例如， https://contoso.com/auth-response 和 https://contoso.com/auth-response/ 可能會被視為應用程式中的非相符URL。

8. 在 [許可權]下，選取 [授予管理員對 openid 和 offline_access 許可權的同意] 複選框。

9. 選取 註冊。

啟用身份令牌隱式授權

您可以啟用隱含授與流程，以使用此應用程式註冊來 測試使用者流程以供測試之用。

1. 選取您建立的應用程式註冊。

2. 在 [管理] 底下，選取 [驗證]。

3. 在 [隱含授與和混合式流程] 下，選取 [存取權杖 (用於隱含流程)] 和 [識別碼權杖 (用於隱含和混合式流程)] 核取方塊。

4. 選取 [儲存]。

備註

如果您啟用隱含授與來測試使用者流程，請務必先停用隱含授與流程設定，再將應用程式部署至生產環境。

步驟 3：在 Azure AD B2C 中將 Trusona Authentication Cloud 設定為 IdP

1. 以外部識別提供者管理員和 B2C 使用者流程管理員角色身分，登入到您的 Azure AD B2C 租戶中的 Azure 入口網站。

2. 如果您有多個租用戶的存取權，請使用頂端功能表中的 [設定] 圖示，從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租用戶。

3. 選擇 Azure 入口網站左上角 的 [所有服務 ]，搜尋並選取 [Azure AD B2C]。

4. 導航至 儀錶板>Azure Active Directory B2C>識別提供者。

5. 選擇「 標識提供者」。

6. 選取 ，然後新增。

設定IdP

1. 選取 [識別提供者類型>OpenID Connect][預覽]。

2. 填寫表單以設定 IdP：

   房產	價值觀
   元數據 URL	https://authcloud.trusona.net/.well-known/openid-configuration
   用戶端識別碼	可在 Trusona Authentication Cloud 入口網站上取得
   客戶端密碼	可在 Trusona Authentication Cloud 入口網站上取得
   影響範圍	OpenID 個人資料電子郵件
   回應類型	程式碼
   回應模式	表單提交

3. 請選擇 [確定]。

4. 選取 [對應此識別提供者的宣告]。

5. 若要映射 IdP，請填寫表單：

   房產	價值觀
   UserID	分支
   顯示名稱	昵稱
   名字	given_name
   姓氏	姓氏
   回應模式	電子郵件

6. 選取 [確定 ] 以完成新 OIDC IdP 的設定。

步驟 4：建立使用者流程原則

您現在應該會在 B2C IdPs 中看到 Trusona 被列為新的 OpenID Connect 識別提供者。

1. 在您的 Azure AD B2C 租戶中，於 [原則] 底下，選取 [使用者流程]。

2. 選取 新使用者流程。

3. 選取 [註冊並登入]，選取版本，然後選取 [ 建立]。

4. 為您的政策輸入名稱。

5. 在 [ 識別提供者 ] 區段中，選取新建立的 Trusona Authentication Cloud-Identity Provider。

   備註

   由於 Trusona 天生具備多重驗證功能，因此最好不要啟用額外的多重驗證功能。

6. 選取 ，創建。

7. 在 [用戶屬性和宣告] 下，選擇 [顯示更多]。 在表單中，選取您在上一節中設定識別提供者期間指定的至少一個屬性。

8. 請選擇 [確定]。

步驟 5：測試您的使用者流程

1. 選取您建立的政策。

2. 選取 [執行使用者流程]，然後選取設定：

   一。 應用程式：選取已註冊的應用程式，例如 jwt ms。

   b。 回覆 URL：選取重新導向 URL， 例如 https://jwt.ms。

3. 選取執行使用者流程。 您應該重新導向至 Trusona Authentication Cloud。 使用者會看到要求輸入其使用者名稱的登入網頁，通常是電子郵件位址。 如果在 Trusona Authentication Cloud 中找不到使用者帳戶，則會將回應傳送至瀏覽器，以在裝置上起始 WebAuthn 註冊程式。 否則，回應會傳送至開始 WebAuthn 驗證程式的瀏覽器。 系統會要求用戶選取要使用的認證。 通行碼與網路應用程式的網域或硬體安全金鑰相關聯。 用戶選取認證之後，OS 會要求使用者使用生物特徵辨識、密碼或 PIN 來確認其身分識別。 這將啟用 Secure Enclave/Trusted Execution 環境，並產生由與所選憑證相關聯的私鑰所簽署的身份驗證聲明。 Azure AD B2C 會驗證 Trusona 驗證回應，併發出 OIDC 令牌。 它會將使用者重新導向回起始的應用程式，例如 ， https://jwt.ms其會顯示 Azure AD B2C 所傳回之令牌的內容。

步驟 3：建立 Trusona Authentication Cloud 原則密鑰

先前在 步驟 1 中產生的客戶端密碼儲存在您的 Azure AD B2C 租用戶中。

1. 登入 Azure 入口網站。

2. 如果您有多個租用戶的存取權，請使用頂端功能表中的 [設定] 圖示，從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租用戶。

3. 選擇 Azure 入口網站左上角 的 [所有服務 ]，然後搜尋並選取 [Azure AD B2C]。

4. 在 [概觀] 頁面上，選取 [ 身分識別體驗架構]。

5. 選取 [原則密鑰 ]，然後選取 [ 新增]。

6. 針對 [選項]，選擇 [ 手動]。

7. 輸入政策金鑰的名稱。 例如： TrusonaTacClientSecret 。 前置詞 B2C_1A_ 會自動新增至金鑰的名稱。

8. 在 [ 秘密] 中，輸入您先前記錄的客戶端密碼。

9. 針對 [ 金鑰使用方式]，選取 Signature。

10. 選取 ，創建。

步驟 4：將 Trusona Authentication Cloud 設定為 IdP

小提示

此時您應該已設定 Azure AD B2C 原則。 如果不是，請遵循 指示，了解如何設定 Azure AD B2C 租戶並配置政策。

若要讓使用者使用 Trusona Authentication Cloud 登入，您必須將 Trusona 定義為 Azure AD B2C 可以透過端點進行通訊的宣告提供者。 端點提供一組宣告，供 Azure AD B2C 用來驗證特定使用者已使用其裝置上可用的複雜密鑰或硬體安全性金鑰進行驗證，證明使用者的身分識別。

使用下列步驟將 Trusona 新增為宣告提供者：

1. 從 GitHub 取得自定義原則入門套件，然後使用您的 Azure AD B2C 租使用者名稱更新 LocalAccounts 入門套件中的 XML 檔案：

   1. 下載 .zip 檔案 或複製存放庫：

          git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
      

   2. 在 LocalAccounts 目錄中的所有檔案中，以 Azure AD B2C 租使用者的名稱取代字串 yourtenant 。 例如，如果 B2C 租使用者的名稱是 contoso，則所有 yourtenant.onmicrosoft.com 的實例都會變成 contoso.onmicrosoft.com。

2. 開啟 LocalAccounts/TrustFrameworkExtensions.xml。

3. 尋找 ClaimsProviders 元素。 如果不存在，請將它新增至根元素底下。 TrustFrameworkPolicy

4. 新增類似如下所示的新 ClaimsProvider ：

<ClaimsProvider>
  <Domain>TrusonaTAC</Domain>
  <DisplayName>Trusona TAC</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="TrusonaTAC-OpenIdConnect">
      <DisplayName>TrusonaTAC</DisplayName>
      <Description>Login with your Trusona TAC  account</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="METADATA">https://authcloud.trusona.net/.well-known/openid-configuration</Item>
        <Item Key="scope">openid profile email</Item>
         <!-- Update the Client ID to the Trusona Authentication Cloud Application ID -->
         <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
        <Item Key="response_types">code</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</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="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
        <!-- The key allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs for each tenant. -->
        <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/187f16e9-81ab-4516-8db7-1c8ef94ffeca,https://login.microsoftonline.com/00001111-aaaa-2222-bbbb-3333cccc4444</Item>-->
        <!-- The commented key 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>
       <!-- Update the Client Secret to the Trusona Authentication Cloud Client Secret Name -->
        <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacSecret" />
      </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://authcloud.trusona.net/" />
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="email" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

1. 使用您先前在步驟 1 中記錄的 Trusona Authentication Cloud 應用程式標識碼來設定client_id。

2. 使用步驟 3 中建立的原則金鑰名稱更新client_secret區段。 例如，B2C_1A_TrusonaTacClientSecret：

   <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
   

3. 儲存變更。

步驟 5：新增使用者旅程圖

此時，您已設定 IdP，但尚未在任何登入頁面中顯示。 如果您有自己的自定義使用者旅程，請繼續進行步驟 6；否則，請複製現有範本使用者旅程，如下所示：

1. 開啟入門套件中的LocalAccounts/TrustFrameworkBase.xml檔案。

2. 尋找並複製包含 之 Id=SignUpOrSignIn 元素的整個內容。

3. 開啟LocalAccounts/TrustFrameworkExtensions.xml 並尋找 UserJourneys 元素。 如果元素不存在，新增一個。

4. 貼上您複製為 UserJourneys 元素子系之 UserJourney 元素的整個內容。

5. 使用者旅程的Id重新命名。 例如： Id=TrusonaTacSUSI 。

步驟 6：將 IdP 新增至使用者旅程圖

現在您已擁有使用者旅程圖，請將新的 IdP 新增至使用者旅程圖。

1. 尋找使用者旅程中包含 Type=CombinedSignInAndSignUp 或 Type=ClaimsProviderSelection 的協調流程步驟元素。 通常是第一個編排流程步驟。 ClaimsProviderSelections 元素包含使用者可以登入的 IdP 清單。 元素的順序會控制向用戶呈現的登入按鈕順序。 新增 ClaimsProviderSelection XML 元素。 將 TargetClaimsExchangeId 的值設定為易記名稱，例如 TrusonaTacExchange。

2. 在下一個協調流程步驟中，新增 ClaimsExchange 元素。 將ID設置為目標宣告交換標識碼的值。 將 TechnicalProfileReferenceId 的值更新為您稍早建立之技術設定檔的識別碼，例如 ， TrusonaTAC-OpenIdConnect。

下列 XML 展示身分識別提供者中使用者旅程的協調流程：

    <UserJourney Id="TrusonaTacSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="TrusonaTacExchange" />
            <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="TrusonaTacExchange" TechnicalProfileReferenceId="TrusonaTAC-OpenIdConnect" />
            <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 (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>

深入了解 使用者旅程。

步驟 7：設定信賴方政策

信賴方政策，例如 SignUpSignIn.xml，會指定 Azure AD B2C 執行的使用者旅程。 尋找信賴憑證者內的 DefaultUserJourney 元素。 更新 ReferenceId 以符合您新增識別提供者的使用者旅程圖標識碼。

在下列範例中 Trusona Authentication Cloud ，針對使用者旅程圖， ReferenceId 會設定為 TrusonaTacSUSI：

   <RelyingParty>
        <DefaultUserJourney ReferenceId="TrusonaTacSUSI" />
        <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>

步驟 8：上傳自定義原則

1. 登入 Azure 入口網站。

2. 如果您有多個租用戶的存取權，請使用頂端功能表中的 [設定] 圖示，從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租用戶。

3. 在 Azure 入口網站中，搜尋並選取 [Azure AD B2C]。

4. 在 [原則] 底下，選取 [ 身分識別體驗架構]。

5. 選取 [上傳自定義原則]，然後上傳您變更的兩個原則檔案，順序如下：擴充原則，例如 TrustFrameworkExtensions.xml，然後是信賴憑證者原則，例如 SignUpOrSignin.xml。

步驟 9：測試您的自定義原則

1. 在您的 Azure AD B2C 租戶中，於 [原則] 下選取 [身分識別體驗架構]。

2. 在 [自定義原則] 底下，選取 [TrusonaTacSUSI]。

3. 針對 [應用程式]，選取您先前註冊為本文必要條件一部分的 Web 應用程式。 例如 jwt ms。 Reply URL 應顯示 https://jwt.ms。

4. 選取 [立即執行]。 您的瀏覽器應該重新導向至 Trusona Authentication Cloud 登入頁面。

5. 顯示登入畫面，底部應有一個透過 Trusona 驗證雲端 進行驗證的按鈕。

6. 您應該重新導向至 Trusona Authentication Cloud。 使用者會看到要求輸入其使用者名稱的登入網頁，通常是電子郵件位址。 如果在 Trusona Authentication Cloud 中找不到使用者帳戶，則會將回應傳送至瀏覽器，以在裝置上起始 WebAuthn 註冊程式。 否則，回應會傳送至開始 WebAuthn 驗證程式的瀏覽器。 系統會要求用戶選取要使用的認證。 通行碼與網路應用程式的網域或硬體安全金鑰相關聯。 用戶選取認證之後，OS 會要求使用者使用生物特徵辨識、密碼或 PIN 來確認其身分識別。 這將啟用 Secure Enclave/Trusted Execution 環境，並產生由與所選憑證相關聯的私鑰所簽署的身份驗證聲明。

7. 如果登入程式成功，您的瀏覽器會重新導向至 https://jwt.ms，以顯示 Azure AD B2C 所傳回令牌的內容。

後續步驟

如需詳細資訊，請檢閱下列文章：

• Azure AD B2C 文件

• 在 Stack Overflow 上詢問您的問題

• Azure AD B2C 範例

• Azure AD B2C YouTube 訓練播放清單

• Azure AD B2C 中的自定義原則

• 開始使用 Azure AD B2C 中的自定義原則