Azure Active Directory B2C で OAuth 2.0 クライアント資格情報フローを設定する

[アーティクル]
11/21/2023

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

OAuth 2.0 クライアント資格情報付与フローでは、アプリ (Confidential クライアント) で REST API などの別の Web リソースを呼び出すときに、ユーザーを偽装する代わりに、独自の資格情報を使用して認証できます。この種類の許可は、バックグラウンドでの実行が必要なサーバー間の相互作用に使用され、ユーザーとの即時の相互動作は必要ありません。これらのアプリケーションは、デーモンまたはサービスアカウントと呼ばれます。

クライアント資格情報フローでは、アクセス許可は管理者によってアプリケーション自体に直接付与されます。アプリがリソースにトークンを提示するとき、リソースはアプリ自体がアクションの実行を承認されていることを求めます。これは、認証に関与しているユーザーが存在しないためです。この記事では、API の呼び出しをアプリケーションに承認するために必要な手順と、その API を呼び出すために必要なトークンを取得する方法について説明します。

"この機能はパブリックプレビュー段階です。 "

アプリ登録の概要

アプリでクライアント資格情報を使ってサインインし、Web API を呼び出せるようにするには、Azure AD B2C ディレクトリに 2 つのアプリケーションを登録します。

アプリケーションの登録により、アプリでは Azure AD B2C を使用してサインインできるようになります。アプリの登録プロセスによって、アプリを一意に識別する "アプリケーション ID" ("クライアント ID" とも呼ばれます) が生成されます。また、トークンを安全に取得するためにアプリによって使用される、"クライアントシークレット" を作成します。
Web API の登録により、アプリではセキュリティで保護された Web API を呼び出すことができます。登録には、Web API の "スコープ" が含まれます。スコープを使用することで、Web API などの保護されたリソースへのアクセス許可を管理できます。その後、アプリケーションのアクセス許可を Web API のスコープに付与します。アクセストークンが要求されたとき、アプリでは要求の .default スコープパラメーターを指定します。 Azure AD B2C により、アプリに付与された Web API スコープが返されます。

アプリのアーキテクチャと登録について、次の図に示します。

Diagram of a web app with web A P I call registrations and tokens.

手順 1: Web API アプリを登録する

この手順では、Web API (App 2) をスコープに登録します。後で、アプリケーション (App 1) のアクセス許可をそれらのスコープに付与します。既にそのようなアプリを登録している場合は、この手順をスキップして、次の「手順 1.1 Web API ロール (スコープ) を定義する」に進みます。

Web API アプリの登録 (App ID: 2) を作成するには、次の手順に従います。

Azure portal にサインインします。
ご自分の Azure AD B2C テナントが含まれるディレクトリを必ず使用してください。ポータルツールバーの [Directories + subscriptions](ディレクトリ + サブスクリプション) アイコンを選択します。
[ポータルの設定] | [Directories + subscriptions](ディレクトリ + サブスクリプション) ページの [ディレクトリ名] の一覧で自分の Azure AD B2C ディレクトリを見つけて、 [切り替え] を選択します。
Azure portal で、 [Azure AD B2C] を検索して選択します。
[アプリの登録] を選択し、 [新規登録] を選択します。
アプリケーションの名前を入力します (my-api1 など)。 [リダイレクト URI] と [サポートされているアカウントの種類] を既定値のままにします。
[登録] を選択します。
アプリ登録が完了したら、 [概要] を選択します。
アプリケーション (クライアント) ID の値を記録しておきます。これは、後で Web アプリケーションを構成するときに使用します。

手順 1.1 Web API ロール (スコープ) を定義する

この手順では、Web API のアプリケーション ID の URI を構成し、次にアプリロールを定義します。アプリ "ロール" は、OAuth 2.0 の "スコープ" で使用され、API を表すアプリケーション登録で定義されます。アプリケーションでは、.default スコープでアプリケーション ID の URI を使用します。アプリロールを定義するには、次の手順に従います。

