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

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

OAuth 2.0 クライアント資格情報付与フローでは、アプリ (機密クライアント) は、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 スコープを返します。

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

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

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

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

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

2. ご自分の Azure AD B2C テナントが含まれるディレクトリを必ず使用してください。 ポータル ツールバーの [Directories + subscriptions](ディレクトリ + サブスクリプション) アイコンを選択します。

3. [ポータルの設定] | [Directories + subscriptions](ディレクトリ + サブスクリプション) ページの [ディレクトリ名] の一覧で自分の Azure AD B2C ディレクトリを見つけて、 [切り替え] を選択します。

4. Azure portal で、 [Azure AD B2C] を検索して選択します。

5. [アプリの登録] を選択し、[新しい登録] を選択します。

6. アプリケーションの名前を入力します (my-api1 など)。 [リダイレクト URI] と [サポートされているアカウントの種類] を既定値のままにします。

7. 登録 を選択します。

8. アプリ登録が完了したら、 [概要] を選択します。

9. アプリケーション (クライアント) ID の値を記録しておきます。これは、後で Web アプリケーションを構成するときに使用します。

   

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

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

1. my-api1 など、作成した Web API を選択します。

2. [ 管理] で、[ API の公開] を選択します。

3. [アプリケーション ID URI] の横にある [設定] リンクを選択します。 既定値 (GUID) を一意の名前 ( api など) に置き換え、[保存] を選択 します。

4. アプリケーション ID URI をコピーします。 次のスクリーンショットは、アプリケーション ID URI をコピーする方法を示しています。

   

5. [ 管理] で [ マニフェスト ] を選択し、アプリケーション マニフェスト エディターを開きます。 エディターで、 appRoles 設定を見つけて、 applicationsを対象とするアプリ ロールを定義します。 各アプリケーションのロール定義には、そのid 値に対して一意のグローバル識別子 (GUID) が必要です。 Microsoft PowerShell またはオンライン GUID ジェネレーターで new-guidcommand を実行して、新しい 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"
   }],
   

6. ページの上部にある [ 保存] を選択してマニフェストの変更を保存します。

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

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

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

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

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

1. Azure portal で、Azure AD B2C を検索して選択します

2. [アプリの登録] を選択し、[新しい登録] を選択します。

3. アプリケーションの名前を入力します。 たとえば、 ClientCredentials_app。

4. 他の値はそのままにして、[ 登録] を選択します。

5. 後の手順で使用する アプリケーション (クライアント) ID を 記録します。

   

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

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

1. [管理] で、[証明書とシークレット] を選択します。

2. 新しいクライアント シークレットを選択します。

3. [ 説明 ] ボックスに、クライアント シークレットの説明 ( clientsecret1 など) を入力します。

4. [有効期限] で、シークレットが有効な期間を選択してから、 [追加] を選択します。

5. シークレットの値を記録します。 この値は、後の手順で構成に使用します。

   

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

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

1. [ アプリの登録] を選択し、作成したアプリ (アプリ 1) を選択します。

2. [管理] で API 許可を選択します。

3. [構成されたアクセス許可] の下で [アクセス許可の追加] を選択します。

4. [ マイ API ] タブを選択します。

5. Web アプリケーションにアクセスを許可する API (アプリ 2) を選択します。 たとえば、「my-api1」と入力します。

6. [ アプリケーションのアクセス許可] を選択します。

7. [アクセス許可] でアプリを展開し、前に定義したスコープ (app.read や app.write など) を選択します。

   

8. アクセス許可の追加 を選択します。

9. [<テナント名> に管理者の同意を与えます] を選択します。

10. [はい] を選択します。

11. [最新の情報に更新] を選択し、両方のスコープの [状態] に、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>を、ユーザー フローの完全な名前またはカスタム ポリシーに置き換えます。 すべての種類のユーザー フローとカスタム ポリシーは、クライアント資格情報フローをサポートします。 持っている任意のユーザー フローまたはカスタム ポリシーを使用することも、サインアップやサインインなどの新しいポリシーを作成することもできます。

実際の 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=11112222-bbbb-3333-cccc-4444dddd5555
&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": "11112222-bbbb-3333-cccc-4444dddd5555"
}

リターン アクセス トークン 要求について説明します。 次の表に、クライアント資格情報フローに関連する要求を示します。

手順 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: トークンをカスタマイズする

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