为用户注册流程添加 API 连接器

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

2025-04-30

重要

自 2025 年 5 月 1 日起，Azure AD B2C 将不再可供新客户购买。在我们的常见问题解答中了解详细信息。

在开始之前，请使用此页面顶部的 “选择策略类型 选择器”来选择要设置的策略类型。 Azure Active Directory B2C 提供了两种方法来定义用户如何与应用程序交互：通过预定义的用户流或通过完全可配置的自定义策略。对于每种方法，本文中所需的步骤都不同。

作为开发人员或 IT 管理员，可以使用 API 连接器将注册用户流与 REST API 集成，以自定义注册体验并与外部系统集成。在本演练结束时，你将能够创建一个 Azure AD B2C 用户流，该流与 REST API 服务交互以修改注册体验。

可以使用我们的示例之一创建 API 终结点。

在此方案中，我们将向用户添加在 Azure AD B2C 注册页中输入会员号码的功能。 REST API 验证电子邮件和会员号码的组合是否映射到促销代码。如果 REST API 找到此用户的促销代码，它将返回到 Azure AD B2C。最后，促销代码将插入到令牌声明中，以供应用程序使用。

也可以将交互设计为业务流程步骤。当 REST API 不会在屏幕上验证数据并且始终返回声明时，这很合适。有关详细信息，请参阅演练：将 REST API 声明交换作为业务流程步骤集成到 Azure AD B2C 用户旅程中。

先决条件

创建用户流，以便用户可以注册并登录到应用程序。
注册 Web 应用程序。

完成 Active Directory B2C 中的自定义策略入门中的步骤。本教程指导你如何更新自定义策略文件以使用 Azure AD B2C 租户配置。
注册 Web 应用程序。

创建 API 连接器

若要使用某个 API 连接器，首先需要创建该 API 连接器，然后在用户流中启用它。

登录到 Azure 门户。
在“Azure 服务”下，选择“Azure AD B2C”。
选择 API 连接器，然后选择 “新建 API 连接器”。
为调用提供显示名称。例如， 验证用户信息。
为 API 调用提供“终结点 URL”。
选择“身份验证类型”，并配置用于调用 API 的身份验证信息。了解如何保护 API 连接器。
选择“ 保存”。

发送到 API 的请求

API 连接器具体化为 HTTP POST 请求，在 JSON 正文中以键值对的形式发送用户特性（“声明”）。特性的序列化方式与 Microsoft Graph 用户属性类似。

示例请求

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "<step-name>",
 "client_id":"00001111-aaaa-2222-bbbb-3333cccc4444",
 "ui_locales":"en-US"
}

只有 Azure AD B2C>用户属性 体验中列出的用户属性和自定义属性才能在请求中发送。

自定义属性存在于 目录中的 extension_<extensions-app-id>_CustomAttribute 格式中。你的 API 应期望收到相同序列化格式的声明。有关自定义属性的详细信息，请参阅在 Azure AD B2C 中定义自定义属性。

此外，这些声明通常在所有请求中发送：

UI 区域设置（“ui_locales”）- 终端用户在其设备上配置的区域设置。 API 可以使用这个来返回国际化的响应。
步骤（“step”）- 调用 API 连接器的用户流上的步骤或点。值包括：
- PostFederationSignup - 对应于“在注册期间与标识提供者进行联合之后”
- PostAttributeCollection - 对应于“创建用户之前”
- PreTokenIssuance - 对应于“发送令牌之前（预览版）”。详细了解此步骤
客户端 ID（“client_id”）- 最终用户在用户流中进行身份验证的应用程序的值。appId 这不是资源应用程序在访问令牌中的。appId
电子邮件地址（“email”）或标识（“identities”）- API 可以使用这些声明来标识向应用程序进行身份验证的最终用户。

重要

如果调用 API 终结点时某个声明没有值，则不会将该声明发送到 API。你的 API 应被设计为显式检查和处理请求中缺少声明的情况。

