Outlook アドインの認証オプション
Outlook アドインは、アドインをホストするサーバー、内部ネットワーク、クラウド内の別の場所などに関わらず、インターネット上のあらゆる場所から情報にアクセスできます。 その情報が保護されている場合、アドインにはユーザーを認証する方法が必要になります。 Outlook アドインは、特定のシナリオに応じて、さまざまな認証メソッドを提供します。
OBO フローを使用したシングル サインオン アクセス トークン
シングル サインオン (SSO) アクセス トークンは、Outlook アドインが Microsoft Graph APIを呼び出すためにアクセス トークンを認証および取得するためのシームレスな方法を提供します。 ユーザーが資格情報を入力する必要がないため、この機能は摩擦を低減します。 中間層サーバーまたは入れ子になったアプリ認証で、代理フローを使用できます (次のセクションで説明します)。
注:
現在、OBO フローを使用した SSO は、Word、Excel、Outlook、およびPowerPointでサポートされています。 サポートの詳細については、「 IdentityAPI 要件セット」を参照してください。 Outlook アドインを使用している場合は、Microsoft 365 テナントの先進認証を有効にしてください。 これを行う方法については、「Exchange Onlineで Outlook の先進認証を有効または無効にする」を参照してください。
アドインが次の場合は、SSO アクセス トークンの使用を検討してください。
- 主に Microsoft 365 ユーザーが使用する
- 次のものにアクセスする必要がある。
- Microsoft Graph の一部として公開されている Microsoft サービス
- ユーザーが制御する Microsoft 以外のサービス
SSO 認証方法は、Azure Active Directory が提供する OAuth2 On-Behalf-Of フローを使用します。 アドインのみのマニフェストが使用されている場合は、 アドインをアプリケーション登録ポータルに登録 し、アドイン マニフェストで必要な Microsoft Graph スコープを指定する必要があります。 アドインが Microsoft 365 の統合マニフェストを使用している場合は、マニフェスト構成がいくつかありますが、Microsoft Graph スコープは指定されていません。 代わりに、Microsoft Graph にトークンをフェッチするための呼び出しで、実行時に必要なスコープが指定されます。
この方法を使用すると、アドインはサーバーのバックエンド API にスコープされたアクセス トークンを取得できます。 アドインはこれを Authorization ヘッダーのベアラー トークンとして使用して、API へのコールバックを認証します。 その時点で、サーバーでは次の操作を実行できます。
- On-Behalf-Of フローを完了して、Microsoft Graph API にスコープ設定されたアクセス トークンを取得する
- トークン内の ID 情報を使用して、独自のバックエンド サービスに対するユーザーの識別と認証を確立する
より詳しい概要については、SSO 認証方式の概要全文を参照してください。
Outlook アドインでの SSO トークンの使用の詳細については、「Outlook アドインでシングルサインオン トークンを使用してユーザーを認証する」を参照してください。
SSO トークンを使用するアドインのサンプルについては、「Outlook アドイン SSO」を参照してください。
入れ子になったアプリ認証を使用したシングル サインオン アクセス トークン
入れ子になったアプリ認証 (NAA) を使用すると、ネイティブ Office アプリケーションのコンテキストで実行されている Office アドインのシングル Sign-On (SSO) が有効になります。 NAA は、Office.js と getAccessToken()で使用される代理フローと比較して、アプリ アーキテクチャの柔軟性が向上し、クライアント主導の豊富なアプリケーションを作成できます。 NAA を使用すると、アドイン コードの SSO の処理が簡単になります。 NAA を使用すると、中間層サーバーを必要とせずに、アドイン クライアント コードから SPA として Microsoft Graph 呼び出しを行うことができます。 MSAL.js ライブラリによって NAA が提供されるため、Office.js API を使用する必要はありません。
Outlook アドインで NAA を使用できるようにするには、「 入れ子になったアプリ認証を使用して Office アドインの SSO を有効にする (プレビュー)」を参照してください。 NAA は、すべての Office アドインで同じように動作します。
Exchange のユーザー ID トークン
重要
従来の Exchange トークンは非推奨です。 2025 年 2 月から、Exchange Online テナントの従来の Exchange ユーザー ID とコールバック トークンの無効化を開始します。 タイムラインと詳細については、FAQ ページを参照してください。 これは、現在の脅威の状況に対応するために必要なツールを組織に提供する 、Microsoft の Secure Future Initiative の一部です。 Exchange ユーザー ID トークンは、引き続き Exchange オンプレミスで機能します。 入れ子になったアプリ認証は、今後のトークンに推奨される方法です。
Exchange のユーザー ID トークンは、アドインがユーザーの ID を確立する方法を提供します。 ユーザーの ID を確認することで、バックエンド システムにワンタイム認証を実行し、将来の要求に対する認証としてユーザー ID トークンを使用することができます。 次の場合、Exchange のユーザー ID トークンを使用します。
- アドインが主に Exchange のオンプレミス ユーザーによって使用される場合。
- アドインが、ユーザーが制御する Microsoft 以外のサービスにアクセスする必要がある場合。
- SSO をサポートしていないバージョンの Office でアドインが実行されている場合の代替認証として。
アドインでは、getUserIdentityTokenAsync を呼び出して Exchange のユーザー ID トークンを取得できます。 それらのトークンの使用の詳細については、「Exchange の ID トークンを使用してユーザーを認証する」を参照してください。
OAuth2 フローで取得されたアクセス トークン
アドインは、認証のために OAuth2 をサポートする Microsoft やその他のサービスにアクセスすることもできます。 アドインが次の場合は、OAuth2 トークンの使用を検討してください。
- 制御外のサービスにアクセスする必要があります。
このメソッドを使用すると、アドインは displayDialogAsync メソッドを使用して OAuth2 フローを初期化することで、ユーザーにサービスへのサインインを求めます。
コールバック トークン
重要
従来の Exchange トークンは非推奨です。 2025 年 2 月から、Exchange Online テナントの従来の Exchange ユーザー ID とコールバック トークンの無効化を開始します。 タイムラインと詳細については、FAQ ページを参照してください。 これは、現在の脅威の状況に対応するために必要なツールを組織に提供する 、Microsoft の Secure Future Initiative の一部です。 Exchange ユーザー ID トークンは、引き続き Exchange オンプレミスで機能します。 入れ子になったアプリ認証は、今後のトークンに推奨される方法です。
コールバック トークンは、Exchange Web サービス (EWS) または Outlook REST API を使用した、サーバーのバックエンドからユーザーのメールボックスへのアクセスを提供します。 アドインが次の場合は、コールバック トークンの使用を検討してください。
- サーバーのバックエンドからユーザーのメールボックスにアクセスする必要がある。
アドインは、getCallbackTokenAsync メソッドの 1 つを使用して、コールバック トークンを取得します。 アクセスのレベルは、アドイン マニフェストで指定されたアクセス許可によって制御されます。
関連項目
Office Add-ins