Azure Active Directory B2C カスタムポリシーを使用して REST API を呼び出す

2025-04-16

重要

2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。詳細については、FAQ を参照してください。

Azure Active Directory B2C (Azure AD B2C) カスタムポリシーを使用すると、Azure AD B2C の外部で実装するアプリケーションロジックを操作できます。これを行うには、エンドポイントへの HTTP 呼び出しを行います。 Azure AD B2C カスタムポリシーは、この目的のために RESTful 技術プロファイルを提供します。この機能を使用すると、Azure AD B2C カスタムポリシー内では使用できない機能を実装できます。

この記事では、次の方法について説明します。

RESTful サービスとして使用するサンプル Node.js アプリを作成してデプロイします。
RESTful 技術プロファイルを使用して、Node.js RESTful サービスへの HTTP 呼び出しを行います。
RESTful サービスがカスタムポリシーに返すエラーを処理または報告します。

シナリオの概要

Azure AD B2C カスタムポリシーを使用したユーザー体験での分岐の作成では、個人用アカウントを選択したユーザーは、有効な招待アクセスコードを指定して続行する必要があります。静的アクセスコードを使用していますが、実際のアプリはこの方法では機能しません。アクセスコードを発行するサービスがカスタムポリシーの外部にある場合は、そのサービスを呼び出し、検証のためにユーザーが入力したアクセスコードを渡す必要があります。アクセスコードが有効な場合、サービスは HTTP 200 OK 応答を返し、Azure AD B2C は JWT を発行します。それ以外の場合、サービスは HTTP 4xx 応答を返し、ユーザーはアクセスコードを再入力する必要があります。

R E S T A P Iを呼び出すフローチャート。

前提条件

まだお持ちでない場合は、Azure サブスクリプションにリンクされている Azure AD B2C テナントを作成します。
Web アプリケーションを登録します。
コンピューターに Node.js がインストールされている必要があります。
コンピューターに Visual Studio Code (VS Code) がインストールされている必要があります。
「Azure AD B2C カスタムポリシーを使用してユーザー入力を検証する」の手順を完了します。この記事は、独自のカスタムポリシーの作成と実行のハウツーガイドシリーズの一部です。

注

この記事は、 Azure Active Directory B2C での独自のカスタムポリシーの作成と実行に関するハウツーガイドシリーズの一部です。最初の記事からこのシリーズを開始することをお勧めします。

手順 1 - Node.js アプリを作成してデプロイする

外部アプリとして機能するアプリをデプロイする必要があります。その後、カスタムポリシーによって、このアプリへの HTTP 呼び出しが行われます。

手順 1.1 - Node.js アプリを作成する

access-code-appなど、ノードアプリケーションをホストするフォルダーを作成します。
ターミナルで、 cd access-code-appなどの Node アプリフォルダーにディレクトリを変更し、 npm init -y実行します。このコマンドは、Node.js プロジェクトの既定の package.json ファイルを作成します。
ターミナルで、npm install express body-parser を実行します。このコマンドは、Express フレームワークとボディパーサーパッケージをインストールします。
プロジェクトで、 index.js ファイルを作成します。

VS Code で、 index.js ファイルを開き、次のコードを追加します。

    const express = require('express');
    let bodyParser = require('body-parser')
    //Create an express instance
    const app = express();

    app.use( bodyParser.json() );       // to support JSON-encoded bodies
    app.use(bodyParser.urlencoded({     // to support URL-encoded bodies
      extended: true
    }));


    app.post('/validate-accesscode', (req, res) => {
        let accessCode = '88888';
        if(accessCode == req.body.accessCode){
            res.status(200).send();
        }else{
            let errorResponse = {
                "version" :"1.0",
                "status" : 409,
                "code" : "errorCode",
                "requestId": "requestId",
                "userMessage" : "The access code you entered is incorrect. Please try again.",
                "developerMessage" : `The provided code ${req.body.accessCode} does not match the expected code for user.`,
                "moreInfo" :"https://learn.microsoft.com/en-us/azure/active-directory-b2c/string-transformations"
            };
            res.status(409).send(errorResponse);                
        }
    });

    app.listen(80, () => {
        console.log(`Access code service listening on port !` + 80);
    });

ユーザーが間違ったアクセスコードを送信すると、REST API から直接エラーを返すことができることを確認できます。カスタムポリシーを使用すると、HTTP 4xx エラーメッセージ (400 (無効な要求)、または 409 (競合) の応答状態コードなど) を返し、応答 JSON 本文 errorResponse 変数に示すように書式設定できます。アプリ内の accessCode のソースをデータベースから読み取る可能性があります。検証エラーメッセージの返却についてさらに詳しく知る。

アプリが期待どおりに動作することをテストするには、次の手順を使用します。

ターミナルで、 node index.js コマンドを実行してアプリサーバーを起動します。
この例に示すような POST 要求を行うには、 Microsoft PowerShell などの HTTP クライアントを使用できます。

    POST http://localhost/validate-accesscode HTTP/1.1
    Host: localhost
    Content-Type: application/x-www-form-urlencoded

    accessCode=user-code-code