在用户流中启用 API 连接器

按照以下步骤将 API 连接器添加到注册用户流。

登录到 Azure 门户。
在“Azure 服务”下，选择“Azure AD B2C”。
选择“用户流”，然后选择要将 API 连接器添加到的用户流。
选择“API 连接器”，然后选择要在执行用户流中的以下步骤时调用的 API 终结点：
- 在注册期间与标识提供者进行联合后
- 创建用户之前
- 发送令牌之前（预览版）
选择“ 保存”。

这些步骤仅适用于 注册和登录（推荐） 和 注册（推荐）， 但仅适用于体验的注册部分。

注册过程中此步骤中的 API 连接器在用户使用标识提供者（如 Google、Facebook 和 Microsoft Entra ID）进行身份验证后立即调用。此步骤优先于属性集合页，后者是向用户显示的用于收集用户属性的表单。如果用户正在向本地帐户注册，则不会调用此步骤。

执行此步骤时发送到 API 的示例请求

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [ 
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "step": "PostFederationSignup",
 "client_id":"<guid>",
 "ui_locales":"en-US"
}

发送到 API 的确切声明取决于标识提供者提供的信息。始终会发送“email”。

执行此步骤时来自 Web API 的预期响应类型

在运行用户流期间当 Web API 从 Microsoft Entra ID 收到 HTTP 请求时，它可以返回以下响应：

继续响应
阻止响应

继续响应

继续响应表示用户流应继续下一步：特性收集页。

在继续响应中，API 可以返回声明。如果 API 返回了某个声明，该声明将执行以下操作：

预先填充特性收集页中的输入字段。

参阅继续响应的示例。

拦截响应

收到阻止响应会退出用户流。 API 可以有目的性地发出阻止响应，通过向用户显示一个阻止页来停止用户流的继续运行。阻止页将显示 API 提供的 userMessage。

参阅阻止响应的示例。

创建用户之前

在注册过程的此步骤中，在显示属性集合页之后，将调用 API 连接器（如果包含了连接器）。在创建用户帐户之前始终会调用此步骤。

执行此步骤时发送到 API 的示例请求

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "PostAttributeCollection",
 "client_id":"00001111-aaaa-2222-bbbb-3333cccc4444",
 "ui_locales":"en-US"
}

发送到 API 的声明取决于从用户收集的信息，或者由标识提供者提供。

执行此步骤时来自 Web API 的预期响应类型

在运行用户流期间当 Web API 从 Microsoft Entra ID 收到 HTTP 请求时，它可以返回以下响应：

继续响应
阻止响应
验证响应

继续响应

继续响应表示用户流应继续下一步：在目录中创建用户。

在继续响应中，API 可以返回声明。如果 API 返回了某个声明，该声明将执行以下操作：

重写用户在属性集合页中已提供的任何值。

若要在注册时将声明写入不应从用户收集的目录，你仍应选择用户流的用户属性下的声明，该属性默认会要求用户输入值，但你可以使用自定义 JavaScript 或 CSS 来隐藏最终用户的输入字段。

参阅继续响应的示例。

拦截响应

参阅阻止响应的示例。

验证错误响应

当 API 使用验证错误响应进行响应时，用户流将保留在属性集合页上，并向用户显示一个 userMessage 。然后，用户可以编辑并重新提交表单。这种类型的响应可用于输入验证。

参阅验证错误响应的示例。

发送令牌之前（预览版）

重要

此步骤中使用的 API 连接器处于预览阶段。有关预览版的详细信息，请参阅联机服务的产品条款。

在登录和注册期间即将颁发令牌时，将调用此步骤中的 API 连接器。此步骤的 API 连接器可用于使用来自外部源的声明值来扩充令牌。

执行此步骤时发送到 API 的示例请求

POST <API-endpoint>
Content-type: application/json

{
 "clientId": "11112222-bbbb-3333-cccc-4444dddd5555",
 "step": "PreTokenApplicationClaims",
 "ui_locales":"en-US",
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
}

