Microsoft Entra アプリ開発

  • 3 分

Microsoft Entra ID の基本原則と利点について理解が深まったら、どうすればその機能を使用してアプリケーションに認証と認可を実装できるのかを明らかにする必要があります。 顧客のデータにセキュリティを確保するためには、PostgreSQL のアクセスの制御メカニズムと確実に連携するようにアプリケーションを実装する必要があると、あなたは感じています。 あなたは、Microsoft Entra アプリケーションの開発、プロビジョニング、管理に関係するタスクを割り出すことから始めることにしました。 また、アプリケーションへのアクセスを複数の顧客に提供するというニーズにどう対処すればよいかも調べたいと考えています。

Microsoft Entra ID ベースのアプリケーションを実装するには、登録、アクセス許可の構成、シークレットの管理など、アプリケーションに関連したいくつかの管理タスクを行う必要があります。

アプリケーションの登録とは

Microsoft Entra 環境内で作業する際に、ユーザーは以下の 2 つの段階を経てアプリケーションに対する認証を行います。

  1. まず、Microsoft Entra ID がユーザーの ID を検証します。 認証に成功すると、Microsoft Entra ID は認証の成功を反映した情報を含むトークンを発行します。
  2. ユーザーがトークンをアプリケーションに渡します。 アプリケーションは、ユーザーのセキュリティ トークンを検証して、認証が成功したことを確かめます。

そのような検証を実行するには、アプリケーションは Microsoft Entra ID と安全に通信できる必要があります。 次に、これにはアプリケーションそのものが Microsoft Entra セキュリティ プリンシパルとして動作することが必要になります。 これを実現するためには、認証ユーザーのアカウントが含まれるのと同じ Microsoft Entra テナント内で、なんらかの形でアプリケーションが表現されているようにする必要があります。

Microsoft Entra ID には、次の 2 つのアプリケーションの表現が存在します。

  • アプリケーション オブジェクト。アプリケーションのプロパティを定義します。
  • サービス プリンシパル。認証と承認の機能を提供し、アプリケーション オブジェクトを参照します。

アプリケーション オブジェクトは、Azure portal の [アプリの登録] ブレードから直接作成できます。 独自のカスタム アプリケーションでは、このように登録することで、対応するサービス プリンシパルが自動的に作成されます。 その後は、Azure portal の [エンタープライズ アプリケーション] ブレードからサービス プリンシパルを管理できます。

アプリケーションの登録中、必要に応じてアプリケーションのリダイレクト URI (Uniform Resource Identifier) を指定できます。 アプリが正常に承認された後で、承認サーバーによってユーザーがどこにリダイレクトされるかが、その値によって指定されます。 リダイレクト URI には、承認サーバーからコードまたはトークンが送信されるため、アプリ登録プロセスの一環として正しい場所を登録することが大切です。

Note

リダイレクト URI は、https で始める必要がありますが、参照先が localhost である場合は、例外的に http://localhost を使用できます。 また、大文字と小文字が区別されます。

アプリケーションのアクセス許可とは

Microsoft Entra ID と統合されたアプリケーションが従う認可モデルは、Microsoft Entra 統合された他のアプリケーションやリソースに対するアプリケーションのアクセス許可を細かく制御することを可能にします。 Microsoft Entra ID は、これらのアクセス許可を実装するために OAuth 2.0 認可モデルに依存しています。 OAuth 2.0 では、アクセス許可が、一般に "スコープ" と呼ばれるまとまりとして整理されます。

アプリケーションに必要なアクセス許可は、開発者がアプリケーションの構成の中で、アクセス許可文字列を指定することによって要求します。 たとえば、Microsoft Graph でユーザーの予定表を読み取る権限がアプリケーションに必要であることは、アクセス許可文字列を "https://graph.microsoft.com/Calendars.Read"" に設定することで指定します。 アプリケーションには同意を通してこれらのアクセス許可を付与する必要があり、この同意は、そのアクセス許可の程度に応じて Microsoft Entra ユーザーまたは Microsoft Entra 管理者が与える必要があります。

