このエントリは2026/02/12現在の情報に基づいています。将来の機能追加や変更に伴い、記載事項からの乖離が発生する可能性があります。

先日の問い合わせ主から更問が届いた。先日の問い合わせは以下のリンクから。

更問

説明に従って構成したら、確かに認証ができた。で、FunctionsのEnvironment variables（環境変数）のApp settings（アプリ設定）を見ていると、シークレットが定義されているようである。このシークレットを管理しなくてすむようにするにはどうしたらよいか？

ここで言っているクライアントシークレットとは、トークンを要求するときにアプリケーションが ID を証明するために使用するシークレット値で、MICROSOFT_PROVIDER_AUTHENTICATION_SECRETのこと。

このシークレットは、Entra IDのApplication registrations（アプリの登録）でEasy Authを構成している際に取得し、MICROSOFT_PROVIDER_AUTHENTICATION_SECRETという環境変数でApp Service内で利用できる。もちろんこのシークレットが漏洩した場合には変更する必要があり、以下のPortalもしくはCLI、REST APIで変更する。

# Create a secret with default expiration (2 years)
az ad app credential reset --id <app-id> --append
# Create a secret with a custom display name and end date
az ad app credential reset --id <app-id> --append --display-name "MySecret" --end-date "2027-12-31"
# via Microsoft Graph API
az rest --method POST \
  --uri "https://graph.microsoft.com/v1.0/applications/{application-object-id}/addPassword" \
  --headers "content-type: application/json"
  --body "{
      \"passwordCredential\": {
        \"displayName\": \"My Secret\",
        \"endDateTime\": \"2027-12-31T00:00:00Z\"
      }
    }"

再生成したらKey Vaultなどに保管する、といったことを考慮しなくてはならず、少々取り扱いが面倒なので、なんとかしたい、というお問い合わせ。

Previewではあるが

この課題は、Previewではあるが解決する方法がある。

シークレットの代わりにマネージドIDを使用する（プレビュー）/ Use a managed identity instead of a secret (preview)
https://learn.microsoft.com/azure/app-service/configure-authentication-provider-aad?tabs=workforce-configuration#use-a-managed-identity-instead-of-a-secret-preview

これはUser assigned managed identityで利用できるFederation Identity credentialで先ほどのクライアントシークレットをなくす、というもの。基本的にドキュメントに従って構成すれば動作するはずだが、備忘録のために以下に手順と気になったことを記載しておく。

User assigned managed identityを使うには

1. User assigned managed identityの作成

これはそのまんま。ふつうに作成しておく。isolation scope（分離スコープ）はお好みで。

az identity create -g <RESOURCE GROUP> -n <USER ASSIGNED IDENTITY NAME>

2. Managed IdentityのFunctionsへの割り当て

これもふつうに割り当てる。Portalからの場合は、Functionsの Settings > Identity > User assigned タブへと遷移して、作成したUser assigned managed identityを割り当てる。Object IDとClient IDは後で利用するので、この時点で記録しておくとよい。

# Retrieve IDENTITY_ID of user assigned managed identity...
IDENTITY_ID=$(az identity show \
  --name <identity-name> \
  --resource-group <resource-group> \
  --query id \
  --output tsv)
# Assign the IDENTITY_ID to target Functions
az functionapp identity assign \
  --name <function-app-name> \
  --resource-group <resource-group> \
  --identities $IDENTITY_ID

3. アプリケーションでのFederated identity credentialの構成

はまりやすいのはここ。GitHub ActionsやAKSなどの構成であれば、User assigned managed identityから直接構成するが、この例ではEntra ID側で設定する。

アプリケーションでフェデレーション ID 資格情報を構成する / Configure a federated identity credential on an application
https://learn.microsoft.com/entra/workload-id/workload-identity-federation-config-app-trust-managed-identity?tabs=microsoft-entra-admin-center%2Cdotnet#configure-a-federated-identity-credential-on-an-application

1) Entra IDでApp registrations > Manage > Certificates & secrets に移動して、Federated credentialsタブを選択し、Add credentialをクリックする。

2) credentialを追加する。シナリオはManaged identity、先ほど作成したManaged identityを選択し、Nameを設定し、Addをクリックする。

4. Functionsのアプリ設定

FunctionsのApp settingsでOVERRIDE_USE_MI_FIC_ASSERTION_CLIENTIDを追加し、その値として、作成したUser assigned managed identityのClient IDを設定する（Azure FunctionsのClient IDではない）。そして、デプロイメントスロットに固定しておく。

5. Easy Authの構成変更

Easy Authの設定ではClient secret setting nameがデフォルトのMICROSOFT_PROVIDER_AUTHENTICATION_SECRETを使っているので、これをOVERRIDE_USE_MI_FIC_ASSERTION_CLIENTIDに変更し、【Save】をクリックして、設定を保存する。

これでおしまい。

動作確認とクライアントシークレットの削除

ふつうに呼び出して、正しく認証されていればOK。問題なくなった時点で、オリジナルのMICROSOFT_PROVIDER_AUTHENTICATION_SECRETを削除する。

• App Service & Static Web Apps
• Azure
• Functions
• Logic Apps
• Security
• Technology