API コネクタをサインアップユーザーフローに追加する

[アーティクル]
04/04/2023

"開始する前に"、[ポリシーの種類の選択] セレクターを使用して、設定するポリシーの種類を選択します。 Azure Active Directory B2C には、ユーザーがアプリケーションを操作する方法を定義する 2 つの方法 (定義済みのユーザーフローを使用する、または完全に構成可能なカスタムポリシーを使用する) があります。この記事で必要な手順は、方法ごとに異なります。

開発者または IT 管理者は、API コネクタを使用し、サインアップユーザーフローと REST API を統合してサインアップ体験をカスタマイズしたり、外部システムと統合したりできます。このチュートリアルの最後では、REST API サービスと対話する Azure AD B2C ユーザーフローを作成して、サンアップエクスペリエンスを変更できるようになります。

API エンドポイントは、サンプルの 1 つを使用して作成できます。

このシナリオでは、ユーザーが Azure AD B2C サインアップページにロイヤルティ番号を入力する機能を追加します。 REST API によって、メールアドレスとロイヤルティ番号の組み合わせがプロモーションコードにマッピングされているかどうかが検証されます。 REST API がこのユーザーのプロモーションコードを見つけると、Azure AD B2C に返されます。最後に、アプリケーションが使用するトークン要求にプロモーションコードが挿入されます。

対話は、オーケストレーション手順として設計することもできます。これは、REST API が画面上のデータを検証せず、常に要求を返す場合に適しています。詳細については、「チュートリアル:REST API 要求交換をオーケストレーション手順として Azure AD B2C ユーザー体験に統合するを参照してください。

前提条件

ユーザーフローを作成して、ユーザーがアプリケーションにサインアップおよびサインインできるようにします。
Web アプリケーションを登録します。

「Active Directory B2C でのカスタムポリシーの概要」にある手順を完了します。
Web アプリケーションを登録します。

API コネクタを作成する

API コネクタを使用するには、まず API コネクタを作成してから、ユーザーフローで有効にします。

Azure portal にサインインします。
[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": "11111111-0000-0000-0000-000000000000",
 "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":"93fd07aa-333c-409d-955d-96008fd08dd9",
 "ui_locales":"en-US"
}

[Azure AD B2C] の [ユーザー属性] のエクスペリエンスで一覧表示されるユーザープロパティとカスタム属性だけが、要求で送信できます。

カスタム属性は、ディレクトリ内に 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 に送信されません。 API は、要求に要求が含まれていないケースを明示的に確認して処理するように設計する必要があります。

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

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

Azure portal にサインインします。
[Azure サービス] で、 [Azure AD B2C] を選択します。
[ユーザーフロー] を選択し、API コネクタを追加するユーザーフローを選択します。
[API connectors](API コネクタ) を選択し、ユーザーフローの次の手順で呼び出す API エンドポイントを選択します。
- サインアップ時に 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":"93fd07aa-333c-409d-955d-96008fd08dd9",
 "ui_locales":"en-US"
}

API に送信される要求は、ユーザーから収集される情報または ID プロバイダーによって提供される情報によって異なります。

この手順での 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": "231c70e8-8424-48ac-9b5d-5623b9e4ccf3",
 "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
}

