前へ

次へ

Office アドインのシングル サインオン (SSO) を実装する

完了

シングル サインオン (SSO) は、アドインがユーザーを認証するための、シームレスな方法を提供します。 この方法を使用すると、アドインは、ユーザーを認証して ID 情報を取得したり、Microsoft Graph などのセキュリティで保護された別のエンドポイントから、ID 情報を取得することができます。 これを行うには、アドインは、Azure AD に登録されているサーバー側 Web API を呼び出す必要があります。

このユニットでは、認証が Office アドインで動作する仕組みと、Office アドインで SSO を使用する方法について説明します。

Office アドインにおける認証と承認

既定では、Web アプリケーションと Office アドインで匿名アクセスが許可されていますが、サインインによる認証をユーザーに要求することができます。 たとえば、ユーザーに Microsoft アカウント、Microsoft 365 Education または職場アカウント、またはその他の一般的なアカウントでログインするように要求できます。 これによりユーザーの確認がアドインで可能になることから、このタスクはユーザー認証と呼ばれています。

アドインはまた、Microsoft Graph データ (ユーザーの Microsoft 365 プロファイル、OneDrive ファイル、SharePoint データなど) や Google、Facebook、LinkedIn、SalesForce、GitHub などの外部ソース内のデータにアクセスするためのユーザーの同意を取得することもできます。 このタスクは、ユーザーではなく、承認されているアドインであるため、アドイン (またはアプリ) 承認と呼ばれます。

2 つのうちいずれかの方法を選択して、認証および承認を実行できます。

• Office シングル サインオン (SSO): ユーザーの Office へのサインインがアドインへのサインインとしても機能できるようにするシステム。 アドインでは、必要に応じて、Microsoft Graph へのアドインの承認を行うために、ユーザーの Office の資格情報も使用できます。
• Azure Active Directory (Azure AD) による Web アプリケーション認証と承認: これは、Office SSO システムが存在する前に Office アドイン (およびその他の Web アプリ) がユーザーと承認されたアプリを認証する方法であり、Office SSO ができないシナリオで引き続き使用されます。 また、SSO が利用可能でも、ユーザーに別の方法でアドインにサインインしてもらうというシナリオもあります。たとえば、ユーザーが現在 Office にログインしているものとは別の ID を使用してアドインにログインするというオプションを用意する場合などです。

Office アドインとシングル サインオン

Microsoft は 2020 年に Office アドインに SSO のサポートを追加しました。 この機能により、サード パーティ サービスへのサインインを求めるメッセージが表示される頻度を減らすことができます。

Office SSO のサポートは、カスタム アドインのコード、Office ランタイム JavaScript SDK での SSO のサポート、Azure AD を組み合わせて実装されます。 SSO をサポートするには、Office アドインに対応する Azure AD アプリケーションの登録が必要です。 このアプリ登録により、アドインがサポートするアクセス許可を定義し、ユーザーに代わって動作する Office クライアント アプリケーションを信頼します。

SSO に対するこのサポートを使用して、アドインはユーザーのプロファイル情報または Microsoft Graph からの情報を要求できます。

ユーザーは、自分で Office アドインに同意することにより、プロファイル情報の取得をアドインに許可することができます。 これによりアドインでは、Azure AD と Office によって提供されるこのプロファイル情報を、現在サインインしているユーザーの ID として使用できるようになります。

一元展開プロセスにより、管理者が組織全体の代理として同意することができるので、各ユーザーが個別に同意プロセスを実行する必要はありません。

Office アドインの SSO は、Microsoft でサポートされている職場または学校アカウント (Azure AD アカウント) と Microsoft アカウント (MSA) の両方の種類のアカウントをサポートします。

Office アドインの SSO は、Office Web クライアントと次のデスクトップ クライアントでサポートされています。

• Windows v16.0.12215.20006 (またはそれ以降)
• macOS v16.32.19102902 (またはそれ以降)

SSO 認証フローを理解する

実行時に SSO プロセスがどのように機能するのかについて説明します。

1. アドインでは、JavaScript によって新しい Office.js API が呼び出されます: getAccessToken()。 このメソッドにより、Office クライアント アプリケーションはアドインへのアクセス トークンを取得するように指示されます。
2. ユーザーがサインインしていない場合、Office クライアント アプリケーションによりユーザーにサインインを求めるポップアップ ウィンドウが開きます。
3. 現在のユーザーがアドインを初めて使用した場合は、ユーザーに同意を求められます。
4. Office クライアント アプリケーションは、Azure AD v2.0 エンドポイントから現在のユーザーのアドイン トークンを要求します。
5. Azure AD は、Office クライアント アプリケーションにアドイン トークンを送信します。
6. Office クライアント アプリケーションは、getAccessToken() 呼び出しによって返される結果オブジェクトの一部として、アドインにアドイン トークンを送信します。
7. アドインの JavaScript は、トークンを解析し、必要な情報を抽出できます。
8. オプションとして、アドインから HTTP 要求を送信して、ユーザー設定などユーザーに関する情報をさらにサーバー側に求めることができます。 または、アクセス トークン自体をサーバー側に送信して解析および検証することができます。

Office アドインで SSO を実装する

SSO をサポートする Office アドインには、次の処理が必要です。

