入れ子になったアプリ認証と Outlook レガシ トークンの非推奨に関する FAQ

Exchange ユーザー ID トークン と コールバック トークン は非推奨となり、2025 年 2 月からオフになります。 従来の Exchange トークンを使用する Outlook アドインを、入れ子になったアプリ認証に移動することをお勧めします。

一般的な FAQ

入れ子になったアプリ認証 (NAA) とは

入れ子になったアプリ認証を使用すると、Outlook などのサポートされている Microsoft アプリケーション内に入れ子になったアプリケーションのシングル サインオン (SSO) が有効になります。 NAA は、既存の完全信頼認証モデルや代理フローと比較して、セキュリティが向上し、アプリ アーキテクチャの柔軟性が向上し、クライアント主導の豊富なアプリケーションを作成できます。 詳細については、「 入れ子になったアプリ認証を使用して Office アドインで SSO を有効にする」を参照してください。

従来の Exchange オンライン トークンをシャットダウンするためのタイムラインは何ですか?

Microsoft は、2025 年 2 月に従来の Exchange オンライン トークンのオフを開始します。 現在から 2025 年 2 月まで、既存のテナントと新しいテナントは影響を受けません。 管理者がテナントとアドインの Exchange トークンを再び有効にするツールを提供します(これらのアドインがまだ NAA に移行されていない場合)。 詳細については、「 レガシ トークンを再び有効にできますか? 」を参照してください。

チャネルで NAA が一般公開されるのはいつですか?

NAA の一般公開 (GA) の日付は、使用しているチャネルによって異なります。

COM アドインは、レガシ Exchange Online トークンの廃止の影響を受けるのですか?

従来のExchange Online トークンの廃止によって COM アドインが影響を受ける可能性は非常に低いです。 Outlook Web アドインは主に、Exchange トークンに依存 Office.js API を使用できるため、影響を受ける可能性があります。 詳細については、「 Outlook アドインがレガシ トークンに依存しているかどうかを確認する方法」を参照してください。 Exchange トークンは、Exchange Web Services (EWS) または Outlook REST API にアクセスするために使用されます。どちらも非推奨です。 COM アドインが影響を受ける可能性がある場合は、Exchange トークンがオフになっているテナントで使用してテストできます。 詳細については、「レガシ Exchange Online トークンのオンとオフを切り替える」を参照してください。

Microsoft 365 管理者の質問

レガシ トークンExchange Online再度有効にできますか?

はい。任意のテナントでレガシ トークンのオンとオフを切り替えるために使用できる PowerShell コマンドがあります。 レガシ トークンのオンとオフを切り替える方法の詳細については、「レガシ Exchange Online トークンのオンとオフを切り替える」を参照してください。 コマンドを使用してレガシ Exchange Online トークンを有効にした場合、2025 年 2 月には無効になりません。 これらは、2025 年 6 月まで、またはツールを使用してオフにするまでオンのままです。

2025 年 6 月には、従来のトークンはオフになり、Microsoft によって特定の例外が与えられなければ、元に戻すことはできません。 2025 年 10 月には、レガシ トークンを有効にすることはできず、すべてのテナントで無効になります。 ツールが利用可能になったら、この FAQ を追加情報で更新します。

管理者の同意フローのしくみ

独立したソフトウェア ベンダー (ISV) は、Entra ID トークンと Microsoft Graph スコープを使用するようにアドインを更新しています。 アドインがアクセス トークンを要求する場合は、管理者またはユーザーの同意が必要です。 管理者が同意した場合、テナント上のすべてのユーザーは、アドインで必要なスコープにアドインを使用できます。 それ以外の場合、ユーザーの同意が有効になっている場合は、各エンド ユーザーに同意を求められます。 管理者の同意を完了すると、ユーザーにプロンプトが表示されないため、エクスペリエンスが向上します。

同意のオプションの 1 つは、ISV が管理者の同意 URI を提供することです。

1. アドイン開発者は、管理者の同意 URI を提供します。 これが提供するドキュメントに記載されていない場合は、詳細についてはお問い合わせください。
2. 管理者は、管理者の同意 URI を参照します。
3. 管理者はサインインを求め、アドインに必要なスコープの一覧に同意するように求められます。
4. 完了すると、ブラウザーは ISV から Web ページにリダイレクトされます。これは、同意が成功したことを示すはずです。

