次の方法で共有

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 をホストする必要もあります。

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

実行時の動作のしくみ

次の図は、サインインして 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 からアドインを直接取得することも可能です。この場合、ユーザーはアドインに同意を付与する必要があります。 これにより、ソリューションを提供した潜在的なパフォーマンスの問題が発生する可能性があります。

コードがOfficeRuntime.auth.getAccessToken( { allowConsentPrompt: true } );などのgetAccessTokenの呼び出しで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 Graph スコープへの同意がアドインに既に付与されていることを確認するように Microsoft ID プラットフォームに依頼します。 がある場合は、アクセス トークンが返されます。 ない場合は、 getAccessToken の呼び出しでエラー 13012 が返されます。 コードでは、Microsoft ID プラットフォームとトークンを交換する運命の試行を行うことなく、認証の代替システムにすぐにフォールバックすることで、このエラーを処理できます。

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

Outlook アドインでの SSO の詳細

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

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

Google Chrome では、ユーザーが閲覧エクスペリエンスをより詳細に制御できるように取り組んでいます。 ユーザーは Chrome ブラウザーでサードパーティの Cookie をブロックできます。 これにより、アドインがそのような Cookie を使用できなくなります。 これにより、複数のサインオン要求やエラーなど、アドインがユーザーを認証するときに問題が発生する可能性があります。

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

Google Chrome ロールアウトの詳細については、「 Web 上のプライバシー サンドボックスの新しいパス」を参照してください。

関連項目