サインアップ ユーザー フローに 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 コネクタを作成してから、ユーザー フローで有効にします。

1. Azure portal にサインインします。

2. Azure サービスで、Azure AD B2C を選択します。

3. [API コネクタ] を選択し、[新しい API コネクタ] を選択します。

   

4. 呼び出しの表示名を指定します。 たとえば、 ユーザー情報を検証します。

5. API 呼び出しの [エンドポイント URL] を指定します。

6. [認証の種類] を選択し、API を呼び出すための認証情報を構成します。 API コネクタのセキュリティ保護の方法を参照してください。

   

7. 保存 を選択します。

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>User 属性 エクスペリエンスに記載されているユーザー プロパティとカスタム属性のみです。

カスタム属性は、ディレクトリの extension_<extensions-app-id>_CustomAttribute 形式に存在します。 API では、これと同じシリアル化された形式で要求を受け取ることを想定しています。 カスタム属性の詳細については、「 Azure AD B2C でのカスタム属性の定義」を参照してください。

さらに、通常、これらの要求はすべての要求で送信されます。

• UI ロケール ('ui_locales') - デバイスで構成されているエンド ユーザーのロケール。 これを API で使用して、国際化された応答を返すことができます。
• ステップ ('step') - API コネクタが呼び出されたユーザー フローのステップまたはポイント。 値は次のとおりです。
  • PostFederationSignup - "サインアップ時の ID プロバイダーとのフェデレーション後" に対応します
  • PostAttributeCollection - "ユーザーを作成する前に" に対応します
  • PreTokenIssuance - "トークンを送信する前 (プレビュー)" に対応します。 この手順の詳細
• クライアント ID ('client_id') - エンド ユーザーがユーザー フローで認証しているアプリケーションの appId 値。 これは、アクセス トークン内のリソース アプリケーションのappId。
• メール アドレス ('email') または ID ('identities') - これらの要求は、アプリケーションに対して認証を行っているエンドユーザーを識別するために API で使用することができます。

ユーザー フローで API コネクタを有効にする

サインアップ ユーザー フローに API コネクタを追加するには、次の手順に従います。

1. Azure portal にサインインします。

2. Azure サービスで、Azure AD B2C を選択します。

3. [ユーザー フロー] を選択し、API コネクタを追加するユーザー フローを選択します。

4. [API connectors](API コネクタ) を選択し、ユーザー フローの次の手順で呼び出す API エンドポイントを選択します。

   • サインアップ時に ID プロバイダーとのフェデレーションを行った後
   • ユーザーを作成する前
   • トークンを送信する前 (プレビュー)

   

5. 保存 を選択します。

これらの手順は、サインアップとサインイン (推奨) とサインアップ (推奨) にのみ存在しますが、エクスペリエンスのサインアップ部分にのみ適用されます。

サインアップ時に ID プロバイダーとのフェデレーションを行った後

サインアップ プロセスのこの手順の API コネクタは、ユーザーが ID プロバイダー (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 に送信される正確な要求は、ID プロバイダーによって提供される情報によって異なります。 "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 に送信される要求は、情報がユーザーから収集されるか、ID プロバイダーによって提供されるかによって異なります。

この手順での Web API からの予期される応答の種類

ユーザー フロー中に Web API で Microsoft Entra ID から HTTP 要求を受信すると、これらの応答が返されることがあります。

• 継続応答
• ブロックに対する応答
• 検証応答

継続応答

継続応答は、ユーザー フローが次の手順 (ディレクトリでのユーザーの作成) に進む必要があることを示します。

継続応答では、API から要求が返されることがあります。 要求が API によって返されると、その要求によって次のことが行われます。

• 属性コレクション ページでユーザーによって既に指定されている値をオーバーライドします。

サインアップ時にユーザーから収集すべきではない要求をディレクトリに書き込むには、ユーザー フローの [ユーザー属性 ] で要求を選択する必要があります。既定ではユーザーに値を要求しますが、 カスタム JavaScript または CSS を 使用してエンド ユーザーから入力フィールドを非表示にすることができます。

継続応答の例を参照してください。

ブロック応答

ブロック応答によって、ユーザー フローは終了します。 API を使用してこれを意図的に発行して、ユーザーにブロック ページを表示することにより、ユーザー フローの継続を停止することができます。 ブロック ページには、API によって提供された userMessage が表示されます。

ブロック応答の例を参照してください。

検証エラー応答

API が検証エラー応答で応答すると、ユーザー フローは属性コレクション ページにとどまり、 userMessage がユーザーに表示されます。 これで、ユーザーはフォームを編集して再送信することができます。 この種類の応答は、入力の検証に使用できます。

検証エラー応答の例を参照してください。

トークンを送信する前 (プレビュー)

この手順の 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で見つかったセットに対応します。

継続応答の例を参照してください。

応答の例

継続応答の例

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
}

