この記事では、証明書やクライアント シークレットを管理せずにアプリケーションがMicrosoft Entra IDで認証されるように、証明書なしの認証を構成する方法について説明します。 アプリでは、Azureマネージド ID によってサポートされるフェデレーション ID 資格情報 (FIC) を使用してトークンを取得します。これにより、資格情報のローテーションが不要になり、シークレットの拡散が軽減され、Azureデプロイが簡略化されます。
Microsoft。Identity.Web では、バージョン 2.12.0 以降で使用可能な SignedAssertionFromManagedIdentity 資格情報ソースの種類を使用した証明書レス認証がサポートされています。
証明書なしの認証について
このセクションでは、証明書なしの認証のしくみと、それを使用するタイミングについて説明します。
従来、機密クライアント アプリケーションは、クライアント シークレットまたは証明書を提示することで、Microsoft Entra ID に対して本人確認を行います。 どちらの方法でも、資格情報のライフサイクルを管理する必要があります。つまり、有効期限が切れる前にシークレットをローテーションし、証明書を更新し、安全に保存する必要があります。
フェデレーション ID 資格情報 (FIC) によってこのモデルが変更されます。 FIC では、アプリの登録とマネージド ID の間に信頼関係を構成します。 アプリケーションを認証する必要がある場合:
- Microsoft。Identity.Web は、Azure ホスト上のマネージド ID エンドポイントからトークンを要求します。
- ライブラリは、マネージド ID トークンを署名付きアサーションとして使用して、Microsoft Entra IDで認証します。
- Microsoft Entra IDは、アプリの登録時にフェデレーション資格情報構成に対して署名済みアサーションを検証します。
- Microsoft Entra IDは、要求されたリソースのアクセス トークンを発行します。
その結果、構成、コード、または環境変数にシークレットや証明書が存在しない、完全に資格情報のないデプロイになります。
適切な認証方法を選択する
次の表は、証明書なしの認証が適切な選択であるタイミングを判断するのに役立ちます。
| シナリオ | 推奨される方法 |
|---|---|
| アプリはAzureで実行され、資格情報の管理をゼロにする必要がある | FIC を使用した証明書なし |
| アプリはAzureで実行されますが、オンプレミスのフォールバックをサポートする必要があります | FIC をプライマリとして使用する証明書ベースの資格情報 |
| アプリはAzure (オンプレミス、その他のクラウド) の外部で実行されます | 証明書またはクライアント シークレット |
| ローカル コンピューターでの開発とテスト | ローカル ストアからのクライアント シークレットまたは証明書 |
前提条件
開始する前に、次のリソースとツールがあることを確認します。
- Azure サブスクリプション。 アカウントがない場合は、無料アカウントを作成してください。
- Microsoft Entra ID で、シナリオに必要な API アクセス許可を持つ アプリ登録。
- Azure内の Managed Identity、つまり、コンピューティング リソースにシステムによって割り当てられるもの、またはスタンドアロンでユーザーによって割り当てられるものとして機能するマネージドID。
- Microsoft。Identity.Web バージョン 2.12.0 以降がプロジェクトにインストールされています。
- Azure App Service、Azure Kubernetes Service (AKS)、Azure Container Apps、Azure 仮想マシンなど、マネージド ID をサポートするAzure コンピューティング リソース。
手順 1: マネージド ID を作成または識別する
システム割り当てマネージド ID またはユーザー割り当てマネージド ID を使用できます。 まだ作成していない場合は、シナリオの指示に従います。
オプション A: システム割り当てマネージド ID を使用する
システム割り当てマネージド ID は、Azure リソースのライフサイクルに関連付けられます。 App Service などのリソースでシステム割り当て ID を有効にすると、Azureによって ID が自動的に作成されます。
- Azure ポータルで、コンピューティング リソース (App Service など) に移動します。
- 左側のナビゲーション メニューから [ID] を 選択します。
- [システム割り当て済み] タブで、[状態] を [オン] に設定します。
- [ 保存] を 選択し、アクションを確認します。
- ID が作成されたら、 オブジェクト (プリンシパル) ID をコピーします。 この値は、フェデレーション資格情報を構成するときに必要です。
オプション B: ユーザー割り当てマネージド ID を作成する
ユーザー割り当てマネージド ID は、1 つ以上のコンピューティング リソースに割り当てることができるスタンドアロン Azure リソースです。
- Azure ポータルで、Managed Identities を検索して選択します。
- を選択してを作成します。
- サブスクリプション、リソース グループ、リージョンを選択し、ID の名前を入力します。
- [ 確認と作成]、[ 作成] の順に選択します。
- デプロイが完了したら、新しいマネージド ID リソースを開きます。
- [概要] ページからクライアント ID をコピーします。 この値は、アプリケーション構成に必要です。
手順 2: Azure ポータルでフェデレーション ID 資格情報を構成する
フェデレーション ID 資格情報は、アプリの登録とマネージド ID の間に信頼関係を確立します。 次の手順に従って作成します。
Azure ポータルで、Microsoft Entra ID>アプリの登録 に移動します。
アプリケーションで使用するアプリの登録を選択します。
左側のナビゲーション メニューで、[ 証明書とシークレット] を選択します。
[ フェデレーション資格情報 ] タブを選択します。
資格情報の追加を選択します。
[フェデレーション資格情報のシナリオ] で、[カスタマー マネージド キー] または [その他の発行者] を選択します (使用可能なオプションは、ポータルのバージョンによって異なります)。
次のフィールドを構成します。
フィールド 価値 発行者 https://login.microsoftonline.com/{tenant-id}/v2.0—{tenant-id}をMicrosoft Entraテナント ID に置き換えます。サブジェクト識別子 マネージド ID の オブジェクト (プリンシパル) ID 。 システム割り当ての場合は、リソースの [ID] ページでこれを見つけます。 ユーザー割り当ての場合は、マネージド ID の [概要] ページの [プリンシパル ID] でこれを見つけます。 氏名 わかりやすい名前 (例: fic-managed-identity-prod)。オーディエンス api://AzureADTokenExchange(既定値)。[] を選択し、[] を追加します。
Important
サブジェクト識別子は、マネージド ID のオブジェクト (プリンシパル) ID と正確に一致する必要があります。 不一致により、認証が失敗し、 AADSTS70021 エラーが発生します。
Azure CLIを使用してフェデレーション ID 資格情報を構成する
または、Azure CLIを使用してフェデレーション資格情報を作成します。 次のコマンドは、アプリの登録時に資格情報を作成します。
az ad app federated-credential create \
--id <app-object-id> \
--parameters '{
"name": "fic-managed-identity-prod",
"issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
"subject": "<managed-identity-principal-id>",
"audiences": ["api://AzureADTokenExchange"],
"description": "FIC for production managed identity"
}'
Azure サービス別の発行者 URL
フェデレーション資格情報の発行者 URL は、アプリケーションをホストするAzure サービスによって異なります。
| Azure サービス | 発行者 URL |
|---|---|
| Azure App Service/Azure Functions | https://login.microsoftonline.com/{tenant-id}/v2.0 |
| Azure Container Apps | https://login.microsoftonline.com/{tenant-id}/v2.0 |
| Azure Kubernetes Service (AKS) | クラスターの OIDC 発行者 URL ( az aks show --query oidcIssuerProfile.issuerUrlで取得) |
| Azure 仮想マシン | https://login.microsoftonline.com/{tenant-id}/v2.0 |
サブジェクト識別子の形式
サブジェクト識別子の形式は、マネージド ID の種類によって異なります。
システム割り当てマネージド ID — リソースの [ID ] ページのオブジェクト (プリンシパル) ID を使用します。 これは GUID 値です (たとえば、 a1b2c3d4-e5f6-7890-abcd-ef1234567890)。
ユーザー割り当てマネージド ID - マネージド ID リソースの [概要] ページからプリンシパル ID (オブジェクト ID とも呼ばれます) を使用します。 これは GUID 値でもあります。
注
ワークロード ID を持つ AKS の場合、サブジェクト識別子は別の形式 ( system:serviceaccount:{namespace}:{service-account-name}) を使用します。 この値は、ポッドが使用する Kubernetes サービス アカウントと一致する必要があります。
手順 3: アプリケーションを構成する
appsettings.json の更新
ClientCredentials構成に AzureAd セクションを追加します。
SourceType を SignedAssertionFromManagedIdentity に設定します。
ユーザー割り当てマネージド ID の場合
{
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"TenantId": "YOUR_TENANT_ID",
"ClientId": "YOUR_CLIENT_ID",
"ClientCredentials": [
{
"SourceType": "SignedAssertionFromManagedIdentity",
"ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
}
]
}
}
次のプレースホルダーを置き換えてください。
| プレースホルダー | 説明 |
|---|---|
YOUR_TENANT_ID |
Microsoft Entra テナント ID。 |
YOUR_CLIENT_ID |
アプリ登録のアプリケーション (クライアント) ID。 |
USER_ASSIGNED_MSI_CLIENT_ID |
ユーザー割り当てマネージド ID のクライアント ID (ID の [概要] ページから)。 |
システム割り当てマネージド ID の場合
システム割り当てマネージド ID を使用する場合は、 ManagedIdentityClientId プロパティを省略します。 Microsoft。Identity.Web では、ホストのシステム割り当て ID が自動的に使用されます。
{
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"TenantId": "YOUR_TENANT_ID",
"ClientId": "YOUR_CLIENT_ID",
"ClientCredentials": [
{
"SourceType": "SignedAssertionFromManagedIdentity"
}
]
}
}
Program.csにサービスを登録する
スタートアップ構成では、特別なコード変更は必要ありません。 標準Microsoft。Identity.Web 登録メソッドは、ClientCredentials セクションを自動的に読み取ります。
次の例では、ユーザーをサインインさせ、ダウンストリーム API を呼び出す Web アプリの認証を登録します。
// For a web app that signs in users and calls downstream APIs
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
.EnableTokenAcquisitionToCallDownstreamApi()
.AddInMemoryTokenCaches();
次の例では、ダウンストリーム API を呼び出す Web API の認証を登録します。
// For a web API that calls downstream APIs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
.EnableTokenAcquisitionToCallDownstreamApi()
.AddInMemoryTokenCaches();
次の例では、ユーザー操作なしでデーモン アプリケーションの認証を登録します。
// For a daemon application (no user interaction)
builder.Services.AddAuthentication()
.AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));
builder.Services.AddTokenAcquisition()
.AddInMemoryTokenCaches();
Microsoft。Identity.Web は、SignedAssertionFromManagedIdentity ソースの種類を検出し、トークン交換を透過的に処理します。
システム割り当てマネージド ID とユーザー割り当てマネージド ID を比較する
アーキテクチャに最適なマネージド ID の種類を選択します。 次のセクションでは、トレードオフについて説明します。
システム割り当てマネージド ID
システム割り当て ID は、それが属するAzure リソースを使用して自動的に作成および削除されます。
長所:
- 管理する個別のリソースはありません。ID ライフサイクルはコンピューティング リソースと一致します。
- 単一リソースデプロイのセットアップが簡単です。
- 構成には
ManagedIdentityClientIdは必要ありません。
Considerations:
- 複数のリソース間で ID を共有することはできません。
- リソースを削除して再作成すると、ID が変更されます。フェデレーション ID 資格情報を更新する必要があります。
次の場合に最適です。 1 つのコンピューティング リソースが 1 つのアプリ登録にマップされる単一インスタンスデプロイ。
ユーザー割り当てマネージド ID
ユーザー割り当て ID は、独自のライフサイクルを持つスタンドアロン Azure リソースです。
長所:
- 複数のコンピューティング リソース間で 1 つの ID を共有します (たとえば、異なるリージョンの複数の App Service インスタンス)。
- ID は、コンピューティング リソースのライフサイクルとは無関係に保持されます。
- コンピューティング リソースをデプロイする前に、事前に作成して事前構成します。
Considerations:
- 管理する追加のAzure リソース。
- 構成で
ManagedIdentityClientIdを指定する必要があります。
次の場合に最適です。 複数インスタンスまたは複数リージョンのデプロイ、ブルーグリーンのデプロイ パターン、コンピューティング リソースが頻繁に再作成されるシナリオ。
Azure コンピューティング サービスにデプロイする
アプリケーションを構成したら、マネージド ID をサポートする Azure コンピューティング サービスにデプロイします。
Azure App Service
App Service でマネージド ID を有効にします ( 手順 1 を参照)。
任意の方法 (Visual Studio、Azure CLI、GitHub Actions) を使用して、アプリケーションを App Service にデプロイします。
デプロイした構成の
AzureAdセクションが 手順 3 の設定と一致していることを確認します。ユーザー割り当てマネージド ID を使用する場合は、App Service に割り当てます。
az webapp identity assign \ --resource-group <resource-group> \ --name <app-service-name> \ --identities <managed-identity-resource-id>App Service を再起動して、ID の割り当てを取得します。
Azure Kubernetes サービス (AKS)
AKS の場合は、ワークロード ID を使用して、Kubernetes サービス アカウントをマネージド ID に関連付けます。 次の手順を実行します。
AKS クラスターでワークロード ID 機能を有効にします。
az aks update \ --resource-group <resource-group> \ --name <aks-cluster-name> \ --enable-oidc-issuer \ --enable-workload-identityマネージド ID クライアント ID で注釈が付けられた Kubernetes サービス アカウントを作成します。
apiVersion: v1 kind: ServiceAccount metadata: name: my-app-sa namespace: default annotations: azure.workload.identity/client-id: "<USER_ASSIGNED_MSI_CLIENT_ID>"AKS OIDC 発行者をマネージド ID にリンクするフェデレーション資格情報を作成します。
サービス アカウントを使用するようにポッドを構成します。
apiVersion: v1 kind: Pod metadata: name: my-app namespace: default labels: azure.workload.identity/use: "true" spec: serviceAccountName: my-app-sa containers: - name: my-app image: <your-container-image>ポッドをデプロイします。 ワークロード ID Webhook は、マネージド ID トークン エンドポイントに必要な環境変数を挿入します。
Azure Container Apps
マネージド ID を使用してコンテナー アプリを作成または更新します。
az containerapp identity assign \ --resource-group <resource-group> \ --name <container-app-name> \ --user-assigned <managed-identity-resource-id>適切な
AzureAd構成でコンテナー イメージをデプロイします。マネージド ID トークン エンドポイントは、コンテナー内で自動的に使用できます。
証明書から証明書なしの認証に移行する
アプリケーションで現在証明書ベースの認証を使用している場合は、構成を最小限に抑えて証明書なしの認証に移行できます。
移行手順を完了する
Azure コンピューティング リソースのマネージド ID を作成します (Step 1 )。フェデレーション ID 資格情報をアプリの登録に追加します (手順 2 を参照)。
構成を更新 して、
SignedAssertionFromManagedIdentity資格情報を追加します。 移行中は、既存の証明書資格情報をフォールバックとして保持できます。{ "AzureAd": { "Instance": "https://login.microsoftonline.com/", "TenantId": "YOUR_TENANT_ID", "ClientId": "YOUR_CLIENT_ID", "ClientCredentials": [ { "SourceType": "SignedAssertionFromManagedIdentity", "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID" }, { "SourceType": "KeyVault", "KeyVaultUrl": "https://your-keyvault.vault.azure.net", "KeyVaultCertificateName": "your-cert-name" } ] } }Microsoft。Identity.Web は、資格情報ソースを順番に試行します。 Azureで実行すると、最初の資格情報 (
SignedAssertionFromManagedIdentity) が成功します。 失敗した場合 (たとえば、ローカル開発中)、ライブラリは証明書にフォールバックします。運用環境に適用する前に、ステージング環境にデプロイして検証します。
証明書 なしの認証が運用環境で動作することを確認した後、構成から証明書資格情報を削除します。
Azure Key Vaultから証明書を削除し、不要になったらアプリの登録を削除します。
構成の前後を比較する
次の例は、証明書ベースから証明書レス認証への構成の変更を示しています。
従来の(証明書ベース):
{
"AzureAd": {
"ClientCredentials": [
{
"SourceType": "KeyVault",
"KeyVaultUrl": "https://your-keyvault.vault.azure.net",
"KeyVaultCertificateName": "your-cert-name"
}
]
}
}
証明書不要の場合:
{
"AzureAd": {
"ClientCredentials": [
{
"SourceType": "SignedAssertionFromManagedIdentity",
"ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
}
]
}
}
一般的なエラーのトラブルシューティング
証明書なしの認証に関する問題を診断して解決するには、次のガイダンスを使用します。
AADSTS70021: 一致するフェデレーション ID レコードが見つかりません
原因: フェデレーション ID 資格情報のサブジェクト識別子が、マネージド ID のオブジェクト (プリンシパル) ID と一致しません。
解決方法:
- Azure ポータルで、マネージド ID リソースに移動し、Principal ID (オブジェクト ID とも呼ばれます) を Overview ページからコピーします。
- アプリ登録の>に移動し、>を確認します。
- [サブジェクト識別子] フィールドがプリンシパル ID と正確に一致するかどうかを確認します。
- 値が一致しない場合は、資格情報を削除し、正しいサブジェクト識別子で再作成します。
AADSTS700024: クライアント アサーションが有効な時間範囲に含まれていません
原因: 署名付きアサーションの有効期限が切れているか、システム クロックが偏っている場合に使用されるマネージド ID トークン。
解決方法:
- Azure リソースのシステム クロックが正確であることを確認します。
- アプリケーションを再起動して、新しいマネージド ID トークン要求を強制します。
- コンテナーで実行する場合は、コンテナーのクロックがホストと同期されていることを確認します。
ManagedIdentityException: マネージド ID エンドポイントを使用できません
Cause: アプリケーションは、Azure インスタンス メタデータ サービス (IMDS) またはマネージド ID トークン エンドポイントに到達できません。
解決方法:
- マネージド ID をサポートするAzureコンピューティング リソースでアプリケーションが実行されていることを確認します。
- マネージド ID が有効になっており、コンピューティング リソースに割り当てられているかどうかを確認します。
- AKS の場合は、ワークロード ID webhook が実行されており、ポッドに正しいサービス アカウント注釈があることを確認します。
- ローカル開発では、このエラーが発生する可能性があります。 フォールバック資格情報ソースを使用します ( 移行手順を参照)。
AADSTS700016: ディレクトリにアプリケーションが見つかりません
原因: 構成の ClientId が、指定したテナントでの有効なアプリ登録と一致しません。
解決方法:
-
ClientIdがアプリ登録のアプリケーション (クライアント) ID と一致するかどうかを確認します。 -
TenantIdが、アプリが登録されているテナントと一致するかどうかを確認します。
デバッグログを有効化する
原因: 資格情報ソースの順序または構成の不一致により、ライブラリが FIC 資格情報をスキップする可能性があります。
解決方法:
Microsoft.Identity.Webでログ記録を有効にして、トークン取得の詳細な手順を確認します。 次のコードは、ID ライブラリのデバッグ レベルのログ記録を構成します。
builder.Services.AddLogging(logging => { logging.AddConsole(); logging.SetMinimumLevel(LogLevel.Debug); logging.AddFilter("Microsoft.Identity", LogLevel.Debug); });ライブラリが試行した資格情報ソースと返されたエラーに関するメッセージのログを確認します。
ユーザー割り当てマネージド ID が取得されない
原因: 複数のユーザー割り当てマネージド ID がコンピューティング リソースに割り当てられている場合、 ManagedIdentityClientId が指定されていない場合、ライブラリで間違った ID が使用される可能性があります。
解決方法:
- ユーザー割り当てマネージド ID を使用する場合は、常に
ManagedIdentityClientIdプロパティを指定します。 - クライアント ID が、フェデレーション ID 資格情報を構成した ID と一致するかどうかを確認します。
セキュリティ上の利点を確認する
FIC を使用した証明書レス認証は、従来の資格情報ベースのアプローチよりも大きなセキュリティ上の利点を提供します。
漏えいするシークレットなし
構成または展開成果物には証明書ファイル、PFX パスワード、またはクライアント シークレットが存在しないため、攻撃者が抽出するものはありません。 攻撃者が構成ファイルへの読み取りアクセス権を取得した場合でも、Azureの外部からアプリケーションを偽装することはできません。
資格情報のローテーションなし
マネージド ID トークンは有効期間が短く、Azure プラットフォームによって自動的に更新されます。 ローテーション スケジュールを実装したり、有効期限を監視したり、デプロイ全体で資格情報の更新を調整したりする必要はありません。
攻撃面の縮小
マネージド ID トークン エンドポイントには、ID が割り当てられている特定のAzure リソースからのみアクセスできます。 攻撃者は、別のホスト、ネットワーク、またはクラウド環境の資格情報を使用できません。
コンプライアンスの簡素化
有効期間が長い資格情報がないと、コンプライアンスに関するいくつかのカテゴリの問題を排除できます。
- ソース管理、環境変数、または構成ファイルに格納されているシークレットはありません。
- 監査、ローテーション、または取り消しを行う重要な資料はありません。
- 保守する証明書インフラストラクチャ (CA、更新プロセス) はありません。
多層防御
証明書なしの認証を他のAzureセキュリティ機能と組み合わせて、階層型保護を実現します。
- Azure RBAC: どの ID がどのリソースにアクセスできるかを制御します。
- 条件付きアクセス: ID のリスク、場所、デバイスの状態に基づいてポリシーを適用します。
- Private エンドポイント: Azure リソースへのネットワーク アクセスを制限します。
- Microsoft Defender for Cloud: 疑わしい認証パターンを監視します。