Microsoft Outlook 365 の認証

前提条件

Integration Service では、Microsoft Graph ベースのコネクタのいずれかへのコネクションを作成する際に、次の 2 つの認証オプションのいずれかを選択できます。

• OAuth 2.0 認可コード – UiPath のパブリック アプリケーションに接続します。
• 独自の OAuth 2.0 アプリ (BYOA) を使用する – 作成したプライベート アプリケーションに接続します。

• OAuth 2.0 認可コード: Microsoft アカウントの資格情報。

環境

初めて [認証] 画面にアクセスするときに、ロボット グループを選択できます。 利用可能なオプションは次のとおりです。

• Office 365 (既定)
• 米国政府 L4 - パブリック セクター ドメイン
• 米国政府 L5 - パブリック セクター ドメイン
• 中国

詳しくは、「 Microsoft Graph および Graph Explorer サービスのルート エンドポイント」をご覧ください。

多くの組織では、外部アプリケーションへの接続を作成する前に管理者の同意が必要です。 管理者の同意ワークフローでは、接続が確立される前に、管理者が特定のユーザーまたはグループに対するアプリの登録を承認する必要があります。 詳細については、Microsoft ドキュメントの「 管理者の同意ワークフローの概要 」と 「Microsoft Entra ID のユーザーと管理者の同意 」をご覧ください。

注:

Integration Service は、コネクションを作成するユーザーを偽装します。 ユーザーの資格情報を使用して、指定のアプリケーション内のリソースと同じリソースすべてへのアクセスを可能にします。コネクションを共有すると、そのコネクションを有する Microsoft Outlook に加えられた変更はすべて、そのユーザーに代わって行われます。

スコープ

コネクタは、次のアクセス許可/スコープを要求します。

• UiPath パブリック アプリ: Mail.Read、 Mail.Read.Shared、 Mail.ReadWrite、 Mail.ReadWrite.Shared、 Mail.Send、 Mail.Send.Shared、 MailboxSettings.ReadWrite、 Calendars.Read、 Calendars.Read.Shared、 Calendars.ReadWrite、 Calendars.ReadWrite.Shared、 profile、 openid、 email、 offline_access、 User.Read
• 独自の OAuth 2.0 アプリ (BYOA) を使用する:
  • コネクションを作成するための最小スコープ: openid、 offline_access、 Mail.Read。
  • Outlook トリガーに必要なスコープの最小限のリストは以下のとおりです。
    • openid、 offline_access、 Mail.Read、 Mail.Read.Shared – 共有メールボックス トリガー
    • Calendars.Read – カレンダーの予定用です。
    • Calendars.Read.Shared – 共有された予定表のイベント用。

手記： [Bring your own OAuth 2.0 app] を使用して認証する場合は、アプリの作成時に設定されたスコープが既定で利用されます。 既定のアプリのアクセス許可を使用する場合は、 common スコープを宣言できます。 つまり、Azure では、そのアプリケーションに対して設定されたアクセス許可のみを使用します。 接続の作成時に [スコープ ] フィールドを使用して追加のスコープを宣言することもできます。 その後、サインイン時に追加の同意を付与するよう求められます。

Microsoft Outlook 365 コネクションを追加する

お使いの Microsoft Outlook 365 インスタンスへのコネクションを作成するには、次の手順を実行する必要があります。

1. Automation Cloud^TM で [Integration Service] を選択します。

2. [コネクタ] のリストから [Microsoft Outlook 365] を選択します。検索バーで検索してコネクタを探すこともできます。

3. [ Microsoft Outlook 365 に接続 ] ボタンを選択します。
4. これで、コネクションのページにリダイレクトされます。

   [OAuth 2.0 認可コード] または [独自の OAuth 2.0 アプリ (BYOA) を使用する] の 2 つの認証の種類から選択できます。

   • [OAuth 2.0 認可コード] を選択した場合は、[接続] をクリックして、Microsoft のメール アドレスとパスワードを使用して認証します。
   • [Bring your own OAuth 2.0 app] を選択した場合は、[クライアント ID] と [クライアント シークレット]、[テナント ID]、[スコープ] を指定する必要があります。この共通シナリオは、各種アクティビティの操作に必要です。 必要なスコープについては、アクティビティのドキュメントをご覧ください。
     手記： マルチテナント アプリケーションを使用している場合は、[ テナント ID] は既定値 (common) のままにします。 シングル テナント アプリケーションを使用している場合は、Azure からテナント ID を取得します。 「 Microsoft Entra テナント ID を確認する方法」をご覧ください。
5. コネクションが追加されました。

サインイン プロセス中にエラーが発生した場合は、Microsoft Outlook 365 の管理者に連絡することをお勧めします。

詳細については、Office 365 Outlook コネクタのドキュメントをご覧ください。

独自の OAuth 2.0 アプリ (BYOA) を使用する

アプリケーションの作成方法については、Microsoft の公式ドキュメントにアクセスし、「Microsoft ID プラットフォームにアプリケーションを登録する」に記載された手順に従ってください。

注: これは高度な機能であり、対象のアプリケーションの管理者権限が必要です。 IT 管理者と協力して、アプリケーションを正常にセットアップしてください。

要件

Integration Service で使用する独自のアプリケーションを作成する場合は、次の要件を考慮する必要があります。

1. アプリケーションを マルチテナント アプリケーションまたは シングルテナント アプリケーションとして構成する必要があります。
2. Web アプリケーションを構成する必要があります。
3. Web リダイレクト URI を構成する必要があります。OAuth 2.0 アプリケーションのリダイレクト URI (またはコールバック URL) は、コネクション作成時の認証画面で提供されます。 https://cloud.uipath.com/provisioning_/callback。
4. 委任されたアクセス許可を設定する必要があります。 詳細については、Microsoft の公式ドキュメントの 「権限 」をご覧ください。
5. アプリケーションのクライアント シークレットを生成します。

大事な： プライベート OAuth アプリケーションを使用するメリットは、実際のニーズに応じてアクセス許可をカスタマイズできることです。 Microsoft 365 のアクティビティ パッケージ内の各アクティビティに必要なスコープについて詳しくは、「 スコープを使用する 」をご覧ください。 アクティビティのドキュメント をご覧ください。

このコネクタは Microsoft Graph API を使用します。 すべての権限について詳しくは、 Microsoft Graph の権限に関するリファレンス ページをご覧ください。

アプリケーションを作成したら、そのクライアント ID とクライアント シークレットを使用して、Microsoft コネクタへのコネクションを作成します。

OAuth アプリケーションの更新トークン

OAuth アプリケーションの更新トークンは、Microsoft によっていつでも無効にされたり、取り消されたりされます。これは、タイムアウトや失効など、さまざまな理由で発生する可能性があります。詳細については、Microsoft の公式ドキュメントをご覧ください。

警告: トークンを無効にするとコネクションが失敗し、コネクションを修正しないとオートメーションを実行できません。

OAuth アプリケーションを作成する際は、Microsoft のベスト プラクティスに従ってください。 OAuth 2.0 アプリケーションの作成方法の詳細については、Microsoft のドキュメントをご覧ください。

この問題は、OneDrive & SharePoint コネクタだけでなく、Outlook や Teams など、すべての Microsoft Graph ベースのコネクタに影響します。