ブロック応答の例

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",
}

ブロック応答を使用したエンド ユーザー エクスペリエンス

検証エラー応答の例

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."
}

検証エラー応答を使用したエンド ユーザー エクスペリエンス

REST API エンドポイントを準備する

このチュートリアルでは、メール アドレスがロイヤルティ ID を使用してバックエンド システムに登録されているかどうかを検証する REST API が必要です。 登録されている場合、REST API は登録プロモーション コードを返す必要があります。このコードは、顧客がアプリケーション内で商品を購入するために使用できます。 それ以外の場合、REST API は HTTP 409 エラー メッセージを返す必要があります。"ロイヤルティ ID '{ロイヤルティ ID}' は '{email}' メール アドレスに関連付けされていません。"。

次の JSON コードは、Azure AD B2C が REST API エンドポイントに送信するデータを示しています。

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

REST API がデータを検証したら、次の JSON データを含む HTTP 200 (OK) を返す必要があります。

{
    "promoCode": "24534"
}

検証に失敗した場合、REST API は HTTP 409 (Conflict) を返し、 userMessage JSON 要素を返す必要があります。 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 サンプルを作成しました。 完全な Azure 関数コードには GitHub でアクセスできます。

要求を定義する

要求は、Azure AD B2C ポリシーの実行中にデータの一時的なストレージを提供します。 要求スキーマ セクション内で 要求 を宣言できます。

1. ポリシーの拡張ファイルを開きます。 たとえば、SocialAndLocalAccounts/TrustFrameworkExtensions.xml のようにします。
2. BuildingBlocks 要素を検索します。 要素が存在しない場合は、追加します。
3. ClaimsSchema 要素を見つけます。 要素が存在しない場合は、追加します。
4. 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>

この例では、は JSON ペイロード内のとして REST サービスに送信されます。 userLanguage要求の値には、現在のユーザー言語 ID が含まれています。 詳細については、 要求リゾルバーを参照してください。

RESTful API 技術プロファイルを構成する

REST API をデプロイしたら、次のような独自の REST API を反映するように REST-ValidateProfile 技術プロファイルのメタデータを設定します。

• ServiceUrl。 REST API エンドポイントの URL を設定します。
• SendClaimsIn。 入力要求を RESTful 要求プロバイダーに送信する方法を指定します。
• AuthenticationType。 RESTful クレーム プロバイダーによって実行される認証の種類を設定します。
• AllowInsecureAuthInProduction。 運用環境では、必ずこのメタデータをtrueに設定してください。

その他の構成については、 RESTful 技術プロファイルのメタデータ を参照してください。

上記のコメントAuthenticationTypeAllowInsecureAuthInProduction、運用環境に移行するときに行う必要がある変更を指定します。 運用環境で RESTful API をセキュリティで保護する方法については、 RESTful API のセキュリティ保護に関するページを参照してください。

ユーザー入力を検証する

サインアップ時にユーザーのロイヤルティ番号を取得するには、ユーザーがこのデータを画面に入力できるようにする必要があります。 既存のサインアップ技術プロファイル セクションの 要素に追加して、OutputClaims 出力要求をサインアップ ページに追加します。 出力要求の一覧全体を指定して、要求が画面に表示される順序を制御します。

REST-ValidateProfileを呼び出すサインアップ技術プロファイルに検証技術プロファイル参照を追加します。 新しい検証技術プロファイルは、基本ポリシーで定義されている <ValidationTechnicalProfiles> コレクションの先頭に追加されます。 この動作は、検証が成功した後にのみ、Azure AD B2C が移動してディレクトリにアカウントを作成することを意味します。

1. 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>

カスタム ポリシーをテストする

