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

Microsoft ID プラットフォームに加えて、多くの 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コードを管理しています。 これらのライブラリの一部は、OAuth 準拠のサービスを実装するためのものです。 Office アドインの場合は、 クライアント ライブラリを探します。なぜなら、お使いの Web サーバーは OAuth 準拠サービスのクライアントだからです。

仲介者サービス

アドインは、承認を実行するために、 Auth0 などの仲介者サービスを使用できます。 仲介サービスは、人気のあるオンライン サービスへのアクセス トークンを提供したり、アドインのソーシャル サインインを簡素化したり、またはその両方を行ったりします。 アドインはクライアント側のスクリプトまたはサーバー側のコードのいずれかを使用して仲介業者サービスに接続でき、仲介業者サービスはオンライン サービスに必要なトークンを返します。

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

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

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

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

CORS とは

CORS は Cross-Origin Resource Sharing の略です。 アドインで CORS を使用する方法の詳細については、「 Office アドインでの同一生成元ポリシーの制限への対処」を参照してください。

関連項目

  • 最終更新: