Microsoft 以外の ID プロバイダーに対する承認

多くの ID プロバイダーは、Microsoft ID プラットフォームに加えて、アドインと連携できます。 これらのプロバイダーを使用すると、ユーザーは Office アドインに他のサービスのアカウントへのアクセス権を付与できます。

Web アプリケーションからオンライン サービスへのアクセスを可能にするための業界標準のフレームワークは OAuth 2.0 です。 ほとんどの場合、このフレームワークをアドインで使用するために、その動作のしくみを詳しく知る必要はありません。 開発者は、この詳細を簡略化している多数のライブラリを使用できます。

OAuth の基本的な考え方は、ユーザーやグループと同様に、アプリケーションは専用の ID とアクセス許可のセットによって、それ自体がセキュリティ プリンシパルになり得るということです。 一般的なフローでは、ユーザーはアドインで別のサービスを必要とするアクションを実行します。 アドインは、そのユーザーのアカウントに対する特定のアクセス許可セットを要求します。 その後、サービスはユーザーにアクセス許可の付与を求めます。

アクセス許可が付与されると、サービスはアドインにエンコードされた アクセス トークンを送信します。 アドインには、サービスの API への要求にトークンが含まれています。 トークンは、ユーザーが承認したアクセス許可のみを付与し、指定した時間が経過すると期限切れになります。

OAuth 2.0 フローを選択する

さまざまなシナリオに向けて、フローまたは許可の種類と呼ばれる、いくつかの OAuth パターンが設計されています。 次の 2 つのパターンが最も一般的に実装されています。

• 暗黙的フロー: アドインとオンライン サービスとの通信は、クライアント側の JavaScript で実装されます。 このフローは、シングル ページ アプリケーション (SPA) で一般的に使用されます。
• 認証コード フロー:アドインの Web アプリケーションとオンライン サービスとの通信は、サーバー間で行われます。 そのため、これはサーバー側のコードで実装されます。

OAuth フローの目的は、アプリケーションの ID と承認の安全を確保することです。 承認コード フローでは、ID プロバイダーは機密のままにする必要がある クライアント シークレット を発行します。 SPA などのサーバー側バックエンドを持たないアプリケーションでは、そのシークレットを安全に格納できないため、SPA の暗黙的なフローをお勧めします。

暗黙的フローと認証コード フローのメリットとデメリットについて理解しておく必要があります。 これら 2 つのフローの詳細については、「認証コード フロー」と「暗黙的フロー」を参照してください。

Office アドインで暗黙的なフローを使用する

ID プロバイダーのドキュメントを確認して、暗黙的なフローがサポートされていることを確認します。

暗黙的フローをサポートするライブラリの詳細については、後述の「ライブラリ」セクションを参照してください。

Office アドインで承認コード フローを使用する

各種の言語とフレームワークで認証コード フローを実装するために利用できるライブラリは多数あります。 いくつかの例については、この記事の後半の 「ライブラリ 」セクションを参照してください。

ライブラリ

各種の言語とプラットフォームで暗黙的フローと認証コード フローを実装するために利用できるライブラリが多数あります。 ライブラリには汎用のものや、特定のオンライン サービス向けのものがあります。

• Facebook:Facebook for Developers で "library" または "sdk" を検索します。
• 一般的な OAuth 2.0: IETF OAuth ワーキング グループは、12 を超える言語のライブラリ リンクのページである OAuth Code を保持しています。 これらのライブラリの一部は、OAuth 準拠サービスを実装するためのものです。 Office アドインの場合は、Web サーバーが OAuth 準拠サービスのクライアントであるため、 クライアント ライブラリを 探します。

仲介者サービス

アドインは、 OAuth.io や Auth0 などの仲介者サービスを使用して承認を実行できます。 仲介サービスは、一般的なオンライン サービスのアクセス トークンを提供したり、アドインのソーシャル サインインを簡略化したり、その両方を提供したりする場合があります。 アドインは、クライアント側スクリプトまたはサーバー側コードを使用して中間者サービスに接続でき、仲介者サービスはオンライン サービスに必要なトークンを返します。

アドインの認証と承認のための UI では、Office ダイアログ API を使用してサインイン ページを開くようお勧めします。 詳細については、「 Office ダイアログ API を使用した認証と承認」を参照してください。

このように Office ダイアログを開くと、アドインの作業ウィンドウや関数ファイルなど、親ページとは別のブラウザーと JavaScript エンジン インスタンスでダイアログが実行されます。 トークンと、文字列に変換できるその他の情報は、 messageParentを使用して親に返されます。 そうすることで、親ページはトークンを使用してリソースへの権限のある呼び出しを実行できます。

このアーキテクチャのため、仲介サービスの API を使用する場合は注意してください。 一部のサービスでは、コードがトークンを取得し、後でリソースを呼び出す際にそのトークンを使用するコンテキスト オブジェクトを作成する API セットを提供します。 一部のサービスでは、最初の呼び出しを行い、コンテキスト オブジェクトを作成する 1 つの API メソッドも使用します。 このようなオブジェクトは完全に文字列化できないため、Office ダイアログから親ページに渡すことはできません。

通常、Middleman サービスでは、REST API など、より低い抽象化レベルで 2 つ目の API セットも提供されます。 この下位レベルの API セットには、通常、サービスからトークンを取得する 1 つの API と、リソースへのアクセスを要求するときにトークンをサービスに返す他の API が含まれます。 Office ダイアログでトークンを取得し、 messageParentを使用して親ページに渡すことができるように、この下位レベルの API セットを使用します。

CORS とは

CORS は、 クロスオリジン リソース共有を表します。 アドインでの CORS の使用の詳細については、「Office アドインでの 同じ配信元ポリシーの制限に対処する」を参照してください。

関連項目

• Office アドインにおける認証と承認の概要