次の方法で共有

SSO を使用した Microsoft Graph への承認

  • [アーティクル]

ユーザーは、個人の Microsoft アカウントまたはMicrosoft 365 Educationまたは職場アカウントを使用して Office にサインインします。 Office アドインの Microsoft Graph へのアクセスの承認には、ユーザーの Office サインオン資格証明を使用するのが最良の方法です。 これにより、2 回目はサインインする必要なく Microsoft Graph データにアクセスできます。

SSO と Microsoft Graph のアドイン アーキテクチャ

Web アプリケーションのページと JavaScript をホスティングすることに加え、アドインでは、同一の完全修飾ドメイン名で、Microsoft Graph へのアクセス トークンを取得して、要求を送信するための 1 つ以上の Web API をホストする必要もあります。

アドイン マニフェストには、アドインに必要な <Microsoft Graph へのアクセス許可など、Office に重要な Azure アプリ登録情報を提供する WebApplicationInfo> 要素が含まれています。

実行時の動作のしくみ

次の図は、サインインして Microsoft Graph にアクセスするための手順を示しています。 プロセス全体で OAuth 2.0 および JWT アクセス トークンが使用されます。

SSO プロセスを示す図。

  1. アドインのクライアント側コードは、Office.js API getAccessToken を呼び出します。 これにより、アドインのアクセス トークンを取得するように Office ホストに指示されます。

    ユーザーがサインインしていない場合は、Office ホストとMicrosoft ID プラットフォームを組み合わせて、ユーザーがサインインして同意するための UI が提供されます。

  2. Office ホストは、Microsoft ID プラットフォームからアクセス トークンを要求します。

  3. Microsoft ID プラットフォームは、アクセス トークン A を Office ホストに返します。 アクセス トークン A は、アドイン独自のサーバー側 API へのアクセスのみを提供します。 Microsoft Graph へのアクセスは提供されません。

  4. Office ホストは、アクセス トークン A をアドインのクライアント側コードに返します。 これで、クライアント側のコードがサーバー側 API に対して認証された呼び出しを行えるようになりました。

  5. クライアント側のコードは、認証を必要とするサーバー側の Web API に対して HTTP 要求を行います。 これには、承認証明としてアクセス トークン A が含まれます。 サーバー側コードは、アクセス トークン A を検証します。

  6. サーバー側コードでは、OAuth 2.0 On-Behalf-Of フロー (OBO) を使用して、Microsoft Graph へのアクセス許可を持つ新しいアクセス トークンを要求します。

  7. Microsoft ID プラットフォームは、Microsoft Graph へのアクセス許可を持つ新しいアクセス トークン B を返します (アドインがアクセス許可offline_access要求した場合は更新トークン)。 サーバーは必要に応じてアクセス トークン B をキャッシュできます。

  8. サーバー側コードは Microsoft Graph APIに要求を行い、Microsoft Graph へのアクセス許可を持つアクセス トークン B が含まれています。

  9. Microsoft Graph は、サーバー側のコードにデータを返します。

  10. サーバー側コードは、データをクライアント側のコードに戻します。

それ以降の要求では、認証された呼び出しをサーバー側のコードに行うときに、クライアント コードは常にアクセス トークン A を渡します。 サーバー側コードは、トークン B をキャッシュして、今後の API 呼び出しで再度要求する必要がないようにすることができます。

Microsoft Graph にアクセスする SSO を開発する

SSO を使用する他のアプリケーションと同様に、Microsoft Graph にアクセスするアドインを開発します。 詳細な説明については、「 Office アドインのシングル サインオンを有効にする」を参照してください。違いは、アドインにサーバー側の Web API が必要であるという点です。

使用する言語とフレームワークによっては、記述する必要のあるサーバー側コードが簡単になるライブラリが使用できることがあります。 コードでは、次に示す操作を実行する必要があります。

  • クライアント側コードから渡されるたびに、アクセス トークン A を検証します。 詳細については、アクセス トークンの検証に関するページを参照してください。
  • アクセス トークン、ユーザーに関するメタデータ、アドインの資格情報 (その ID とシークレット) を含むMicrosoft ID プラットフォームを呼び出して、OAuth 2.0 On-Behalf-Of フロー (OBO) を開始します。 OBO フローの詳細については、「Microsoft ID プラットフォームおよび OAuth 2.0 On-Behalf-Of フロー」を参照してください。
  • 必要に応じて、フローが完了したら、返されたアクセス トークン B を Microsoft Graph へのアクセス許可でキャッシュします。 アドインで Microsoft Graph を複数回呼び出す場合に、これが行われます。 詳細については、「Microsoft 認証ライブラリ (MSAL) を使用してトークンを取得およびキャッシュする」を参照してください。
  • (キャッシュされている可能性がある) アクセス トークン B を Microsoft Graph に渡すことで、Microsoft Graph データを取得する 1 つ以上の Web API メソッドを作成します。