パラメーター	タイプ	Required	説明
version	String	はい	API のバージョン。
action	String	はい	値は `Continue` とする必要があります。
<builtInUserAttribute>	<attribute-type>	いいえ	戻り値を使用すると、ユーザーから収集された値を上書きすることができます。
<extension_{extensions-app-id}_CustomAttribute>	<attribute-type>	いいえ	`_<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",
}

パラメーター	タイプ	Required	説明
version	String	はい	API のバージョン。
action	String	はい	値は `ShowBlockPage` とする必要があります
userMessage	String	はい	ユーザーに表示するメッセージ。

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

Example of a blocking response

検証エラー応答の例

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

パラメーター	タイプ	Required	説明
version	String	はい	API のバージョン。
action	String	はい	値は `ValidationError` とする必要があります。
status	Integer/String	はい	ValidationError 応答の値は、`400` または `"400"` である必要があります。
userMessage	String	はい	ユーザーに表示するメッセージ。

注意

HTTP 状態コードは、応答の本文で、"status" 値であることに加え、"400" である必要があります。

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

Example of a validation-error response

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

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

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

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

データがお使いの REST API によって検証されると、次の JSON データと共に HTTP 200 (Ok) が返されます。

{
    "promoCode": "24534"
}

検証が失敗した場合、REST API は userMessage JSON 要素と共に HTTP 409 (Conflict) を返す必要があります。 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 ポリシーの実行時に、データの一時的なストレージとなります。要求は、claims schema セクションで宣言できます。

お使いのポリシーの拡張ファイルを開きます。たとえば、「 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 portal にサインインします。
複数のテナントへのアクセス権をお持ちの場合、上部のメニューの [設定] アイコンを選び、[ディレクトリとサブスクリプション] メニューからお使いの Microsoft Entra ID テナントに切り替えます。
Azure portal の左上隅にある [すべてのサービス] を選択し、 [アプリの登録] を検索して選択します。
[Identity Experience Framework] を選択します。
[カスタムポリシーのアップロード] を選択し、変更した次のポリシーファイルをアップロードします。TrustFrameworkExtensions.xml、および SignUpOrSignin.xml。
アップロードしたサインアップまたはサインインポリシーを選択し、 [今すぐ実行] ボタンをクリックします。
メールアドレスを使用してサインアップできることを確認します。
[Sign-up now](今すぐサインアップ) リンクをクリックします。
[Your loyalty ID](ロイヤルティ ID) に「1234」と入力して [続行] をクリックします。この時点で、検証エラーメッセージが表示されるはずです。
別の値に変更して [続行] をクリックします。
アプリケーションに返送されるトークンには、promoCode 要求が含まれています。

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584295703,
  "nbf": 1584292103,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/f06c2fe8-709f-4030-85dc-38a4bfd9e82d/v2.0/",
  "aud": "e1d2612f-c2bc-4599-8e7b-d874eaca1ee1",
  "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 側は、応答を受信するために最大 20 秒間待機します。何も受信しない場合は、API の呼び出しが もう一度実行 (再試行) されます。
- サーバーレス機能またはスケーラブルな Web サービスを使用している場合は、API を運用環境で "起動状態" または "ウォーム状態" に保つホスティングプランを使用します。 Azure Functions の場合、運用環境では少なくとも Premium プランを使用することをお勧めします。
API の高可用性を保証します。
ダウンストリームの API、データベース、または API のその他の依存関係のパフォーマンスを監視し、最適化します。

重要

エンドポイントは、Azure AD B2C のセキュリティ要件に準拠している必要があります。以前の TLS バージョンと暗号は非推奨です。詳細については、Azure AD B2C の TLS および暗号スイートの要件に関するページを参照してください。

ログの使用

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

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

さらに、Azure AD B2C では、ユーザーフローを介してユーザー認証中に発生した API トランザクションに関するメタデータをログに記録します。次のようにして探します。

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

Example of an API connector transaction during user authentication

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

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

ベストプラクティス

次のことを確認します。

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

重要

ログの使用

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

次のステップ

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

次の方法で共有

前提条件

API コネクタを作成する

API に送信される要求

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

この手順で API に送信される要求の例

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

継続応答

ブロック応答

ユーザーを作成する前

この手順で API に送信される要求の例

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

継続応答

ブロック応答

検証エラー応答

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

この手順で API に送信される要求の例

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

継続応答

応答の例

継続応答の例

ブロック応答の例

検証エラー応答の例

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

要求を定義する

RESTful API 技術プロファイルを追加する

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

ユーザー入力の検証

トークンに要求を含める

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

ベストプラクティスとトラブルシューティングの方法

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

ベストプラクティス

ログの使用

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

ベストプラクティス

ログの使用

次のステップ

フィードバック

その他のリソース

次の方法で共有

API コネクタをサインアップ ユーザー フローに追加する

前提条件

API コネクタを作成する

API に送信される要求

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

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

この手順で API に送信される要求の例

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

継続応答

ブロック応答

ユーザーを作成する前

この手順で API に送信される要求の例

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

継続応答

ブロック応答

検証エラー応答

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

この手順で API に送信される要求の例

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

継続応答

応答の例

継続応答の例

ブロック応答の例

検証エラー応答の例

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

要求を定義する

RESTful API 技術プロファイルを追加する

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

ユーザー入力の検証

トークンに要求を含める

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

ベスト プラクティスとトラブルシューティングの方法

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

ベスト プラクティス

ログの使用

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

ベスト プラクティス

ログの使用

次のステップ

フィードバック

その他のリソース

API コネクタをサインアップユーザーフローに追加する

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

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

ベストプラクティスとトラブルシューティングの方法

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

ベストプラクティス

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

ベストプラクティス