Microsoft Graph と Microsoft Identity
このユニットでは、Microsoft Entra ID に焦点を当てます。 Microsoft Entra 管理センターを使用してアプリケーションを登録し、アプリの資格情報を設定し、アプリケーションの種類を構成する方法について説明します。 次に、既存の ASP.NET MVC アプリケーションを変更して、Microsoft Entra ID で動作するようにする方法について説明します。
Microsoft Entra エンドポイントのバージョン
Microsoft Entra ID には、2 つの認証エンドポイントとトークン エンドポイントが含まれています。 v2 エンドポイントは、Microsoft Graph を使用するすべてのアプリケーションで推奨されるエンドポイントです。 その理由を理解するには、v1 エンドポイントと比較した利点の理解が役立ちます。
Azure AD v1 エンドポイント
Azure AD v1 エンドポイントでは、Microsoft Entra 認証のみがサポートされます。 Microsoft アカウントなど、他の認証スタイルをサポートしていません。 つまり、ユーザーが個人用アカウントまたはコンシューマー アカウント (Microsoft アカウントともいう) でログイン中、OneDrive コンシューマー アカウントまたは Outlook.com にアクセスする場合、アプリケーションの開発者はこうした種類のアカウントを処理する特別な認証コードを記述する必要があります。 これは、学校アカウント (Microsoft Entra アカウント) での作業のみをサポートしているため、v1 エンドポイントの欠点です。
v1 エンドポイントのもう 1 つの課題は、静的な同意のみをサポートしていることです。 静的な同意は、アプリケーションが必要とする単一のアクセス許可が事前に定義されている必要があることを意味します。また、ユーザーは初回ログイン時に、すべてのアクセス許可についてアプリケーションに同意を与える必要があります。
Azure AD v2 エンドポイント
Azure AD v2 エンドポイントは、v1 エンドポイントのこれら 2 つの欠点を解決します。 最初に、Microsoft アカウントと職場と学校 (Microsoft Entra ID) アカウントのサインイン エクスペリエンスを統合する統合認証を実装します。 開発者は、ユーザーを特定のサインイン操作に誘導する必要はありません。すべてのユーザーは、統合されたサインイン機能に送られ、Microsoft ID を利用してアカウントの種類が決定されます。 これにより開発者は、Microsoft Graph を使用して連絡先の閲覧、メール、検索などを行うために、同じコードを作成することもできます。
v2 エンドポイントのもう 1 つの利点は動的な同意です。 動的な同意は、ユーザーがサインインしたときに、アプリケーションがその時点で必要なアクセス許可を要求するという点で、静的な同意とは異なります。 Microsoft ID によって、以前にユーザーが要求されたアクセス許可に同意したかどうかが判別されます。 同意していない場合、ユーザーには新しいアクセス許可の要求についてのみ、同意ダイアログが表示されます。
v2 エンドポイントは、サインイン時に要求された場合、ID トークンを含む OpenID Connect 標準もサポートします。 これは認証プロトコルの拡張機能で、ユーザーが正常にサインインすると、アプリケーションのサインイン要求に返されます。 ID トークンには、ユーザーのメール アドレスと名前など、現在のユーザーに関する情報が含まれます。 v1 エンドポイントは OpenID Connect を部分的にサポートしていましたが、v2 エンドポイントは OpenID Connect の仕様により適合しています。
Microsoft Entra アプリケーションを Microsoft Entra 管理センターに登録する
他のアプリを使用するためのアクセス許可を付与する必要があるすべてのアプリは、Microsoft Entra ID に登録する必要があります。 アプリの登録は、 の Microsoft Entra 管理センターを https://aad.portal.azure.com通じて行われます。 Microsoft Entra 管理センターでは、ユーザーとアプリを管理するために有料の Azure サブスクリプションを持っている必要はありません。 ユーザー、グループ、アプリの読み取りと編集、またはディレクトリの管理を行うのに、ユーザーにはアクセス権が必要です。 管理センターでは、以前は開発者および管理者向けに用意されていた、さまざまなアプリ管理ポータルが 1 つのサイトに統合されています。 このポータルから、v1 および v2 の Microsoft ID エンドポイントを使用するために作成されたアプリを管理できます。
カスタム アプリケーションは、Microsoft が提供する認証ライブラリのいずれかを使用できます。 2 つのライブラリのそれぞれは、Microsoft ID でサポートされている各プラットフォームおよび言語について、SDK を介して利用できます。
v2 エンドポイントを使用するアプリは、Microsoft Authentication Library (MSAL) SDK を使用できます。 MSAL は、v1 エンドポイントでのみ機能する以前のライブラリ、Azure AD Authentication Library (ADAL) を置き換えました。
Microsoft Graph に統合されているアプリの場合、開発者は Microsoft ID v2 エンドポイントを使用することをお勧めします。そのため、MSAL ライブラリを使用します。
Web アプリケーションと Microsoft ID
このモジュールでは、ASP.NET MVC Web アプリケーションを使用して、Microsoft Graph でユーザーの予定表のイベントを要求および表示する方法を示します。 このシナリオでは、OAuth 2.0 承認コード許可フローを実装して、Microsoft Entra ID からアクセス トークンを取得します。 アクセス トークンは、ユーザーとアプリケーションを認証するために Microsoft Graph に送信される各要求に含まれます。
Web アプリは、アクセス トークンを要求するときに、Microsoft Entra ID で認証する必要があります。 アクセス トークン要求の一部として、アプリには、そのアプリ ID (クライアント ID とも呼ばれる) とシークレットを含める必要があります。 シークレットは、x509 証明書または文字列を指定できます。
また Web アプリでは、Microsoft ID が成功したログインにユーザーをリダイレクトする Web アプリのアドレスを、Microsoft ID に対して指定する必要があります。 このアドレスは、リダイレクト URI と呼ばれます。 ログインに含まれるリダイレクト URI は、アプリ登録のアドレスと一致している必要があります。
Microsoft Entra 管理センターのアプリ登録プロセスの最後の手順は、アプリに必要なアクセス許可を指定することです。 これには、代理アクセス許可またはアプリケーションのアクセス許可のいずれかを含めることができます。 代理アクセス許可は、ユーザーがアプリにサインインしたときに代理として動作するようにアプリに付与するものです。 アプリケーションのアクセス許可は、対話型ユーザー セッションが存在しない場合に、サービス アプリまたはデーモン アプリがあるかのようにアプリで使用されます。 Microsoft Entra 管理センター内で定義されているアクセス許可は静的なアクセス許可であり、動的なアクセス許可ではありません。 以前に説明した一般的な同意の一部として、ユーザーが初めてアプリケーションにサインインするときに、これらのアクセス許可が与えられます。
概要
このユニットでは、Microsoft Entra ID とアプリの登録に焦点を当てています。 Microsoft Entra 管理センターを使用してアプリケーションを登録し、アプリの資格情報を設定し、アプリケーションの種類を構成する方法について説明しました。 また、既存の ASP.NET MVC アプリケーションを変更して、Microsoft Entra ID で動作するようにする方法についても説明しました。