Microsoft Entra ID を使用してアプリケーションやユーザーを認証する

  • [アーティクル]

アプリにとって主要な Microsoft Entra ID の機能は認証です。これはユーザーがユーザー名や電子メール アドレスなどの個人識別子を使用して ID を宣言するプロセスです。 ID の証明が提供されます。 証明には、パスワード、多要素認証アーティファクト、生体認証、またはパスワードレスの同意が考えられます。

この記事では、アプリケーションで Microsoft Entra ID を使用してユーザーやアプリケーションを認証する方法について説明します。 これは、独立系ソフトウェア開発者 (ISV) が Microsoft Entra ID 用にアプリケーションを構築および最適化する方法に関する一連の記事の 3 つ目です。 このシリーズでは、次のトピックの詳細を確認できます:

トークンの要求

アプリケーションは、Microsoft Entra ID からトークンを要求します。 アプリはトークンを受け取った後、そのトークン内の情報を使用してユーザーを識別できます。 Microsoft Entra ID を基に構築すると、ユーザーは登録された 1 つの Microsoft Entra ID アカウント (SSO) を使用して多くのアプリケーションを認証できます。 SSO 認証方法を使用すると、ユーザーは 1 セットの資格情報を使用して複数の独立系ソフトウェア システムにサインインできます。

開発者が Microsoft Entra ID にトークンを要求するために使用できるプロトコルでは、ブラウザーを使用してユーザーを Microsoft Entra ID Web サイトに接続します。 この Web サイトを使用すると、ユーザーは Microsoft Entra ID とプライベートな会話を行うことができます。 アプリケーションは、そのプライベートな会話の参加者ではありません。 アプリは、ユーザーが認証プロセスを開始する Microsoft Entra ID Web サイトを起動します。 認証プロセスが完了すると、Microsoft Entra ID は、トークンの有無にかかわらず、ユーザーをアプリケーションにリダイレクトします。

ユーザーが認証プロセスを実行する必要がないことが重要です。 ユーザーがそうしなければならない頻度が高いほど、フィッシング攻撃などの悪用の影響を受けやすくなります。

サインイン プロンプトを減らす

SSO を使用すると、サインイン プロンプトを減らしたり排除したりできます。 開発者は、サインイン プロンプトを減らして排除する上で重要な役割を果たします。 すべてのアプリは、ユーザーが認証プロセスを実行する Microsoft Entra ID Web サイトにアクセスするブラウザーを共有する必要があります。 アプリがブラウザー ベースのシングル ページ アプリケーション (SPA) または Web アプリである場合、開発者の手順は必要ありません。 ブラウザー内のすべてのアプリがブラウザーを共有します。 デスクトップとモバイル デバイスで実行されるネイティブ アプリケーションの場合、開発者はサインイン プロンプトをあらかじめ減らすか、または排除する必要があります。

サインイン プロンプトを減らすか排除する最善の方法は、Microsoft 認証ライブラリ (MSAL) または MSAL に基づいて構築されたライブラリ、およびブローカー認証を使用することです。 この方法では、サインイン プロンプトを最小限に抑え、最もシームレスなエクスペリエンスを提供します。 MSAL でビルドできない場合は、アプリケーションでシステム ブラウザーを使用してサインイン プロンプトを最小限に抑える必要があります。

iOS または Android で実行されているアプリの場合、モバイル プラットフォーム プロバイダーには、このエクスペリエンスをよりシームレスにするためのいくつかの機能があります。 Google には、Chrome カスタム タブを使用した Android アプリケーション向けのガイダンスがあります。 Apple には、iOS アプリケーションで Web サービスを介してユーザーを認証するためのガイダンスがあります。 埋め込み WebView は、アプリ間やシステム ブラウザーとの共有を許可しない可能性があるため、使用しないでください。

ユーザー認証の 2 つのプロトコルは、Security Assertion Markup Language (SAML) 2.0 と OpenID Connect (OIDC) です。 Microsoft Entra ID はいずれのプロトコルを使用するアプリも完全にサポートしているため、開発者は要件に基づいていずれかを選択できます。

これらのリファレンスでは、Microsoft Entra ID SAML のサポートについて詳しく説明します。

Microsoft Entra ID SAML サポートにはいくつかの制限があります。 具体的には、WS-Trust ActAs パターンと SAML アーティファクト解決のサポートというプロトコル機能を必要とするアプリを移行することはできません。

Microsoft Entra ID は SAML プロトコル上に構築されたアプリの SAML を完全にサポートしていますが、Microsoft ID プラットフォームには、SAML を使用してアプリケーションを開発するためのライブラリやその他の開発ツールは用意されていません。 新しいアプリケーション開発では、認証に OpenID Connect (OIDC) を使用することをお勧めします。

Microsoft Entra ID は OpenID Connect を完全にサポートしています。 Microsoft では、OIDC アプリケーションの開発を容易にするために、MSAL、Microsoft Identity Web、および Azure SDK ライブラリを提供しています。 「Microsoft ID プラットフォーム上の OpenID Connect (OIDC)」では、Microsoft Entra ID OIDC のサポートについて詳しく説明します。 MSAL は OIDC を自動的にサポートします。 MSAL は、リソースにアクセスするためのアプリの承認要求を含め、各トークン要求で常に OIDC ID トークンを要求します。