別の方法として、ISV は、中央展開の一部として管理者の同意を求める更新されたアプリ マニフェストを提供する場合があります。 このシナリオでは、更新されたアプリ マニフェストをデプロイすると、デプロイを完了する前に同意するように求められます。 管理者の同意 URI は必要ありません。

最後に、アドインが Microsoft 365 ストアで公開されている場合、更新プログラムは自動的に展開され、管理者はスコープへの同意を求められます。 管理者が同意しない場合、ユーザーは更新されたアドインを使用できません。

管理者の同意後にアドインが機能しない場合はどうすればよいですか?

機能を無効にしたり、アドインに必要なアクセス許可を取り消したりしないようにします。 例については、「 メールボックス ポリシーのプロパティの変更」を参照してください。 アドインは委任されたアクセス許可を使用するため、サインインしているユーザーと同じリソースにアクセスできます。 ただし、ポリシーまたは設定によって特定のリソースまたはアクションからユーザーがブロックされた場合、アドインもブロックされます。

ISV からアドイン更新プログラムをデプロイ操作方法。

従来の Exchange トークンを使用するアドインがある場合は、NAA を使用するようにアドインを移行するためのタイムラインに関する情報を ISV に問い合わせてください。 ISV がアドインを移行すると、ほとんどの場合、管理者の同意 URL が提供されます。 詳細については、「 管理者の同意フローのしくみ」 を参照してください。

ISV では、一元化されたデプロイを通じてデプロイするための更新されたアプリ マニフェストも提供される場合があります。 一元展開中に、アドインで必要な Microsoft Graph スコープに同意するように求められる場合があります。 このシナリオでは、管理者の同意 URI を使用する必要はありません。

アドインが Microsoft AppSource から展開されている場合は、ISV がアドインの更新プログラムをロールアウトするときに、Microsoft Graph スコープへの同意を求めるメッセージが表示される可能性があります。 同意するまで、テナントのユーザーは NAA で新しいバージョンのアドインを使用できません。

organizationのどのアドインが影響を受けますか?

2024 年 10 月の時点でレガシ トークンを使用する Microsoft ストアに発行されたすべての Outlook アドインの一覧を公開しました。 一覧を使用して、レガシ トークンを使用する可能性がある Outlook アドインのレポートを作成する方法の詳細については、「レガシ Exchange Online トークンを使用する Outlook アドインを検索する」を参照してください。 また、従来のトークンを使用してアドインを追跡しやすくするために、レポート ツールにも取り組んでいます。 2025 年初頭にレポート ツールを利用できるようにしたいと考えています。

アドインでは、レガシ トークンを使用して、EWS または Outlook REST API を介して Exchange からリソースを取得できます。 アドインでは、一部のユース ケースでは Exchange リソースが必要な場合もあれば、他のユース ケースでは必要な場合は必要な場合があるため、アドインに更新プログラムが必要かどうかを判断するのが困難な場合があります。 アドインの開発者と所有者に問い合わせ、アドイン コードが次の API を参照しているかどうかを確認することをお勧めします。

• makeEwsRequestAsync
• getUserIdentityTokenAsync
• getCallbackTokenAsync

アドインに ISV を使用する場合は、できるだけ早く連絡して、従来の Exchange トークンから移行するためのプランとタイムラインがあることを確認することをお勧めします。 ISV 開発者は、Exchange レガシ トークンの終了の準備ができていることを確認するために、Microsoft の連絡先に質問を直接連絡する必要があります。 organization内の開発者に依存している場合は、この FAQ と「入れ子になったアプリ認証を使用して Office アドインで SSO を有効にする」の記事を確認する必要があります。 質問は 、OfficeDev/office-js GitHub issue サイトで提起する必要があります。

同意があるアドインはどこで見つかりますか?

管理者またはユーザーが同意すると、Microsoft Entra 管理センターに一覧表示されます。 アプリの登録は、次の手順を使用して見つけることができます。

1. https://entra.microsoft.com/#homeに移動します。
2. 左側のナビゲーション ウィンドウで、[アプリケーション>アプリの登録] を選択します。
3. [アプリの登録] ページで、[すべてのアプリケーション] を選択します。
4. これで、名前または ID で任意のアプリ登録を検索できます。

アドインを更新した発行元の一覧はありますか?

一部の広く使用されている Outlook アドインの発行元は、次に示すようにアドインを既に更新しています。