Microsoft Entra ID では、次の 2 種類のアクセス許可がサポートされています。

  • 委任されたアクセス許可は、サインインして利用する対話型のアプリで使用されます。 結果としてアプリは、ターゲット リソースにアクセスする際、サインイン ユーザーの代理で動作します。
  • アプリケーションのアクセス許可は、サインインするユーザーがいないアプリ、たとえばバックグラウンド サービスで使用されます。 これらのアプリには、管理者の同意が必要です。

アプリケーション シークレットとは

サービス プリンシパルで使用できる認証には、

  • パスワードベースの認証。Azure portal で直接生成できるアプリケーション シークレットが利用されます。 シークレットの生成時に、その有効期間を指定します。
  • Microsoft Entra ID にアップロードした証明書に依存する、証明書ベースの認証。

Note

Azure 仮想マシン (VM)、Azure App Service Web アプリ、AKS クラスターなどの Azure コンピューティング リソースをホストとするアプリケーションの場合、アプリケーション ID にはサービス プリンシパルではなく、マネージド ID の使用を検討してください。 そうすれば、認証用のパスワードや証明書を管理する手間がかかりません。

アプリケーション認証の各種シナリオ

認証フローおよび対応する構成の詳細は、アプリケーションの種類によって異なります。 一般に、アプリケーションの種類には、次のようなカテゴリがあります。

  • ブラウザーベースのアプリ。 ブラウザーで実行されている JavaScript または TypeScript アプリによってトークンが取得される Web アプリです。 これらのアプリケーションには多くの場合、Angular、React、Vue などのフレームワークが使用されます。 MSAL.js は、SPA をサポートする唯一の Microsoft Authentication Library です。
  • パブリック クライアント アプリケーション。 常にサインイン ユーザーを利用してトークンを取得するアプリです。 たとえば、サインイン ユーザーの代理で Web API を呼び出すデスクトップ アプリやモバイル アプリが該当します。
  • 機密クライアント アプリケーション。 トークンは独自に取得されます。 Web API を呼び出す Web アプリや、別の Web API を呼び出す Web API、Linux デーモン、Windows サービスがこのカテゴリのアプリに該当します。

上に挙げた最初の 2 つのカテゴリではユーザーが認証されるのに対し、3 つ目のカテゴリで認証されるのは、あくまでユーザーとバックエンド サービスとの間に存在するアプリまたはサービスです。 この場合、バックエンド サービスは、エンド ユーザーについては一切認識せず、エンド ユーザーが使用しているアプリを認識します。 たとえば、バックエンド サービスとして Azure Maps を使用するアプリを考えてみましょう。 Maps サービスは、適切に課金を行ううえで、承認済みのアプリケーションから自分が呼び出されていることを把握すればよく、エンド ユーザーについては何も知っている必要はありません。

シングルテナントとマルチテナントの Microsoft Entra アプリケーションの違いは何ですか?

開発者は、アプリの登録時に、シングルテナントまたはマルチテナントとしてアプリを構成できます。

  • シングルテナント アプリは、それらが登録されているテナント (ホーム テナントと呼ばれます) でのみ使用できます。
  • マルチテナント アプリは、ホーム テナントと他の Microsoft Entra テナントの両方のユーザーが使用できます。

アプリの登録に Azure portal を使用する場合、アプリのテナントを指定するには、その対象ユーザー プロパティを次のいずれかの値に設定します。

  • このディレクトリ内のアカウントのみ。 この場合はシングルテナント構成になります。 実質的に、ゲスト アカウントを含め、対象テナント内のあらゆるセキュリティ プリンシパルにアプリケーションへのアクセス権を与えることができます。
  • 任意の Microsoft Entra ディレクトリ内のアカウント。 この場合はマルチテナント構成になります。 これによって、組織外のユーザーが各自の Microsoft Entra テナントにアプリケーションを登録できます。
  • 任意の Microsoft Entra ディレクトリ内のアカウントと、個人用の Microsoft アカウント (Skype、Xbox、Outlook.com など)。 この場合もマルチテナント構成になりますが、個人用 Microsoft アカウントを持つユーザーがアプリを使用できるようになります。

Note

アプリケーション オブジェクトが存在するのはあくまでホーム テナントですが、マルチテナント構成の場合は、さまざまな Microsoft Entra テナントの複数のサービス プリンシパルから参照することができます。