发送到 API 的声明取决于为用户定义的信息。

执行此步骤时来自 Web API 的预期响应类型

在运行用户流期间当 Web API 从 Microsoft Entra ID 收到 HTTP 请求时，它可以返回以下响应：

继续响应

继续响应

继续响应表示用户流应继续下一步：颁发令牌。

在延续响应中，API 可以返回其他声明。你希望在令牌中返回的 API 所返回的声明必须是内置声明或定义为自定义属性，并且必须在用户流的“应用程序声明”配置中选中。

令牌中的声明值将是 API 返回的值，而不是目录中的值。 API 响应无法覆盖某些声明值。 API 可以返回的声明对应于 用户属性 下找到的集，除了 email 之外。

参阅继续响应的示例。

注释

API 仅在初始身份验证期间调用。使用刷新令牌以无提示方式获取新的访问令牌或 ID 令牌时，令牌将包括初始身份验证期间评估的值。

示例响应

连续响应的示例

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "Continue",
    "postalCode": "12349", // return claim
    "extension_<extensions-app-id>_CustomAttribute": "value" // return claim
}

参数	类型	必选	DESCRIPTION
版本	字符串	是的	API 的版本。
操作	字符串	是的	值必须是 `Continue`。
<内建用户属性 (builtInUserAttribute)>	<属性类型>	否	返回的值可以覆盖从用户收集的值。
<extension_{extensions-app-id}_自定义属性>	<属性类型>	否	声明不需要包含 `_<extensions-app-id>_`，它是可选的。返回的值可以覆盖从用户收集的值。

阻止响应的示例

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "There was a problem with your request. You are not able to sign up at this time. Please contact your system administrator",
}

参数	类型	必选	DESCRIPTION
版本	字符串	是的	API 的版本。
操作	字符串	是的	值必须是 `ShowBlockPage`
用户消息	字符串	是的	要显示给用户的消息。

收到阻止响应时的最终用户体验

阻止响应的示例

验证错误响应示例

HTTP/1.1 400 Bad Request
Content-type: application/json

{
    "version": "1.0.0",
    "status": 400,
    "action": "ValidationError",
    "userMessage": "Please enter a valid Postal Code."
}

参数	类型	必选	DESCRIPTION
版本	字符串	是的	API 的版本。
操作	字符串	是的	值必须是 `ValidationError`。
状态	整数/字符串	是的	其值必须为 `400` 或 `"400"`（表示验证错误响应）。
用户消息	字符串	是的	要显示给用户的消息。

注释

HTTP 状态代码必须是“400”，此外，响应正文中必须包含“status”值。

收到验证错误响应时的最终用户体验

验证错误响应示例

准备一个 REST API 终结点

在本演练中，应有一个 REST API，用于验证是否在后端系统中注册了一个具有会员 ID 的电子邮件地址。如果已注册，REST API 应返回注册促销代码，客户可以使用该代码在应用程序中购买商品。否则，REST API 应返回 HTTP 409 错误消息：“会员 ID '{loyalty ID}' 未与 '{email}' 电子邮件地址关联。”

以下 JSON 代码演示 Azure AD B2C 将发送到 REST API 终结点的数据。

{
    "email": "User email address",
    "language": "Current UI language",
    "loyaltyId": "User loyalty ID"
}

REST API 验证数据后，它必须返回 HTTP 200（确定），其中包含以下 JSON 数据：

{
    "promoCode": "24534"
}

如果验证失败，REST API 必须使用 JSON 元素返回 HTTP 409（冲突 userMessage ）。 IEF 需要 REST API 返回的 userMessage 声明。如果验证失败，此声明将作为字符串呈现给用户。

{
    "version": "1.0.1",
    "status": 409,
    "userMessage": "LoyaltyId ID '1234' is not associated with 'david@contoso.com' email address."
}