• Outlook 用 Atlassian Jira Cloud
• Outlook 用ボックス
• Outlook のクリックアップ
• iEnterprises® - Outlook コネクタ
• HubStar Connect
• LawToolBox
• OnePlace ソリューション
• SalesForce for Outlook
• Set-OutlookSignatures Benefactor Circle
• Wrike
• zoho CRM for Email
• zoho Recruit for Email
• zoho projects for Email
• Outlook の Zoho Sign
• zoho WorkDrive for Email
• 請求書と時間の追跡 - Zoho 請求書

発行元がマニフェストを更新し、アドインが Microsoft ストア経由で展開されている場合は、管理者として更新プログラムをアップグレードして展開するように求められます。 発行元がマニフェストを更新し、アドインが中央展開を通じてデプロイされる場合は、新しいマニフェストを管理者としてデプロイする必要があります。 場合によっては、パブリッシャーがアドインの新しいスコープに同意するために使用する必要がある管理者の同意 URI を持っている場合があります。 アドインの更新に関する詳細情報が必要な場合は、発行元に問い合わせてください。

Outlook アドインの移行に関する FAQ

Microsoft が Outlook アドインを移行するのはなぜですか?

Entra ID トークンを使用して Microsoft Graph に切り替えることは、Outlook および Exchange のお客様のセキュリティの大きな向上です。 Entra ID (旧称 Azure Active Directory) は、クラウドベースの主要な ID およびアクセス管理サービスです。 お客様は、条件付きアクセス、MFA 要件、継続的なトークン監視、リアルタイムの安全性ヒューリスティックなど、従来の Exchange トークンでは使用できないゼロ トラスト機能を利用できます。 お客様は Exchange に格納されている重要なビジネス データを格納するため、このデータが確実に保護されていることが重要です。 Microsoft Graph で Entra ID トークンを使用するように Outlook エコシステム全体を移行すると、顧客データのセキュリティが大幅に向上します。

Outlook アドインを NAA に移行する必要がありますか?

いいえ。 Outlook アドインでは NAA を使用する必要はありませんが、NAA ではユーザーに最適な認証エクスペリエンスと組織に最適なセキュリティ体制が提供されます。 アドインが従来の Exchange トークンを使用していない場合、Exchange トークンの非推奨の影響を受けることはありません。 Entra ID に依存する MSAL.js またはその他の SSO メソッドを使用するアドインは引き続き機能します。

Outlook アドインがレガシ トークンに依存しているかどうかを確認操作方法。

アドインで従来の Exchange ユーザー ID トークンとコールバック トークンを使用しているかどうかを確認するには、コードで次の API の呼び出しを検索します。

• makeEwsRequestAsync
• getUserIdentityTokenAsync
• getCallbackTokenAsync

アドインでこれらの API のいずれかを呼び出す場合は、NAA を採用し、代わりに Entra ID トークンを使用して Microsoft Graph にアクセスするように移行する必要があります。

スコープ内の Outlook アドインはどれですか?

多くの主要なアドインがスコープ内にあります。 アドインが EWS または Outlook REST を使用してExchange Onlineリソースにアクセスする場合は、ほぼ確実に従来の Outlook トークンから NAA に移行する必要があります。 アドインが Exchange オンプレミス専用 (Exchange 2019 など) の場合、この変更の影響を受けません。

NAA に移行しない場合、Outlook アドインはどうなりますか?

Outlook アドインを NAA に移行しないと、Exchange Onlineで期待どおりに動作しなくなります。 Exchange トークンがオフの場合、Exchange Onlineはレガシ トークンの発行をブロックします。 従来のトークンを使用するアドインは、Exchange オンライン リソースにアクセスできません。

アドインがオンプレミスでのみ機能する場合、またはアドインが非推奨パスにある場合は、更新する必要がない場合があります。 ただし、EWS または Outlook REST を介して Exchange リソースにアクセスするほとんどのアドインは、期待どおりに機能し続けるために移行する必要があります。

Outlook アドイン操作方法 NAA に移行しますか?

Outlook アドインで NAA をサポートするには、次のドキュメントとサンプルを参照してください。

• 入れ子になったアプリ認証を使用して Office アドインで SSO を有効にします。
• 入れ子になったアプリ認証を使用した SSO を使用した Outlook アドイン。