作成した Web API (my-api1 など) を選択します。
[管理] の [API の公開] を選択します。
[アプリケーション ID URI] の横にある [設定] リンクを選択します。既定値 (GUID) を一意の名前 (例: api) に置き換え、[保存] を選択します。
アプリケーション ID の URI をコピーします。次のスクリーンショットは、アプリケーション ID の URI をコピーする方法を示しています。
[管理] で、[マニフェスト] を選択してアプリケーションマニフェストエディターを開きます。エディターで appRoles 設定を見つけ、applications をターゲットとするアプリロールを定義します。各アプリロールの定義には、id 値にグローバル一意識別子 (GUID) が必要です。 Microsoft PowerShell またはオンライン GUID ジェネレーターで new-guid コマンドを実行して、新しい GUID を生成します。各アプリロール定義の value プロパティは、スコープ (scp クレーム) に表示されます。 value プロパティにスペースを含めることはできません。次の例は、読み取りと書き込みの 2 つのアプリロールを示しています。
```
"appRoles": [
{
  "allowedMemberTypes": ["Application"],
  "displayName": "Read",
  "id": "d6a15e20-f83c-4264-8e61-5082688e14c8",
  "isEnabled": true,
  "description": "Readers have the ability to read tasks.",
  "value": "app.read"
},
{
  "allowedMemberTypes": ["Application"],
  "displayName": "Write",
  "id": "204dc4ab-51e1-439f-8c7f-31a1ebf3c7b9",
  "isEnabled": true,
  "description": "Writers have the ability to create tasks.",
  "value": "app.write"
}],
```
ページの上部にある [保存] を選択して、マニフェストの変更内容を保存します。

手順 2: アプリケーションを登録する

クライアント資格情報フローを使用してアプリで Azure AD B2C を使ってサインインできるようにするには、既存のアプリケーションを使用するか、新しいものを登録します (App 1)。

既存のアプリを使用している場合は、アプリの accessTokenAcceptedVersion が 2 に設定されていることを確認します。

Azure portal で、 [Azure AD B2C] を検索して選択します。
[アプリの登録] を選び、一覧から既存のアプリを選びます。
左側のメニューの [管理] で [マニフェスト] を選択し、マニフェストエディターを開きます。
accessTokenAcceptedVersion 要素を見つけ、値を 2 に設定します。
ページの上部にある [保存] を選択して、変更内容を保存します。

新しい Web アプリの登録を作成するには、次の手順に従います。

Azure portal で、 [Azure AD B2C] を検索して選択します
[アプリの登録] を選択し、 [新規登録] を選択します。
アプリケーションの名前を入力します。たとえば、ClientCredentials_app などです。
その他の値はそのままにして、 [登録] を選択します。
後の手順で使用するために、アプリケーション (クライアント) ID を記録しておきます。

手順 2.1 クライアントシークレットを作成する

登録したアプリケーションに対してクライアントシークレットを作成します。アプリは、トークンを要求するときに、このクライアントシークレットを使用してその ID を証明します。

[管理] で、[証明書とシークレット] を選択します。
[新しいクライアントシークレット] を選択します。
[説明] ボックスにクライアントシークレットの説明を入力します (例、clientsecret1)。
[有効期限] で、シークレットが有効な期間を選択してから、 [追加] を選択します。
シークレットの値を記録します。この値は、後の手順で構成に使用します。

手順 2.2 Web API にアプリのアクセス許可を付与する

アプリ (App 1) のアクセス許可を付与するには、次の手順に従います。

[アプリの登録] を選択し、作成したアプリ (App 1) を選択します。
[管理] の下にある [API のアクセス許可] を選択します。
[構成されたアクセス許可] の下で [アクセス許可の追加] を選択します。
[自分の API] タブを選択します。
Web アプリケーションへのアクセス権を付与する API (App 2) を選択します。たとえば、「my-api1」と入力します。
[Application permission] (アプリケーションのアクセス許可) を選択します。
[アクセス許可] で、[アプリ] を展開し、前に定義したスコープ (例: app.read と app.write) を選択します。
[アクセス許可の追加] を選択します.
[<テナント名> に管理者の同意を与えます] を選択します。
[はい] を選択します。
[最新の情報に更新] を選択し、両方のスコープの [状態] に、Granted for ...(... に付与されました) と表示されていることを確認します。

手順 3: アクセストークンを取得する

ユーザーフローまたはカスタムポリシーのクライアント資格情報を有効にするための特定のアクションはありません。 Azure AD B2C ユーザーフローとカスタムポリシーの両方で、クライアント資格情報フローがサポートされます。ユーザーフローまたはカスタムポリシーの作成をまだ行っていない場合は、作成してください。次に、お好みの API 開発アプリケーションを使用して、認可要求を生成します。 POST 要求の本文として以下の情報を使用し、次の例のような呼び出しを作成します。

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy>/oauth2/v2.0/token

<tenant-name> は Azure AD B2C テナントの名前に置き換えます。たとえば、「 contoso.b2clogin.com 」のように入力します。
<policy> は、ユーザーフローの完全な名前、またはカスタムポリシーに置き換えます。すべての種類のユーザーフローとカスタムポリシーで、クライアント資格情報フローがサポートされていることに注意してください。お持ちのユーザーフローまたはカスタムポリシーを使用することも、サインアップやサインインなどの新しいものを作成することもできます。

