Azure Id ライブラリを使用して Azure サービスに対して JavaScript アプリを認証する方法

2025-01-03

アプリケーションがストレージ、Key Vault、Cognitive Services などの Azure リソースにアクセスする必要がある場合は、アプリケーションを Azure に対して認証する必要があります。これは、Azure にデプロイされているか、オンプレミスにデプロイされているか、ローカルの開発者ワークステーションで開発中であるかに関係なく、すべてのアプリケーションに当てはまります。この記事では、Azure SDK for JavaScript を使用するときに Azure に対してアプリを認証するための推奨される方法について説明します。

推奨されるアプリ認証方法

推奨される方法は、Azure リソースに対する認証時に、接続文字列やキーではなく、トークンベースの認証をアプリで使用することです。 Azure Identity ライブラリはトークンベースの認証を提供し、アプリがローカル開発中か、Azure にデプロイされているか、オンプレミスサーバーにデプロイされているかに関係なく、アプリが Azure リソースに対してシームレスに認証できるようにします。

アプリが Azure リソースに対する認証に使用するトークンベースの認証の特定の種類は、アプリが実行されている場所によって異なり、次の図に示します。

環境	認証
ローカル	開発者がローカル開発中にアプリを実行している場合 - アプリは、ローカル開発用のアプリケーションサービスプリンシパルを使用するか、開発者の Azure 資格情報を使用して Azure に対して認証できます。これらの各オプションについては、ローカル開発時の認証セクションで詳しく説明します。
Azure	アプリが Azure でホストされている場合 - アプリは、マネージド ID を使用して Azure リソースに対して認証する必要があります。このオプションについては、サーバー環境での認証セクションで詳しく説明します。
オンプレミス	アプリがオンプレミスでホストおよびデプロイされている場合- アプリは、アプリケーションサービスプリンシパルを使用して Azure リソースに対して認証する必要があります。このオプションについては、サーバー環境での認証セクションで詳しく説明します。

アプリの実行場所に応じて推奨されるトークンベースの認証戦略を示す図。

トークンベースの認証の利点

Azure 用のアプリを構築する場合は、接続文字列やキーなどのシークレットではなく、トークンベースの認証を使用することを強くお勧めします。 DefaultAzureCredential では、トークンベースの認証が提供されます。

トークンベースの認証	シークレット (接続文字列とキー)
最小特権の原則、Azure リソースでアプリに必要な特定のアクセス許可を確立します。	接続文字列またはキーは、Azure リソースに対する完全な権限を付与します。
保存するアプリケーションシークレットはありません。	アプリ設定または環境変数にシークレットを格納してローテーションする必要があります。
Azure ID ライブラリは、バックグラウンドでトークンを管理します。これにより、トークンベースの認証を接続文字列と同じくらい簡単に使用できます。	シークレットは管理されません。

接続文字列の使用は、運用環境や機密データにアクセスしない概念実証アプリまたは開発プロトタイプに限定する必要があります。それ以外の場合は、Azure リソースに対する認証時に、Azure ID ライブラリで使用できるトークンベースの認証クラスを常に優先する必要があります。

次のライブラリを使用します。

@azure/identity

DefaultAzureCredential

Azure Identity ライブラリによって提供される DefaultAzureCredential クラスを使用すると、アプリは実行環境に応じて異なる認証方法を使用できます。この動作により、アプリをローカル開発からテスト環境に昇格し、コードを変更せずに運用環境に昇格できます。環境ごとに適切な認証方法を構成すると、DefaultAzureCredential はその認証方法を自動的に検出して使用します。異なる環境で異なる認証方法を使用するには、条件付きロジックまたは機能フラグを手動でコーディングするよりも、DefaultAzureCredential を使用することをお勧めします。

の使用方法の詳細については、「アプリケーションでを使用する」を参照してください。

サーバー環境での認証

サーバー環境でホストする場合、各アプリケーションには、環境ごとに一意の アプリケーション ID 割り当てる必要があります。 Azure では、アプリ ID は、サービスプリンシパル(Azure に対するアプリの識別と認証を目的とした特殊な種類の セキュリティプリンシパル によって表されます。アプリに使用するサービスプリンシパルの種類は、アプリが実行されている場所によって異なります。

ローカル開発時の認証

ローカル開発中に開発者のワークステーションでアプリケーションを実行する場合、ローカル環境は、アプリで使用されるすべての Azure サービスに対して認証を行う必要があります。

アプリケーションで DefaultAzureCredential を使用する

DefaultAzureCredential は、Microsoft Entra ID に対する認証のための、堅牢な順序付けられた一連のメカニズムです。各認証メカニズムは、TokenCredential クラスから派生したクラスであり、資格情報と呼ばれます。実行時に、DefaultAzureCredential は最初の資格情報を使用して認証を試みます。その資格情報がアクセストークンの取得に失敗した場合は、アクセストークンが正常に取得されるまで、シーケンス内の次の資格情報が試行されます。これにより、アプリは環境固有のコードを記述することなく、異なる環境で異なる資格情報を使用できます。

DefaultAzureCredential を使用するには、@azure/identity パッケージをアプリケーションに追加します。

npm install @azure/identity

次に、次のコードサンプルは、DefaultAzureCredential オブジェクトをインスタンス化し、Azure SDK サービスクライアントクラス (この場合は Azure Blob Storage へのアクセスに使用される BlobServiceClient) と共に使用する方法を示しています。

import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config';

const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  new DefaultAzureCredential()
);

DefaultAzureCredential は、アプリ用に構成された認証メカニズムを自動的に検出し、Azure に対してアプリを認証するために必要なトークンを取得します。アプリケーションで複数の SDK クライアントを使用する場合は、各 SDK クライアントオブジェクトで同じ資格情報オブジェクトを使用できます。

次の方法で共有