トークンの有効期間

MSAL は、アクセス トークンの有効期限に基づいて ID トークンとアクセス トークンをキャッシュします。 Microsoft Entra ID では ID トークンとアクセス トークンの有効期間が異なるので、アクセス トークンがまだ有効期間内である間に、期限切れの MSAL キャッシュから期限切れの ID トークンを受け取る可能性があります。

MSAL は ID トークンを自動的に更新しません。 MSAL は、アプリケーションがトークンを要求したときに、アクセス トークンの有効期間の終了時点 (またはその近く) でアクセス トークンを更新します。 その時点で、MSAL は新しい ID トークンを要求します。 OIDC を実装するには、ID トークンの exp (有効期限が切れた) 要求を使用して、MSAL の ForceRefresh フラグを使用して ID トークン要求をスケジュールします。

MSAL でビルドできない場合、または MSAL 上に構築されたライブラリを使用できない場合は、OpenID Connect 標準を使用して現在のユーザーを認証できます。 ネイティブ アプリケーションの一部の機能は、マネージド デバイスでネイティブ アプリが実行されていることを確認するなど、MSAL を使用しないと不可能な場合があります。 MSAL で構築していない場合のガイダンスについては、「開発 するクライアント アプリケーションでの認証と承認の回復性を高める方法」を確認してください。

Microsoft Entra ID は、特定の Microsoft Graph パス (https://graph.microsoft.com/oidc/userinfo) を使用した Microsoft Entra ID OIDC 標準サポートの一部として UserInfo エンドポイントを実装します。 UserInfo エンドポイントから返される情報を追加またはカスタマイズすることはできません。 ID トークン内の情報は UserInfo エンドポイントを呼び出すことによって返される情報のスーパーセットであるため、UserInfo エンドポイントを呼び出す代わりに ID トークンを使用することをお勧めします。

ユーザーの認証

アプリケーションは Microsoft Entra ID テナントと対話してユーザーを認証します。 ユーザーを認証するために、アプリケーションはブラウザーを https://login.microsoftonline.com/{tenant}/v2.0 に誘導します。ここで {tenant} はテナントの ID またはドメインです。 ただし、ISV では Microsoft Entra ID を使用して、幅広い顧客をサポートできるマルチテナント アプリケーションを構築することをお勧めします。 マルチテナント アプリケーションの場合、アプリでは、ユーザーが認証されるまでユーザーがどのテナントであるかがわからない可能性があるため、特定のテナント エンドポイントを使用することはできません。

マルチテナント アプリを有効にするために、Microsoft Entra ID には、テナントに依存しない OIDC/OAuth 2.0 エンドポイントが 2 つ用意されています:

  • https://login.microsoftonline.com/common/v2.0 を使用すると、ユーザーは、Microsoft Entra ID テナントからの場合や、outlook.com、skype.com、xbox.com、live.com、Hotmail.com などのサイトからコンシューマー Microsoft アカウントを持っている場合にアプリを認証できます。
  • https://login.microsoftonline.com/organizations/v2.0 を使用すると、ユーザーは Microsoft Entra ID テナントからアプリを認証できます。

これらのエンドポイントを使用すると、Microsoft Entra ID テナントのすべてのユーザーがアプリケーションを認証できます。 特定のテナントのユーザーのみを許可する場合は、それらのテナントのユーザーのみがアプリにアクセスできるようにするロジックを実装してください。 通常の実装では、トークン内の iss (発行者) または tid (テナント ID) 要求に基づいて、保持するテナントの許可リストに基づいてユーザーをフィルター処理します。

Microsoft Entra ID テナントは、テナントの通常のメンバーも、テナントのゲスト ユーザーもサポートします。 既定では、テナント内のゲスト ユーザーの機能は制限されています。 たとえば、ゲスト ユーザーは、テナント内の他のユーザーの完全なプロファイルを表示できません。 ゲスト ユーザー (Business to Business (B2B) ユーザーとも呼ばれます) を使用すると、さまざまな組織が Microsoft Entra ID で保護されているツールやサービスと共同作業を行うことができます。 シナリオの例としては、組織外のユーザーを招待してテナント内の SharePoint ファイルにアクセスできるようにするなどです。 通常、B2B ユーザーは userid として自身の電子メール アドレスを使用します。 ただし、ホーム テナントの userid として同じアドレスを使用することもできます。 既定では、Microsoft Entra ID は、ユーザーが userid を入力したときにホーム テナントにユーザーをサインインさせます。

ユーザーを B2B ユーザーとしてサインインするには、アプリケーションで、ユーザーがゲストである特定のテナント エンドポイントを使用する必要があります。 アプリケーションが https://login.microsoftonline.com/organizations/v2.0 エンドポイントを使用するときに、ユーザーがアクセスするテナントを指定することはできますが、ユーザーはその機能を検出するのが難しいことがあります。

次のステップ