1. Azure AD アプリケーションを登録する
2. Office アドインを Azure AD アプリケーションに関連付ける
3. クライアント側のコードを実装して、ホスティング Office クライアントからアクセス トークンを取得する

それぞれの処理について説明します。

Azure AD アプリケーションを登録する

まず、アドイン用に Azure AD アプリケーションを登録します。

Office アドインで SSO をサポートするために使用される Azure AD アプリケーションには多くの要件があります。 たとえば、マルチテナント アプリケーションであり、access_as_user のアクセス許可を公開し、アプリを呼び出すすべての Office クライアント アプリケーションを信頼している必要があります。

Microsoft によって提供される開発者ツールには、開発プロセス中に必要なすべての設定で Azure AD アプリケーションを登録するユーティリティ configure-sso が含まれています。

このモジュールの別のユニットでは、SSO を実装する Office アドインで使用する新しい Azure AD アプリケーションを作成する方法について詳しく説明します。

Office アドインを Azure AD アプリケーションに関連付ける

Azure AD アプリケーションを作成したら、Office アドインに関連付ける必要があります。 これは、アドインの manifest.xml ファイルの <WebApplicationInfo> セクションで実行します。

<WebApplicationInfo>
  <Id>056b1e8c-747d-4b45-94b1-f61ac2c19a5e</Id>
  <Resource>api://localhost:3000/056b1e8c-747d-4b45-94b1-f61ac2c19a5e</Resource>
  <Scopes>
    <Scope>User.Read</Scope>
    <Scope>profile</Scope>
    <Scope>openid</Scope>
  </Scopes>
</WebApplicationInfo>

アプリケーション用にこのセクションの 3 つの部分を更新する必要があります。

• Id: これは、登録済みの Azure AD アプリケーションのクライアント ID です
• リソース: これはアドインの URL です。これは、アドインを Azure AD に登録するときに使用された URI と同じです。 URI のドメイン部分は、アドインの manifest.xml ファイルの <Resources> セクションの URL で使用されているドメインと一致している必要があります。
• スコープ: これらは、アドインが Azure AD から必要とするアクセス許可 (スコープ) です。

重要

OpenID のアクセス許可 profile と openid はアドインで常に必要です。 アドインが Microsoft Graph などの別のサービスを呼び出す必要がある場合を除き、おそらく必要なアクセス許可はこれだけです。

また、アドインで使用されている一部のライブラリで、追加のアクセス許可が必要な場合があります。 たとえば、MSAL.NET には offline_access のアクセス許可が必要です。

クライアント側のコードを実装する

最後に、SSO を実装してサポートするために、アドインにクライアント側のコードを実装する必要があります。 Microsoft が提供するツールを使用する場合、アドイン プロジェクトには、SSO をサポートする定型コードのほとんどが含まれています。 ASP.NET アドインのための Office Developer Tools for Visual Studio 2019、または Node.js ベースのアドインの VS コードのための Yeoman Generator for Microsoft Office のいずれかを使用している場合も同様です。

API メソッド [OfficeRuntime.Auth.getAccessToken()](/javascript/api/office-runtime/officeruntime.auth) は、ホスティング Office クライアントからアクセス トークンを要求するためにアドインによって使用されます。

Office クライアントは、Azure AD で以前に登録したアプリケーションを使って Azure AD からアクセス トークンを要求します。

Azure AD によって返されるトークンは、ユーザーを識別するために使用できますが、Microsoft Graph に要求を送信するために使用できるアクセス トークンを取得する際に、ブートストラップ トークンとして使用することもできます (アドインとユーザーに特定の Microsoft Graph のアクセス許可が付与されている場合)。

アクセス トークンを使用してユーザーを識別する

アドインでユーザーを識別する必要がある場合があります。 この場合、アドインは通常、トークンを使って現在サインインしているユーザーに固有のユーザー設定やその他の情報を保存するバックエンド システムにこのトークンを提供します。

このシナリオでは、返されるトークンには、アプリケーションに役立ついくつかのプロパティが含まれます。

• name: ユーザーの表示名です。
• preferred_username: ユーザーの UPN またはメール アドレスです。
• oid: ユーザーの一意のオブジェクト ID です。これは、ユーザーまたは管理者が name と preferred_username プロパティを変更できる場合に、バック エンド システムでユーザーを識別するために使用する必要があります。
• tid: ユーザーが属している一意のテナント ID です。

独自の API でアクセス トークンを使用する

独自の API でアクセス トークンを使用する場合、Office から取得したトークンを転送するときに、受け入れられているベスト プラクティスを実装する必要があります。 これには、トークンが Azure AD によって作成されていること、トークンが想定される機関からのものであること、アドインがトークンの対象ユーザーであること、トークンが期限切れになっていないこと、スコープが access_as_user に設定されていることを確認するために、トークンを検証することが含まれます。

アクセス トークンを使用して、Microsoft Graph にアクセスする

アドインが Microsoft Graph にアクセスする必要があるシナリオでは、Office からアドインに提供されたこのトークンをコードで使用して、OAuth2 On-Behalf-Of (OBO) フローを開始できます。 トークンをこの方法で使用する場合、Microsoft Graph の呼び出しに使用できるアクセス トークンを取得するためにのみ使用されるため、「ブートストラップ トークン」と呼ばれます。

続行