ASP.NET MVC Web アプリケーションにおける Microsoft Graph の概要
このユニットでは、Microsoft Graph が大規模な Microsoft 365 プラットフォームに適合する方法について説明します。 また、ASP.NET MVC アプリケーションの Microsoft Graph を使用して、現在サインインしているユーザーの予定表からイベントを表示する方法について説明します。
Microsoft 365 プラットフォーム
Microsoft 365 の開発者構想はユーザーのエクスペリエンスとそのデータに焦点を当て、開発者として世界中の 12 億を超える Office ユーザー向けにアプリケーションのユーザー エクスペリエンスを提供できます。 これは、お客様のアプリケーションを知ってもらい、ユーザーのデータがアプリケーションのインテリジェンスにつながる大きなチャンスになります。
現在、毎月 8 億 5,000 万件を超えるイベントが作成され、ユーザーに付加価値を与えるサービスに合計 400 ペタバイト超のデータが格納されています。
Microsoft Graph は、Microsoft クラウドで確認できる自分のデータに対する入口です。
Microsoft Graph - Microsoft のクラウドにあるデータへの入口
Microsoft のクラウドには、複数のサービスとデータの種類が含まれており、Office 365 から活用することができます。これはすべて、Microsoft 365 プラットフォームの一部とみなされます。
開発者は、サインインしているユーザーのメール、予定表、連絡先、タスクをカスタム アプリに統合できます。 SharePoint サイトのコンテンツや OneDrive のファイル一覧、Microsoft Teams のチャネルとコンテンツ、Azure Active Directory (Azure AD) のユーザーを操作できます。
開発者がカスタム アプリを活用できる、各種のサービスが多数存在します。 これらのサービスの多くは、開発者が対話的に操作できる独自の API を備えています。
ただし、このような個別のサービスを個別のエンドポイントと共に使用するのが難しい場合があります。 各 API は固有のアクセス許可モデルを持っている場合があり、これはアクセス制御の構成が個別であることを意味します。 サービスごとにエンドポイントが異なるため、カスタム アプリケーションは Azure AD からそれぞれのアクセス トークンを取得する必要があります。
Microsoft Graph による Microsoft 365 データへのアクセスの簡略化
Microsoft Graph の利点の 1 つは、他のすべてのサービスに対してプロキシ エンドポイントとして機能するということです。 Microsoft Graph には、Office 365、Windows 10 Enterprise Mobility + Security (EMS) などの機能が含まれています。これらの異なるサービスはすべて 1 つの統合エンドポイント graph.microsoft.com に集約されます。
Microsoft Graph を使用する利点は、開発者が単一のエンドポイント、リソースを持つことができることです。つまり、異なるサービスを認証するのに必要なのはただ 1 つのアクセス トークンです。 それでも、すべてのセキュリティを個別の方法で保護できるように、各サービスは個別のアクセス許可を備えています。 単一のエンドポイントにより、開発者はより簡単にアプリケーションを構築できます。
また、Microsoft Graph では、エンティティおよびエンティティ間のリレーションシップを簡単に移動できます。 ファイル用の OneDrive、連絡先と予定表用の Outlook など、さまざまな Microsoft 365 サービスが多数用意されていますが、これらの異なるエンティティは互いに関連付けられています。 こうしたリレーションシップは Microsoft Graph に存在するので、基になっている別々のエンドポイントをまたがる場合でも、エンティティ間を簡単に移動できます。
単一の認証フロー
Microsoft 365 にはこのようにさまざまなサービスがあり、サービスごとに別のアクセス トークンを取得する必要があったため、Microsoft Graph によりトークンの取得が簡単になります。
Microsoft Graph では、異なるサービスがプロキシされるので、サービスごとに個別のトークンを入手する必要がありません。 Microsoft Graph は、1 つのエンドポイント経由で、各サービスのエンドポイントへの呼び出しをプロキシします。
このため、従来の探索サービスは必要ありません。 Microsoft Graph が登場するまでは、開発者は探索サービスを使用し、OneDrive や Outlook などの各サービスのユーザー固有エンドポイントについて、Microsoft 365 のさまざまなエンドポイントで確認する必要がありました。
注意が必要な点は、これはプロキシであるため、Microsoft Graph に表示される前に、新しい機能と特徴がダウンストリーム エンドポイントに表示される場合があることです。 これは、Microsoft Graph はプロキシであり、プロキシを行ういずれかのサービスでダウンストリームに存在しない機能を公開することはできないためです。
認証および同意フレームワーク
Office 365 には、Microsoft Graph でも使用される単一の認証フローがあります。 ユーザーは、オープン標準である Open ID Connect と呼ばれるテクノロジを使用してサインインします。 Open ID Connect は、ログインしている個々のユーザーに関する詳細情報を含む OAuth 2.0 認証プロトコルのラッパーです。
Azure AD は認証のすべてに使用されます。 Microsoft Graph では、Azure AD の認証モデルに基づいて構築された、Azure および Office 365 と同じ認証モデルを使用します。 これらの両方のサービスで Azure AD が信頼され、この共有信頼があることで、認証を利用し、同じ認証フローでこれらの異なるサービスの両方を利用できます。
この認証フローは、多要素認証 (MFA ともいう) およびフェデレーション ユーザー サインオンもサポートしています。 クライアントに 100% 存在するモバイル デバイス、Web サイト、シングル ページ アプリケーション、またはユーザーの関与のないヘッドレス アプリケーション (デーモン アプリまたはサービスともいう) など、あらゆる種類のデバイス アプリケーションをサポートしています。
Azure AD に関連する概念の 1 つに共通同意フレームワークがあります。 同意についてより良く理解するために、アクセス許可を三角形の概念の中で考えてください。
三角形の 1 点はアクセス許可、別の 1 点はユーザーまたはアプリケーション、最後の 1 点はやりとりするリソースです。 ユーザーはやりとりするリソースへのアクセス許可を持っている必要があります。
ユーザーが初めて Azure AD にサインすると、Microsoft Graph で認証するためのアクセス トークンを取得するために、Azure AD はまず、このユーザーがこのアプリケーションに Microsoft Graph へのアクセスを許可しているかどうかを確認します。 特に、アプリにこれらのアクセス許可に対するアクセス権が付与されているかどうかを確認します。
これは次のように機能します。ユーザーがこのプロセスを完了していない場合、共通同意フレームワークが起動し、ユーザーのサインイン後、前の画像に示されるダイアログが表示されます。
ユーザーがエンドポイントへのアクセス許可をアプリケーションに与えていない場合、同意フレームワークはその操作を要求します。 このプロセスは、委任された同意と呼ばれます。 ユーザーがダイアログの要求を承認すると、ユーザーに代わって、特定のアプリケーションにアプリへの特定のアクセス許可が付与されます。
認証オプション
Microsoft Graph は認証に関して 2 つのオプションをサポートしています。 オプションの 1 つは、Azure AD のみ、つまり職場または学校アカウントです。 もう 1 つのオプションは、Azure AD および Microsoft アカウントの統合認証です。 この場合、Microsoft Graph のまったく同じコード、同じエンドポイント、同じ SDK を使用して、OneDrive コンシューマーまたは OneDrive for Business のどちらかでファイルを取得できます。 Outlook.com または Office 365 の予定表、連絡先、メールについても同様です。
これについて便利な点は、取得するデータがサインインするユーザーのログインにすべて依存していることです。 したがって、コンシューマー アカウントまたはビジネス アカウントのデータを取得するために、特別なコードを作成したり、さまざまな API またはエンドポイントを使用したりする必要はありません。
Microsoft Accounts & Azure AD
前述したとおり、Microsoft Graph は、Microsoft アカウントと Azure AD アカウント (職場および学校のアカウントともいう) の両方をサポートしています。 サインインに関して、Microsoft Graph の API または SDK に固有のものはありません。コードは同じで、サインインによって、Microsoft Graph がアクセスするサービスが決まります。 ユーザーが Microsoft アカウントでサインインした場合、ファイル エンドポイントは OneDrive コンシューマーにマッピングされ、職場および学校のサインインは OneDrive for Business にマッピングされます。 これはほんの一例です。
アプリでサポートされているアカウントの種類またはアプリが両方をサポートしているかどうかを判断するには、Azure AD 管理センターに登録されている関連の Azure AD アプリで特定の設定を行います。
Microsoft Graph と ASP.NET MVC Web アプリケーション
開発者は、さまざまな種類のアプリケーションで Microsoft Graph を使用できます。 このモジュールでは、Microsoft Graph を呼び出すためのサポートを追加し、ASP.NET MVC Web アプリケーションに、現在サインインしているユーザーの予定表からイベントを表示します。
最初の手順では、Visual Studio プロジェクト作成ウィザードを使用して、ASP.NET MVC Web アプリケーションを作成します。 次に、.NET および OWIN ミドルウェアの Microsoft Authentication Library (MSAL) を追加し、構成します。 これにより、Web アプリケーションでは、ユーザーがサインインして、Microsoft Graph に要求を送信するときに使用するアクセス トークンを、Azure AD から取得できるようになります。 この 2 つのライブラリでは、プロジェクトにいくつかのライブラリをインストールする必要があります。 ライブラリは NuGet パッケージとして使用できます。
次に、アプリケーションが SSL を使用していることを確認します。 アプリケーションを Azure AD に登録する場合は、サインイン成功後にユーザーに送信されるリダイレクト URL を指定する必要があります。 HTTPS を使用して Azure AD アプリケーションを操作するには、この URL を構成する必要があります。
概要
このユニットでは、Microsoft Graph が大規模な Microsoft 365 プラットフォームに適合する方法について説明しました。 また、ASP.NET MVC アプリケーションの Microsoft Graph を使用して、現在サインインしているユーザーの予定表からイベントを表示する方法について説明しました。