REST API 终结点的设置不在本文的范围内。我们创建了一个 Azure Functions 示例。可以在 GitHub 上访问完整的 Azure 函数代码。

定义索赔

声明可在 Azure AD B2C 策略执行过程中提供数据的临时存储。可以在声明架构部分中声明。

打开策略的扩展文件。例如，SocialAndLocalAccounts/TrustFrameworkExtensions.xml。
搜索 BuildingBlocks 元素。如果该元素不存在，请添加该元素。
找到 ClaimsSchema 元素。如果该元素不存在，请添加该元素。
将以下声明添加到 ClaimsSchema 元素。

<ClaimType Id="loyaltyId">
  <DisplayName>Your loyalty ID</DisplayName>
  <DataType>string</DataType>
  <UserInputType>TextBox</UserInputType>
</ClaimType>
<ClaimType Id="promoCode">
  <DisplayName>Your promo code</DisplayName>
  <DataType>string</DataType>
  <UserInputType>Paragraph</UserInputType>
</ClaimType>
  <ClaimType Id="userLanguage">
  <DisplayName>User UI language (used by REST API to return localized error messages)</DisplayName>
  <DataType>string</DataType>
</ClaimType>

添加 RESTful API 技术配置文件

RESTful 技术配置文件支持与你自己的 RESTful 服务交互。 Azure AD B2C 将数据以集合InputClaims的方式发送到 RESTful 服务，并以集合OutputClaims的方式接收返回的数据。查找 ClaimsProviders 元素并添加一个新的声明提供程序，如下所示：

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-ValidateProfile">
      <DisplayName>Check loyaltyId Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <!-- Set the ServiceUrl with your own REST API endpoint -->
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/ValidateProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
        <Item Key="AuthenticationType">None</Item>
        <!-- REMOVE the following line in production environments -->
        <Item Key="AllowInsecureAuthInProduction">true</Item>
      </Metadata>
      <InputClaims>
        <!-- Claims sent to your REST API -->
        <InputClaim ClaimTypeReferenceId="loyaltyId" />
        <InputClaim ClaimTypeReferenceId="email" />
        <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
      </InputClaims>
      <OutputClaims>
        <!-- Claims parsed from your REST API -->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

在此示例中，userLanguage 将作为 JSON 有效负载中的 lang 发送到 REST 服务。声明的值userLanguage包含了当前用户的语言 ID。有关详细信息，请参阅声明解析程序。

配置 RESTful API 技术概况

部署 REST API 后，设置技术配置文件的 REST-ValidateProfile 元数据以反映自己的 REST API，包括：

ServiceUrl。设置 REST API 终结点的 URL。
SendClaimsIn。指定如何将输入声明发送到 RESTful 声明提供程序。
AuthenticationType。设置 RESTful 声明提供程序执行的身份验证类型。
AllowInsecureAuthInProduction。在生产环境中，请确保将此元数据设置为 true

有关更多配置，请参阅 RESTful 技术配置文件元数据。

上述 AuthenticationType 和 AllowInsecureAuthInProduction 注释说明你在移动到生产环境时需要做出的更改。若要了解如何保护 RESTful API 进行生产，请参阅安全 RESTful API。

验证用户输入

若要在注册期间获取用户的会员号码，必须允许用户在屏幕上输入此数据。将 loyaltyId 输出声明添加到注册页面，方法是将其添加到现有注册技术配置文件部分的 OutputClaims 元素。指定输出声明的完整列表，以控制屏幕上显示声明的顺序。

将验证技术配置文件引用添加到调用 REST-ValidateProfile 的注册技术配置文件。新的验证技术概要文件将添加到基策略中定义的<ValidationTechnicalProfiles>集合的顶部。此行为意味着仅在成功验证后，Azure AD B2C 才会继续在目录中创建帐户。

查找 ClaimsProviders 元素。如下所示添加新的声明提供程序：