user-code-codeを、54321などのユーザーによるアクセスコード入力に置き換えます。 PowerShell を使用している場合は、次のスクリプトを実行します。

    $accessCode="54321"
    $endpoint="http://localhost/validate-accesscode"
    $body=$accessCode
    $response=Invoke-RestMethod -Method Post -Uri $endpoint -Body $body
    echo $response

正しくないアクセスコードを使用する場合、応答は次の JSON スニペットのようになります。

    {
        "version": "1.0",
        "status": 409,
        "code": "errorCode",
        "requestId": "requestId",
        "userMessage": "The access code you entered is incorrect. Please try again.",
        "developerMessage": "The provided code 54321 does not match the expected code for user.",
        "moreInfo": "https://learn.microsoft.com/en-us/azure/active-directory-b2c/string-transformations"
    }

REST サービスは HTTP 4xx 状態コードを返すことができますが、JSON 応答の status の値は 409する必要があります。

この時点で、Node.js アプリをデプロイする準備ができました。

手順 1.2 - Azure App Service に Node.js アプリをデプロイする

カスタムポリシーが Node.js アプリに到達するには、アクセス可能である必要があるため、デプロイする必要があります。この記事では、 Azure App Service を使用してアプリをデプロイしますが、別のホスティングアプローチを使用します。

「アプリを Azure にデプロイする」の手順に従って、Node.js アプリを Azure にデプロイします。アプリの名前には、 custompolicyapiなどのわかりやすい名前を使用します。従って：

アプリの URL は、 https://custompolicyapi.azurewebsites.netのようになります。
サービスエンドポイントは、 https://custompolicyapi.azurewebsites.net/validate-accesscodeのようになります。

Microsoft PowerShell などの HTTP クライアントを使用して、デプロイしたアプリをテストできます。今回は、エンドポイントとして https://custompolicyapi.azurewebsites.net/validate-accesscode URL を使用します。

手順 2 - REST API を呼び出す

アプリが実行されたので、カスタムポリシーから HTTP 呼び出しを行う必要があります。 Azure AD B2C カスタムポリシーは、外部サービスの呼び出しに使用する RESTful 技術プロファイルを提供します。

手順 2.1 - RESTful 技術プロファイルを定義する

ContosoCustomPolicy.XML ファイルで、ClaimsProviders セクションを見つけ、次のコードを使用して新しい RESTful 技術プロファイルを定義します。

    <!--<ClaimsProviders>-->
        <ClaimsProvider>
            <DisplayName>HTTP Request Technical Profiles</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="ValidateAccessCodeViaHttp">
                    <DisplayName>Check that the user has entered a valid access code by using Claims Transformations</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
                    <Metadata>
                        <Item Key="ServiceUrl">https://custompolicyapi.azurewebsites.net/validate-accesscode</Item>
                        <Item Key="SendClaimsIn">Body</Item>
                        <Item Key="AuthenticationType">None</Item>
                        <Item Key="AllowInsecureAuthInProduction">true</Item>
                    </Metadata>
                    <InputClaims>
                        <InputClaim ClaimTypeReferenceId="accessCode" PartnerClaimType="accessCode" />
                    </InputClaims>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

プロトコルから、 RestfulProvider を使用するように技術プロファイルが構成されていることを確認できます。メタデータセクションでは、次の情報を確認することもできます。

ServiceUrlは API エンドポイントを表します。その値は https://custompolicyapi.azurewebsites.net/validate-accesscode。別の方法を使用して Node.js アプリをデプロイした場合は、必ずエンドポイント値を更新してください。
SendClaimsIn は、入力要求を RESTful クレームプロバイダーに送信する方法を指定します。使用可能な値: Body (default)、 Form、 Header、 Url 、または QueryString。この記事にあるように Body を使用すると、POST HTTP メソッドを使用し、リクエストの本文でキーと値のペアとしてフォーマットされたデータを API に送信します。 GET HTTP 動詞を呼び出し、クエリ文字列としてデータを渡す方法について説明します。
AuthenticationType は、RESTful クレームプロバイダーが実行する認証の種類を指定します。 RESTful クレームプロバイダーは保護されていないエンドポイントを呼び出すので、 AuthenticationType を None に設定します。認証の種類を Bearer に設定する場合は、アクセストークンのストレージを指定する CryptographicKeys 要素を追加する必要があります。 RESTful クレームプロバイダーがサポートする認証の種類について説明します。
の InputClaim 属性は、API でデータを受け取る方法を指定します。

手順 2.2 - 検証技術プロファイルを更新する

Azure AD B2C カスタムポリシーを使用したユーザー体験での分岐の作成で、要求変換を使用して accessCode を検証しました。この記事では、外部サービスへの HTTP 呼び出しを行って accessCode を検証します。そのため、新しいアプローチを反映するようにカスタムポリシーを更新する必要があります。

AccessCodeInputCollector 技術プロファイルを見つけて、ValidationTechnicalProfile 要素の ReferenceId をValidateAccessCodeViaHttp に更新します。

更新前:

    <ValidationTechnicalProfile ReferenceId="CheckAccessCodeViaClaimsTransformationChecker"/>

