SharePoint Embedded アプリケーションを作成する

  • 6 分

開発者は、SharePoint Embedded を使用して、SharePoint の強力なファイルおよびドキュメント管理機能を利用するアプリケーションを作成できます。 これらの種類のアプリケーションには、2 つの異なるコンポーネントがあります。

  • 1 つのコンポーネントは、Microsoft Graph API を使用して SharePoint Embedded に対して CRUD 操作を実行する役割を担います。
  • もう 1 つのコンポーネントは、ユーザーが SharePoint Embedded に格納されているドキュメントを使用して格納するためのインターフェイスを実装します。

SharePoint Embedded の概要

SharePoint Embedded を使用すると、開発者はファイルに焦点を当てたアプリケーションを迅速に作成し、ドキュメント化できます。 SharePoint Embedded は SharePoint を利用します。 開発者は、SharePoint が独自のカスタム アプリケーションで提供する必要があるのと同じ強力なファイルおよびドキュメント機能を統合できます。

SharePoint Embedded を確認するもう 1 つの方法は、カスタム アプリケーションがすべてのドキュメント ストレージとコラボレーション機能に SharePoint を使用することです。 これは、SharePoint Embedded を SharePoint のドキュメント ストレージ システムの "ヘッドレス API" として効果的に使用します。

アプリ ドキュメントは Microsoft 365 テナントに留まる

コンシューマーが SharePoint Embedded アプリケーションを Microsoft 365 テナントにインストールまたは登録すると、SharePoint Embedded によって別の SharePoint パーティションが作成されます。 このストレージ パーティションにはユーザー インターフェイスはありませんが、代わりに、パーティション内のドキュメントには API 経由でのみアクセスできます。 つまり、すべてのドキュメントに ISV または開発者のアプリケーションからアクセスできますが、ドキュメントはコンシューマーの Microsoft 365 テナントにのみ存在します。

コンシューマー Microsoft 365 設定がアプリ ドキュメントに適用される

SharePoint Embedded アプリによって作成された SharePoint パーティションに格納されているすべてのドキュメントは、コンシューマーの Microsoft 365 テナント内にあるため、コンシューマーの Microsoft 365 テナント設定の対象となります。

さまざまな種類のアプリのアクセス許可と On-Behalf-Of フローについて

Microsoft Graph や SharePoint Online などの REST API にアクセスするためのアプリケーションを作成する場合、さまざまなタスクでさまざまな種類のアクセスが必要になります。 これに対処するために、OAuth v2.0 は、Microsoft Graph や SharePoint Online など、API アクセスに使用される承認のオープン標準です。 ユーザーの代わりに、保護されたリソースへの委任されたアクセスをアプリケーションに提供します。 これには、 App+User (委任済みとも呼ばれます) とアプリ専用 (またはアプリケーション) の 2 種類 の アクセス許可が含まれます。

  • App+User (または委任された) アクセス許可: このモデルは、2 者のアクセス許可モデルに関するモデルです。 アプリケーションは、サインインしているユーザーの代わりにタスクを実行し、API を呼び出しています。 アプリケーションは、サインインしたユーザーから委任されたアクセス許可を取得し、特定のデータにアクセスできない、特定のアクションを実行できないなどの制限など、ユーザーが持つ特権を継承します。 これらは、ユーザーがセッション中にアプリに代わって実行することを許可したタスクを反映しています。

    たとえば、アプリにはユーザーの代わりにメールを送信するアクセス許可が与えられる場合がありますが、ユーザーにメールを送信するアクセス許可がない場合、アプリはメールを送信することもできません。

    この種類のアクセス許可は、サインインしているユーザーがアプリを操作する場合によく使用されます。アプリケーション シナリオでは、操作がユーザーに代わって行われ、アクセス許可は同意を付与するユーザーによって異なります。

  • アプリ専用 (またはアプリケーション) のアクセス許可: アプリのみのアクセス許可は、逆に、アプリがユーザーとは別にリソースにアクセスする必要がある場合に使用されます。 アプリケーションは、ユーザーのアクセス許可に関係なく、自身に直接付与されたアクセス許可を取得します。 これにより、アプリケーションは独自の ID と特権を使用して API サービスにアクセスできます。 これは、ユーザー セッションから独立して実行されるバックグラウンド サービスまたはデーモンに最適です。

たとえば、ドキュメント ライブラリ内のすべてのファイルにアクセスする必要があるアプリケーションがある場合、ユーザーと共有されていないファイルでも、アプリのみのアクセス許可が適切な選択になります。

多くの場合、より高い特権が付与されるため、アプリケーションのアクセス許可は管理者のみが同意できます。

これら 2 つのオプションに加えて、3 つ目の OAuth 2.0 フロー である On-Behalf-Of ( OBO フローとも呼ばれます) は、アプリケーションがユーザーに代わってタスクを実行する必要がある場合に使用できます。 OBO フロー全体の動作を次に示します。

  1. クライアント アプリケーションは承認サーバー (Microsoft Entra ID など) に対して認証を行い、API (プロジェクトの API サーバーなど) のアクセス トークンを要求します。
  2. ユーザーはサインインし、アプリケーションが自分の代わりに動作できるようにします。
  3. クライアント アプリケーションは、ユーザーのセッションを表すアクセス トークンと更新トークンを受け取ります。
  4. クライアント アプリケーションは、ユーザーの代わりに SharePoint Online などの別のサービスを呼び出す必要がある場合、HTTP ヘッダーで前に取得したアクセス トークンを Authorization 送信します。
  5. サーバー側 API は、アクセス トークンを検証し、要求を処理します。 ユーザーの代わりに別のサービス (SharePoint Online など) を呼び出す必要がある場合は、この既に取得したトークンを提示することで、Microsoft Entra ID からトークンをフェッチします。
  6. Microsoft Entra ID は、プロジェクトの API サーバーが SharePoint Online の呼び出しに使用できる SharePoint Online の "新しい" アクセス トークンを発行します。

Microsoft Graph または SharePoint Online を扱う実用的なシナリオでは、ユーザーがアプリで予定表にアクセスする必要がある場合、個々の操作ごとにアプリケーションをサインインさせるのは理想的ではありません。 代わりに、OBO フローでは、ユーザーは 1 回だけ認証する必要があり、アプリケーションは承認されたすべての操作を自分の代わりに実行します。

したがって、OBO フローは、一連の呼び出しが行われるたびにアクセス許可が検証されるようにすることで、ユーザー エクスペリエンスを簡素化し、システムのセキュリティを強化します。

概要

このセクションでは、SharePoint Embedded Container で CRUD 操作を実行する Web アプリケーションを作成するための最初の手順を完了しました。