操作方法最新のガイダンスに追いつくのですか?

新しい情報が利用可能になると、この FAQ が更新されます。 Office アドイン コミュニティコールと M365 開発者ブログで、今後の追加のガイダンスについて説明します。 最後に、OfficeDev/office-js GitHub issue サイトで NAA とレガシ Exchange Online トークンの非推奨に関する質問をすることができます。 問題をグループ化して優先順位を付けることができるように、タイトルに "NAA" を配置してください。

問題を送信する場合は、次の情報を含めてください。

• Outlook クライアントのバージョン。
• Outlook リリース チャネルの対象ユーザー (クライアント用)。
• 問題のスクリーン キャプチャ。
• 問題が発生するプラットフォーム (Windows、Outlook (新規)、Mac、iOS、Android)。
• 問題が発生したセッション ID。
• 使用されているアカウントの種類。
• msal-browser のバージョン。
• msal-browser からのログ。

開発者の質問

MSAL と NAA からより多くのデバッグ情報を取得操作方法

入れ子になったパブリック クライアント アプリケーションを初期化するときに、msalConfig でデバッグ情報を有効にするには、次のコードを使用します。 これにより、コンソールに追加の詳細が記録されます。

const msalConfig = {
  auth: {...},
  system: {
    loggerOptions: {
      logLevel: LogLevel.Verbose,
      loggerCallback: (level, message, containsPii) => {
        switch (level) {
          case LogLevel.Error:
            console.error(message);
            return;
          case LogLevel.Info:
            console.info(message);
            return;
          case LogLevel.Verbose:
            console.debug(message);
            return;
          case LogLevel.Warning:
            console.warn(message);
            return;
        }
      },
    }
  }
};

操作方法 ID トークンを検証するか、ユーザーを認証しますか?

Exchange トークンを使用すると、ID トークンを検証し、それを使用してユーザーが独自のリソースにアクセスすることを承認できます。 詳細については、「 Exchange の ID トークンを使用してユーザーを認証する」を参照してください。 ただし、Entra ID トークンを持つ MSAL では、この方法は使用されません。

MSAL を使用してトークンを要求すると、常に 3 つのトークンが返されます。

MSAL は常にこれら 3 つのトークンを返します。 トークン要求に含まれていない場合でも、既定のスコープとして profile、 openid、 offline_access が要求されます。 これにより、ID と更新トークンが確実に要求されます。 ただし、アクセス トークンを取得するには、 user.read などのリソース スコープを少なくとも 1 つ含める必要があります。 そうでない場合、要求は失敗する可能性があります。

ネットワーク呼び出しを介して ID トークンを渡して、サービスへのアクセスを有効または承認することは、セキュリティ対策パターンです。 トークンはクライアント (作業ウィンドウ) のみを対象としており、サービスがトークンを確実に使用して、ユーザーがアクセスを承認したことを確認する方法はありません。 ID トークン要求の詳細については、「 https://zcusa.951200.xyz/en-us/entra/identity-platform/id-token-claims-reference」を参照してください。

常に独自のサービスへのアクセス トークンを要求することが非常に重要です。 アクセス トークンには同じ ID 要求も含まれているため、ID トークンを渡す必要はありません。 代わりに、サービスのカスタム スコープを作成します。 独自のサービスのアプリ登録設定の詳細については、「 保護された Web API: アプリの登録」を参照してください。 サービスがアクセス トークンを受け取ると、そのトークンを検証し、アクセス トークン内から ID 要求を使用できます。

ユーザーがオンラインアカウントかオンプレミスアカウントかを判断操作方法

サインインしているユーザーが、Office.UserProfile.accountType プロパティを使用して、Exchange Online アカウントまたはオンプレミスの Exchange アカウントを持っているかどうかを判断できます。 アカウントの種類のプロパティ値が エンタープライズの場合、メールボックスはオンプレミスの Exchange サーバー上にあります。 ボリューム ライセンスの永続的なOutlook 2016では、accountType プロパティはサポートされません。 これを回避するには、Exchange オンプレミス サーバーの Exchange Web Service (EWS) で ResolveNames 操作を呼び出して、受信者の種類を取得します。

関連コンテンツ

• 入れ子になったアプリ認証を使用して Office アドインで SSO を有効にします。
• 入れ子になったアプリ認証を使用した SSO を使用した Outlook アドイン。