Key	Value
grant_type	`client_credentials`
client_id	「手順 2 アプリケーションを登録する」のクライアント ID。
client_secret	「手順 2.1 クライアントシークレットを作成する」のクライアントシークレットの値。
scope	「手順 1.1 Web API ロール (スコープ) を定義する」のアプリケーション ID のURI と `.default`。例: `https://contoso.onmicrosoft.com/api/.default`、または `https://contoso.onmicrosoft.com/12345678-0000-0000-0000-000000000000/.default`。

実際の POST 要求は次の例のようになります。

要求:

POST /<tenant-name>.onmicrosoft.com/B2C_1A_SUSI/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=33333333-0000-0000-0000-000000000000
&client_secret=FyX7Q~DuPJ...
&scope=https%3A%2F%2Fcontoso.onmicrosoft.com%2Fapi%2F.default

応答:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IlBFcG5OZDlnUkNWWUc2dUs...",
    "token_type": "Bearer",
    "not_before": 1645172292,
    "expires_in": 3600,
    "expires_on": 1645175892,
    "resource": "33333333-0000-0000-0000-000000000000"
}

返されるアクセストークンクレームについて説明します。次の表に、クライアント資格情報フローに関連するクレームを示します。

要求	説明	値
`aud`	トークンの受信者を示します。	API のクライアント ID。
`sub`	サービスプリンシパルは、要求を開始したアプリケーションに関連付けられます。	これは、認可要求の `client_id` のサービスプリンシパルです。
`azp`	承認されたパーティ - アクセストークンの発行先のパーティ。	要求を開始したアプリケーションのクライアント ID。これは、認可要求の `client_id` に指定した値と同じです。
`scp`	アプリケーション API によって公開されたスコープのセット (スペースの区切り記号)。	クライアント資格情報フローにおいて、認可要求で `.default` スコープが要求されますが、トークンには API によって公開 (およびアプリ管理者によって同意) されたスコープの一覧が含まれます。たとえば、「 `app.read app.write` 」のように入力します。

手順 3.1 スクリプトを使用してアクセストークンを取得する

次の PowerShell スクリプトを使用して構成をテストします。

$appId = "<client ID>"
$secret = "<client secret>"
$endpoint = "https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy>/oauth2/v2.0/token"
$scope = "<Your API id uri>/.default"
$body = "grant_type=client_credentials&scope=" + $scope + "&client_id=" + $appId + "&client_secret=" + $secret

$token = Invoke-RestMethod -Method Post -Uri $endpoint -Body $body

次の cURL スクリプトを使用して構成をテストします。

curl --location --request POST 'https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/<policy>/oauth2/v2.0/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--form 'grant_type="client_credentials"' \
--form 'client_id="<client ID>"' \
--form 'client_secret="<client secret>"' \
--form 'scope="<Your API id uri>/.default"'

手順 4: ウィザードをカスタマイズする

この機能は、カスタムポリシーでのみ使用できます。セットアップ手順は、前のセレクターで [カスタムポリシー] を選択します。

カスタムポリシーは、トークン発行プロセスを拡張する方法を提供します。 OAuth 2.0 クライアント資格情報のユーザー体験をカスタマイズするには、クライアント資格情報のユーザー体験を構成する方法のガイダンスに従ってください。次に JwtIssuer 技術プロファイルに、作成したユーザー体験への参照を含む ClientCredentialsUserJourneyId メタデータを追加します。

次の例は、トークン発行者の技術プロファイルに ClientCredentialsUserJourneyId を追加する方法を示しています。

<TechnicalProfile Id="JwtIssuer">
  <Metadata>
    <Item Key="ClientCredentialsUserJourneyId">ClientCredentialsJourney</Item>
  </Metadata>
</TechnicalProfile>

次の例は、クライアント資格情報のユーザー体験を示しています。最初と最後のオーケストレーション手順は必須です。

<UserJourneys>
  <UserJourney Id="ClientCredentialsJourney">
    <OrchestrationSteps>
      <!-- [Required] Do the client credentials -->
      <OrchestrationStep Order="1" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="ClientCredSetupExchange" TechnicalProfileReferenceId="ClientCredentials_Setup" />
        </ClaimsExchanges>
      </OrchestrationStep>

      <!-- [Optional] Call a REST API or claims transformation -->
      <OrchestrationStep Order="2" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="TokenAugmentation" TechnicalProfileReferenceId="TokenAugmentation" />
        </ClaimsExchanges>
      </OrchestrationStep>

      <!-- [Required] Issue the access token -->
      <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys>

次のステップ

Azure AD B2C でリソース所有者パスワード資格情報フローを設定する方法について理解します