1. Azure portal にサインインします。
2. 複数のテナントにアクセスできる場合は、上部メニューの [設定] アイコンを選択して、[ ディレクトリ + サブスクリプション ] メニューから Microsoft Entra ID テナントに切り替えます。
3. Azure portal の左上隅にある [ すべてのサービス ] を選択し、[ アプリの登録] を検索して選択します。
4. [Identity Experience Framework] を選択します。
5. [ カスタム ポリシーのアップロード] を選択し、変更したポリシー ファイル (TrustFrameworkExtensions.xml、 SignUpOrSignin.xml) をアップロードします。
6. アップロードしたサインアップまたはサインイン ポリシーを選択し、[ 今すぐ実行 ] ボタンをクリックします。
7. メール アドレスを使用してサインアップできる必要があります。
8. [ 今すぐサインアップ ] リンクをクリックします。
9. ロイヤルティ ID に「1234」と入力し、[ 続行] をクリックします。 この時点で、検証エラー メッセージが表示されます。
10. 別の値に変更し、[ 続行] をクリックします。
11. アプリケーションに送り返されるトークンには、 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 の場合は、少なくとも運用環境で Premium プラン を使用することをお勧めします。
• API の高可用性を保証します。
• ダウンストリームの API、データベース、または API のその他の依存関係のパフォーマンスを監視し、最適化します。

ログの使用

一般に、予期しないエラー コード、例外、およびパフォーマンスの低下について API を監視するには、ご使用の Web API サービスによって有効になっているログ ツール (Application insights など) を使うと便利です。

• HTTP 200 または 400 以外の HTTP 状態コードを監視します。
• 401 または 403 HTTP 状態コードは、通常、認証に問題があることを示しています。 API コネクタで API の認証レイヤーとそれに対応する構成を再確認します。
• 開発では、必要に応じて、より積極的なログ レベル ("トレース" や "デバッグ" など) を使用します。
• APIの応答時間が長くならないように監視します。

さらに、Azure AD B2C は、ユーザー フローを介してユーザー認証中に発生する API トランザクションに関するメタデータをログに記録します。 これらを見つけるには:

1. Azure AD B2C に移動します。
2. [ アクティビティ] で、[ 監査ログ] を選択します。
3. リスト ビューをフィルター処理する: [日付] で目的の時間間隔を選択し、[ アクティビティ] で [ API がユーザー フローの一部として呼び出されました] を選択します。
4. 個々のログを検査します。 各行は、ユーザー フロー中に呼び出そうとしている API コネクタを表します。 API 呼び出しが失敗し、再試行が発生した場合でも、1 つの行として表されます。 numberOfAttemptsは、API が呼び出された回数を示します。 この値は、 1または 2できます。 API 呼び出しに関するその他の情報については、ログで詳しく説明します。

サーバーレス クラウド機能の使用

Azure Functions の HTTP トリガーなどのサーバーレス クラウド関数は、API コネクタとして使用する API エンドポイントを作成するための、シンプルで高可用性でパフォーマンスの高い方法を提供します。

ベスト プラクティス

次のことを確認してください。

• API によって、それが依存する受信済み要求の null 値が明示的に確認されます。
• API には、API コネクタのセキュリティ保護に関する記事で説明されている認証方法が実装されています。
• API が可能な限り迅速に応答することで、スムーズなユーザー エクスペリエンスが保証されます。
  • サーバーレス機能またはスケーラブルな Web サービスを使用している場合は、API を運用環境で "起動状態" または "ウォーム状態" に保つホスティング プランを使用します。 Azure Functions の場合は、少なくとも Premium プランを使用することをお勧めします。
• API の高可用性を保証します。
• ダウンストリームの API、データベース、または API のその他の依存関係のパフォーマンスを監視し、最適化します。

ログの使用

一般に、予期しないエラー コード、例外、およびパフォーマンスの低下について API を監視するには、ご使用の Web API サービスによって有効になっているログ ツール (Application insights など) を使うと便利です。

• HTTP 200 または 400 以外の HTTP 状態コードを監視します。
• 401 または 403 HTTP 状態コードは、通常、認証に問題があることを示しています。 API コネクタで API の認証レイヤーとそれに対応する構成を再確認します。
• 開発では、必要に応じて、より積極的なログ レベル ("トレース" や "デバッグ" など) を使用します。
• APIの応答時間が長くならないように監視します。

• サンプルの使用を開始します。
• API コネクタをセキュリティで保護する

• チュートリアル: REST API 要求交換をオーケストレーション手順として Azure AD B2C ユーザー体験に統合する
• API コネクタをセキュリティで保護する
• リファレンス: RESTful 技術プロファイル