<ClaimsProvider>
  <DisplayName>Local Account</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="newPassword" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="displayName"/>
        <OutputClaim ClaimTypeReferenceId="givenName"/>
        <OutputClaim ClaimTypeReferenceId="surName"/>
        <!-- Required to present the text box to collect the data from the user -->
        <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
        <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
        to subsequent orchestration steps and token issuance-->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile" />
      </ValidationTechnicalProfiles>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>
<ClaimsProvider>
  <DisplayName>Self Asserted</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SelfAsserted-Social">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="email" />
      </InputClaims>
        <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="email" />
        <OutputClaim ClaimTypeReferenceId="displayName"/>
        <OutputClaim ClaimTypeReferenceId="givenName"/>
        <OutputClaim ClaimTypeReferenceId="surname"/>
        <!-- Required to present the text box to collect the data from the user -->
        <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
        <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
        to subsequent orchestration steps and token issuance-->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile"/>
      </ValidationTechnicalProfiles>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

在令牌中包括声明

若要将促销代码声明返回给信赖方应用程序，请将输出声明添加到 SocialAndLocalAccounts/SignUpOrSignIn.xml 该文件。输出声明将允许在用户旅程成功后向令牌添加声明，并将被发送到应用程序。在信赖方部分修改技术概要元素，以添加 promoCode 作为输出声明。

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <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="promoCode" DefaultValue="" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

测试自定义策略

登录到 Azure 门户。
如果有权访问多个租户，请选择顶部菜单中的“设置”图标，切换到“目录 + 订阅”菜单中的 Microsoft Entra ID 租户。
选择 Azure 门户左上角的“所有服务”，然后搜索并选择“应用注册” 。
选择“Identity Experience Framework”。
选择 “上传自定义策略”，然后上传已更改的策略文件： TrustFrameworkExtensions.xml和 SignUpOrSignin.xml。
选择已上传的注册或登录策略，然后单击“ 立即运行 ”按钮。
应能够使用电子邮件地址进行注册。
单击“ 立即注册 ”链接。
在 “你的会员 ID”中，键入 1234，然后单击“ 继续”。此时，应收到验证错误消息。
更改为另一个值，然后单击“ 继续”。
发送回应用程序的令牌包含 promoCode 声明。

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584295703,
  "nbf": 1584292103,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/",
  "aud": "22223333-cccc-4444-dddd-5555eeee6666",
  "acr": "b2c_1a_signup_signin",
  "nonce": "defaultNonce",
  "iat": 1584292103,
  "auth_time": 1584292103,
  "name": "Emily Smith",
  "email": "emily@outlook.com",
  "given_name": "Emily",
  "family_name": "Smith",
  "promoCode": "84362"
  ...
}

最佳做法和故障排除方法

使用无服务器云函数

无服务器函数（例如 Azure Functions 中的 HTTP 触发器）可让用户创建与 API 连接器配合使用的 API 终结点。举例而言，可以使用无服务器云函数来执行验证逻辑，并仅限通过特定的电子邮件域进行注册。无服务器云函数还可以调用其他 Web API、数据存储和其他云服务，以实现复杂的方案。

最佳做法

请确保：

API 遵循上面所述的 API 请求和响应协定。
API 连接器的终结点 URL 指向正确的 API 终结点。
API 会显式检查它所依赖的已收到声明是否有 null 值。
你的 API 会实现保护 API 连接器中概述的身份验证方法。
API 可以尽快做出响应，以确保用户体验流畅。
- Azure AD B2C 将等待最多 10 秒 才能接收响应。如果未收到任何内容，它会再次尝试（重试）调用 API。
- 如果使用无服务器函数或可缩放的 Web 服务，请使用能够在生产环境中让 API 保持“清醒”或“热身”状态的托管计划。对于 Azure Functions，建议在生产环境中至少使用高级计划。
确保 API 的高可用性。
监视和优化下游 API、数据库或 API 的其他依赖项的性能。

重要

终端必须符合 Azure AD B2C 安全要求。旧版 TLS 版本和密码已弃用。有关详细信息，请参阅 Azure AD B2C TLS 和密码套件要求。