詳細なチュートリアルとシナリオについては、次を参照してください。

Microsoft AppSource での SSO 対応アドインの配布

Microsoft 365 管理者が AppSource からアドインを取得すると、管理者は 統合アプリ を通じてアドインを再配布し、Microsoft Graph スコープにアクセスするためのアドインへの管理者の同意を付与できます。 ただし、エンド ユーザーが AppSource からアドインを直接取得することも可能です。この場合、ユーザーはアドインに同意を付与する必要があります。 これにより、ソリューションを提供した潜在的なパフォーマンスの問題が発生する可能性があります。

などの呼び出しgetAccessTokenOfficeRuntime.auth.getAccessToken( { allowConsentPrompt: true } );でコードがオプションを渡したallowConsentPrompt場合、Microsoft ID プラットフォームがアドインに同意がまだ付与されていないと Office に報告された場合、Office はユーザーに同意を求めることができます。 ただし、セキュリティ上の理由から、Office はユーザーに Microsoft Graph profile スコープへの同意のみを求めることができます。 Office では、他の Microsoft Graph スコープへの同意を求めることはできません。それ以外の場合も User.Readです。 つまり、ユーザーがプロンプトで同意を許可した場合、Office はアクセス トークンを返します。 ただし、追加の Microsoft Graph スコープを使用してアクセス トークンを新しいアクセス トークンと交換しようとすると、エラー AADSTS65001で失敗します。つまり、(Microsoft Graph スコープに対する) 同意が付与されていないことを意味します。

注:

管理者がエンド ユーザーの同意 { allowConsentPrompt: true } をオフにしている場合、スコープに対 profile しても同意の要求が失敗する可能性があります。 詳細については、「 Azure Active Directory を使用してエンド ユーザーがアプリケーションに同意する方法を構成する」を参照してください。

コードでは、別の認証システムにフォールバックすることでこのエラーを処理できます。これにより、ユーザーは Microsoft Graph スコープへの同意を求められます。 コード例については、「 シングル サインオンを使用する Node.js Office アドインを作成する 」および「シングル サインオンとリンク先のサンプル を使用する ASP.NET Office アドインを作成する 」を参照してください。 プロセス全体で、Microsoft ID プラットフォームへの複数のラウンド トリップが必要です。 このパフォーマンスの低下を回避するには、 の呼び出しgetAccessTokenに オプションを含めます forMSGraphAccess (例: OfficeRuntime.auth.getAccessToken( { forMSGraphAccess: true } ))。 これは、アドインに Microsoft Graph スコープが必要であることを Office に通知します。 Office はMicrosoft ID プラットフォームに対して、Microsoft Graph スコープへの同意がアドインに既に付与されていることを確認するように求めます。 がある場合は、アクセス トークンが返されます。 ない場合は、 の getAccessToken 呼び出しによってエラー 13012 が返されます。 コードでは、Microsoft ID プラットフォームとトークンを交換する運命の試行を行うことなく、認証の代替システムにすぐにフォールバックすることで、このエラーを処理できます。

ベスト プラクティスとして、アドインが AppSource で配布され、Microsoft Graph スコープが必要な場合は常に に渡forMSGraphAccessgetAccessTokenします。

Outlook アドインでの SSO の詳細

SSO を使用する Outlook アドインを開発し、それをテスト用にサイドロードした場合、管理者の同意が付与されている場合でも、Office は常にエラー 13012 をforMSGraphAccessgetAccessToken返します。 このため、Outlook アドインをforMSGraphAccess開発するときにオプションをコメント アウトする必要があります。 運用環境用にデプロイする場合は、必ずオプションのコメントを解除してください。 偽の 13012 は、Outlook でサイドローディングしている場合にのみ発生します。

Outlook アドインの場合は、Microsoft 365 テナントの先進認証を必ず有効にしてください。 これを行う方法については、「Exchange Onlineで Outlook の先進認証を有効または無効にする」を参照してください。

Google Chrome は、2024 年にサード パーティの Cookie を段階的に廃止し、トラッキング防止という名前の機能を導入しています。 Chrome ブラウザーでトラッキング防止が有効になっている場合、アドインはサード パーティの Cookie を使用できません。 アドインでは、複数のサインオン要求やエラーなど、ユーザーを認証するときに問題が発生する可能性があります。

認証エクスペリエンスの向上については、「 デバイスの状態を使用した、ブロックされたサード パーティの Cookie を使用したブラウザーでの SSO エクスペリエンスの向上」を参照してください。

Google Chrome ロールアウトの詳細については、次のリソースを参照してください。

関連項目