Azure Active Directory B2C で OAuth 2.0 クライアント資格情報フローを設定する
"開始する前に"、[ポリシーの種類の選択] セレクターを使用して、設定するポリシーの種類を選択します。 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 スコープが返されます。
アプリのアーキテクチャと登録について、次の図に示します。
手順 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 でリソース所有者パスワード資格情報フローを設定する方法について理解します