使用日志记录

一般情况下，使用 Web API 服务（例如 Application insights）启用的日志记录工具来监视 API 是否出现意外错误代码、异常和性能不佳的情况会很有帮助。

监视非 HTTP 200 或 400 的 HTTP 状态代码。
401 或 403 HTTP 状态代码通常指示身份验证出现了问题。反复检查 API 的身份验证层以及 API 连接器中的相应配置。
如果需要，请在开发中使用更主动的日志记录级别（例如“跟踪”或“调试”）。
监视 API 的响应时间是否太长。

此外，Azure AD B2C 记录有关通过用户流进行用户身份验证期间发生的 API 事务的元数据。若要查找这些，请执行以下步骤：

转到 Azure AD B2C。
在 “活动”下，选择“ 审核日志”。
筛选列表视图：对于 “日期”，选择所需的时间间隔；对于 “活动”，选择 用户流程中 API 被调用。
检查单个日志。每行表示在用户流期间尝试调用的 API 连接器。如果 API 调用失败，并且重试发生，它仍表示为单行。 numberOfAttempts 指示 API 被调用的次数。此值可以是 1或 2。有关 API 调用的其他信息在日志中详细介绍。

用户身份验证期间 API 连接器事务的示例

使用无服务器云函数

无服务器云函数（如 Azure Functions 中的 HTTP 触发器）提供了一种简单、高度可用、高性能的方式来创建用作 API 连接器的 API 终结点。

最佳做法

请确保：

API 会显式检查它所依赖的已收到声明是否有 null 值。
你的 API 会实现保护 API 连接器中概述的身份验证方法。
API 可以尽快做出响应，以确保用户体验流畅。
- 如果使用无服务器函数或可缩放的 Web 服务，请使用能够在生产环境中让 API 保持“清醒”或“热身”状态的托管计划。对于 Azure Functions，建议至少使用高级计划
确保 API 的高可用性。
监视和优化下游 API、数据库或 API 的其他依赖项的性能。

重要

终端必须符合 Azure AD B2C 安全要求。旧版 TLS 版本和密码已弃用。有关详细信息，请参阅 Azure AD B2C TLS 和密码套件要求。

使用日志记录

一般情况下，使用 Web API 服务（例如 Application insights）启用的日志记录工具来监视 API 是否出现意外错误代码、异常和性能不佳的情况会很有帮助。

监视非 HTTP 200 或 400 的 HTTP 状态代码。
401 或 403 HTTP 状态代码通常指示身份验证出现了问题。反复检查 API 的身份验证层以及 API 连接器中的相应配置。
如果需要，请在开发中使用更主动的日志记录级别（例如“跟踪”或“调试”）。
监视 API 的响应时间是否太长。

后续步骤

开始使用我们的示例。
保护 API 连接器

通过

将 API 连接器添加到注册用户流

先决条件

创建 API 连接器

发送到 API 的请求

在用户流中启用 API 连接器

在注册期间与标识提供者进行联合后

执行此步骤时发送到 API 的示例请求

执行此步骤时来自 Web API 的预期响应类型

继续响应

拦截响应

创建用户之前

执行此步骤时发送到 API 的示例请求

执行此步骤时来自 Web API 的预期响应类型

继续响应

拦截响应

验证错误响应

发送令牌之前（预览版）

执行此步骤时发送到 API 的示例请求

执行此步骤时来自 Web API 的预期响应类型

继续响应

示例响应

连续响应的示例

阻止响应的示例

验证错误响应示例

准备一个 REST API 终结点

定义索赔

添加 RESTful API 技术配置文件

配置 RESTful API 技术概况

验证用户输入

在令牌中包括声明

测试自定义策略

最佳做法和故障排除方法

使用无服务器云函数

最佳做法

使用日志记录

使用无服务器云函数

最佳做法

使用日志记录

后续步骤

反馈

其他资源