シナリオ:Web API を呼び出すデーモン アプリケーション

  • [アーティクル]

このシナリオでは、Web API を呼び出すデーモン アプリケーションをビルドする方法について説明します。

概要

アプリケーションは、(ユーザーの代わりではなく) 自身の代わりに、Web API を呼び出すトークンを取得できます。 このシナリオでは、デーモン アプリケーションに役立ちます。 これには標準の OAuth 2.0 クライアント資格情報の付与が使用されます。

Daemon apps

デーモン アプリのユース ケースの例としては、次のようなものがあります。

  • プロビジョニングまたはユーザーの管理に使用される、またはディレクトリ内でプロセスのバッチ処理を行う Web アプリケーション
  • バッチ ジョブ (バックグラウンドで実行されているオペレーティング システム サービス) を実行するデスクトップ アプリケーション (Windows 上の Windows サービスや Linux 上のデーモン プロセスなど)
  • 特定のユーザーではなく、ディレクトリを操作する必要がある Web API

デーモン以外のアプリケーションがユーザーに代わって動作する場合でも、クライアント資格情報を使用するもう 1 つの一般的なケースがあります。 これは、技術的な理由から、アプリケーションが自身の ID を使用して Web API またはリソースにアクセスする必要がある場合に発生します。 Azure Key Vault 内のシークレットまたはキャッシュのための Azure SQL Database へのアクセスはその一例です。

デーモン アプリケーションを通常のユーザーのデバイスにデプロイできません。また、通常のユーザーはデーモン アプリケーションにアクセスできません。 限られた IT 管理者のセットのみがデーモン アプリケーションが実行されているデバイスにアクセスできます。 これは、悪意のあるアクターがデバイス トラフィックからクライアント シークレットまたはトークンにアクセスして、デーモン アプリケーションの代わりに動作できないようにするためです。 デーモン アプリケーションのシナリオでは、デバイス認証は置き換えされません。

デーモン以外のアプリケーションの例:

  • アプリケーションの代わりに Web サービスにアクセスするが、ユーザーに代わってアクセスしないモバイル アプリケーション。
  • デバイスの代わりに Web サービスにアクセスするが、ユーザーに代わってアクセスしない IoT デバイス。

自身の ID 用にトークンを取得するアプリケーションは:

  • 機密クライアント アプリケーションがユーザーとは無関係にリソースにアクセスする場合には、自身の ID を証明する必要があります。 これらはかなり機密性の高いアプリであるため、Microsoft Entra テナント管理者によって承認される必要があります。
  • Microsoft Entra ID に登録されたシークレット (アプリケーション パスワードまたは証明書) を持っています。 このシークレットは、トークンを取得するために Microsoft Entra ID への呼び出し中に渡されます。

詳細

デーモン アプリケーションには独自の ID が必要なため、ユーザーが対話することはできません。 この種のアプリケーションは、アプリケーション ID を使用し、アプリケーション ID、資格情報 (パスワードまたは証明書)、アプリケーション ID の URI を Microsoft Entra ID に提示して、アクセス トークンを要求します。 認証が成功すると、デーモンは Microsoft ID プラットフォームからアクセス トークン (および更新トークン) を受け取ります。 このトークンは、Web API の呼び出しに使用されます (必要に応じて更新されます)。

ユーザーはデーモン アプリケーションと対話できないため、増分の同意を実行できません。 必要なすべての API アクセス許可は、アプリケーションの登録時に構成する必要があります。 このアプリケーションのコードでは、静的に定義されたアクセス許可のみが要求されます。 これは、デーモン アプリケーションが増分同意をサポートしないことも意味します。

開発者にとって、このシナリオのエンドツーエンドのエクスペリエンスには、次の側面があります。

  • デーモン アプリケーションは Microsoft Entra テナントでのみ機能します。 Microsoft の個人アカウントを操作しようとするデーモン アプリケーションをビルドする意味はありません。 基幹業務 (LOB) アプリの開発者の場合は、自分のテナント内でデーモン アプリを作成します。 ISV の場合は、マルチテナントのデーモン アプリケーションを作成した方がよいでしょう。 各テナント管理者は、同意を示す必要があります。
  • アプリケーションの登録時に、応答 URI は必要ありません。 Microsoft Entra ID でシークレット、証明書、または署名付きアサーションを共有します。 また、アプリケーションのアクセス許可を要求し、それらのアプリのアクセス許可を使用できるように管理者の同意を与える必要があります。
  • アプリケーションの構成で、アプリケーションの登録時に Microsoft Entra ID と共有されるようにクライアントの資格情報を提供する必要があります。
  • クライアント資格情報フローでトークンを取得するために使用されるスコープは、静的スコープである必要があります。

OAuth 2.0 と OpenID Connect を使用した ID およびアクセス管理 (IAM) を初めて使用する場合、または Microsoft ID プラットフォームの IAM を初めて使用する場合は、次の一連の記事をお読みください。

これらは、最初のクイックスタートまたはチュートリアルを完了する前に読む必要はありませんが、プラットフォームに不可欠なトピックについて説明しており、これらをよく知ると、より複雑なシナリオを構築する際に役立ちます。

認証と権限承認

Microsoft ID プラットフォーム

次のステップ

このシナリオの次の記事「アプリの登録」に進みます。