宛先：

    <ValidationTechnicalProfile ReferenceId="ValidateAccessCodeViaHttp"/>

この時点で、 IdCheckAccessCodeViaClaimsTransformationChecker を含む技術プロファイルは不要であり、削除できます。

手順 3 - カスタムポリシーファイルをアップロードする

Node.js アプリが実行されていることを確認し、「カスタムポリシーファイルのアップロード」の手順に従ってポリシーファイルをアップロードします。ポータルに既に存在するファイルと同じ名前のファイルをアップロードする場合は、[ カスタムポリシーが既に存在する場合は上書きする] を選択してください。

手順 4 - カスタムポリシーをテストする

カスタムポリシーをテストしてカスタムポリシーをテストする手順に従います。

[アカウントの種類] で、[個人アカウント] を選択します。
必要に応じて残りの詳細を入力し、[ 続行] を選択します。新しい画面が表示されます。
[アクセスコード] に「88888」と入力し、[続行] を選択します。ポリシーの実行が完了すると、 https://jwt.msにリダイレクトされ、デコードされた JWT が表示されます。手順を繰り返し、88888 以外の別のアクセスコードを入力すると、エラーが表示されます。入力したアクセスコードが正しくありません。もう一度お試しください。

手順 5 - デバッグモードを有効にする

開発中は、 developerMessage や moreInfo など、API によって送信された詳細なエラーを確認できます。この場合、RESTful 技術プロバイダーでデバッグモードを有効にする必要があります。

ValidateAccessCodeViaHttp 技術プロバイダーを見つけ、技術プロバイダーのmetadataに次の項目を追加します。
```
    <Item Key="DebugMode">true</Item>
```
変更を保存し、ポリシーファイルをアップロードします。
カスタムポリシーをテストします。 アクセスコードに間違った入力を使用していることを確認します。次のスクリーンショットに示すようなエラーが表示されます。

複雑な要求 JSON ペイロードを処理する

呼び出す REST API で複雑な JSON ペイロードを送信する必要がある場合は、 GenerateJson JSON 要求変換を使用してペイロードを作成できます。ペイロードを生成したら、JSON ペイロードを含むクレームの名前にメタデータオプションを使用できます。

たとえば、次の要求変換を使用して JSON ペイロードを生成します。

    <ClaimsTransformation Id="GenerateRequestBodyClaimsTransformation" TransformationMethod="GenerateJson">
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" TransformationClaimType="customerEntity.email" />
            <InputClaim ClaimTypeReferenceId="objectId" TransformationClaimType="customerEntity.userObjectId" />
            <InputClaim ClaimTypeReferenceId="givenName" TransformationClaimType="customerEntity.firstName" />
            <InputClaim ClaimTypeReferenceId="surname" TransformationClaimType="customerEntity.lastName" />
            <InputClaim ClaimTypeReferenceId="accessCode" TransformationClaimType="customerEntity.accessCode" />
        </InputClaims>
        <InputParameters>
            <InputParameter Id="customerEntity.role.name" DataType="string" Value="Administrator" />
            <InputParameter Id="customerEntity.role.id" DataType="long" Value="1" />
        </InputParameters>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="requestBodyPayload" TransformationClaimType="outputClaim" />
        </OutputClaims>
    </ClaimsTransformation>

ClaimsTransformation では、次の JSON オブジェクトが生成されます。

{
   "customerEntity":{
      "email":"john.s@contoso.com",
      "userObjectId":"aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
      "firstName":"John",
      "lastName":"Smith",
      "accessCode":"88888",
      "role":{
         "name":"Administrator",
         "id": 1
      }
   }
}

次に、次に示すように、RESTful 技術プロバイダーの メタデータ、 InputClaimsTransformations、 InputClaims を更新します。

    <Metadata>
        <Item Key="ClaimUsedForRequestPayload">requestBodyPayload</Item>
        <!--Other Metadata items -->
    </Metadata>
    
    <!--Execute your InputClaimsTransformations to generate your request Payload-->
    <InputClaimsTransformations>
        <InputClaimsTransformation ReferenceId="GenerateRequestBodyClaimsTransformation" />
    </InputClaimsTransformations>
    
    <InputClaims>
        <InputClaim ClaimTypeReferenceId="requestBodyPayload" />
    </InputClaims>

REST API からデータを受信する

REST API がデータを返す場合(ポリシーに要求として含める)、RESTful 技術プロファイルの OutputClaims 要素に要求を指定することで受け取ることができます。ポリシーで定義されている要求の名前が REST API で定義されている名前と異なる場合は、 PartnerClaimType 属性を使用してこれらの名前をマップする必要があります。

「データの受信」の手順を使用して、カスタムポリシーで想定されるデータの書式を設定する方法、null 値を処理する方法、および API の入れ子になった JSON 本文を REST で解析する方法について説明します。

次に、次の情報を確認します。

JSON 要求変換について。
RESTful 技術プロファイルについて。
Azure Active Directory B2C カスタムポリシーを使用してユーザーアカウントを作成して読み取る方法

次の方法で共有

Azure Active Directory B2C カスタム ポリシーを使用して REST API を呼び出す