次の方法で共有


Azure SDK for JavaScript を使用して JavaScript アプリを Azure サービスに対して認証する方法

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

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

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

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

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

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

Azure 用のアプリを構築する場合、シークレット (接続文字列またはキー) よりもトークンベースの認証を強くお勧めします。 トークンベースの認証は、DefaultAzureCredential で提供されます。

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

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

次の SDK を使用します。

DefaultAzureCredential

Azure SDK DefaultAzureCredential メソッドを使用すると、アプリは実行されている環境に応じて異なる認証方法を使用できます。 これにより、アプリはコードを変更することなく、ローカル環境、テスト環境、運用環境にデプロイできます。 環境ごとに適切な認証方法を構成すると、DefaultAzureCredential によりその認証方法が自動的に検出されて使用されます。 さまざまな環境で異なる認証方法を使用するには、条件付きロジックや機能フラグを手動でコーディングするよりも、DefaultAzureCredential を使用することをお勧めします。

DefaultAzureCredential クラスの使用の詳細については、この記事の後半の「アプリケーションで DefaultAzureCredential を使用する」セクションで説明します。

サーバー環境での認証

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

ローカル開発時の認証

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

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

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

npm install @azure/identity

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

// connect-with-default-azure-credential.js
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 クライアント オブジェクトで同じ資格情報オブジェクトを使用できます。

DefaultAzureCredential を使用する際の認証方法の選択シーケンス

内部的には、DefaultAzureCredential は、Azure リソースに対してアプリケーションを認証するための資格情報プロバイダーを選択するチェーンを実装します。 各資格情報プロバイダーでは、その種類の資格情報がアプリ用に構成されているかどうかを検出できます。 DefaultAzureCredential では各プロバイダーを順番にチェックし、資格情報が構成されている最初のプロバイダーの資格情報が使用されます。

複数の資格情報が構成されている場合は、チェーンを通じて資格情報を見つける順序が重要です。

次の図と表に、DefaultAzureCredential で JavaScript の資格情報を検索する順序を示します。

DefaultAzureCredential がアプリケーションに対してどの認証ソースが構成されているかを確認するシーケンスを示す図。

2 つの方法があります。

  • デプロイされたサービス (Azure またはオンプレミス): シーケンスは環境変数で始まり、次にマネージド ID、資格情報の残りの場所 (Visual Studio Code、Azure CLI、Azure PowerShell) で始まります。
  • 開発者のローカル環境: ローカル開発者ワークステーションのチェーンは、IDE の下部バーに表示される Visual Studio Code のサインイン済み Azure ユーザーから始まり、Azure CLI、Azure PowerShell に進みます。 環境全体またはプロジェクトの仮想環境 (DOTENV など) に対してローカル環境変数を構成した場合、これらの変数は、チェーンで最初にチェックされる資格情報であるため、Visual Studio Code -> Azure CLI -> PowerShell チェーンをオーバーライドすることを理解しておくことが重要です。
資格情報の種類 説明
環境 DefaultAzureCredential では、一連の環境変数を読み取り、アプリケーション サービス プリンシパル (アプリケーション ユーザー) がアプリに設定されているかどうかを判断します。 そうであれば、DefaultAzureCredential はこれらの値を使用し、Azure に対してアプリを認証します。

この方法は、サーバー環境で最もよく使用されますが、ローカルで開発する場合も使用できます。
マネージド ID マネージド ID が有効な Azure ホストにアプリケーションがデプロイされている場合、DefaultAzureCredential ではそのアカウントを使用して、Azure に対してアプリを認証します。 マネージド ID を使用した認証については、このドキュメントの「サーバー環境での認証」セクションで説明します。

このメソッドは、アプリケーションが マネージド ID が有効なサービス を使用して Azure でホストされている場合にのみ使用できます。
Visual Studio Code 開発者が Visual Studio Code Azure アカウント プラグインを使用して Azure に対して認証を行った場合、DefaultAzureCredential では、その同じアカウントを使用して Azure に対してアプリを認証します。
Azure CLI 開発者が Azure CLI の az login コマンドを使用して Azure に対して認証を行った場合、DefaultAzureCredential ではその同じアカウントを使用して Azure に対してアプリを認証します。
Azure PowerShell 開発者が Azure PowerShell の Connect-AzAccount コマンドレットを使用して Azure に対して認証を行った場合、DefaultAzureCredential ではその同じアカウントを使用してアプリを Azure に認証します。
Interactive 有効にした場合、DefaultAzureCredential では、現在のシステムの既定のブラウザーを介して開発者を対話形式で認証します。 既定では、このオプションは無効になっています。