How to connect to Microsoft 365 activities

Überblick

Microsoft 365 activities have different authentication flows that you can choose from. Your choice is dependent on: the type of automation mode you plan to run (attended or unattended), the type of projects you want to build (cross-platform or Windows), the type of permissions you want to grant (delegated or app-only), and your application authentication requirements (consult with your administrator if you're unsure which authentication requirements apply to your application).

Use the table below to understand the basic differences between each authentication type:

Microsoft Authentication flow	Microsoft 365 Scope - Authentication type	Integration Service-Verbindung	Robot type - Attended	Robot type - Unattended	API permission type
OAuth 2.0 authorization code flow	Interactive Token - public app	OAuth 2.0: Autorisierungscode			Delegierte Berechtigungen
	Interactive Token - BYOA	Bringen Sie Ihre eigene OAuth 2.0-App mit			Delegierte Berechtigungen
Integrated Windows authentication (IWA)	Integrierte Windows-Authentifizierung	Keine Angabe			Delegierte Berechtigungen
UsernameAndPassword	UsernameAndPassword	Keine Angabe			Delegierte Berechtigungen
OAuth 2.0 client credentials flow	Application ID and secret	Keine Angabe			Anwendungsberechtigungen
	Application ID and certificate	Keine Angabe			Anwendungsberechtigungen

Delegated permissions versus application permissions

To understand the differences between delegated and application permissions, see the Microsoft official documentation: Comparison of delegated and application permissions.

Briefly, the differences are as follows:

• With delegated permissions, the application impersonates a user and acts on the user's behalf. The application can access only what the signed-in user can access.
• With application permissions, the application acts on its own, without a signed-in user. The application can access any data that its permissions are associated with.

For both delegated and application permissions, you can restrict what the application can and can't access using the scopes defined when you create the app. Refer to Scopes and permissions in the Microsoft documentation.

Multitenant versus single-tenant applications

Both Microsoft 365 Scope and Integration Service connections support single tenant applications and multitenant applications. To learn the difference between the two, refer to Who can sign in to you app? in the Microsoft official documentation.

Azure environments

Both Microsoft 365 Scope and Integration Service connections support multiple Azure environments:

• Connections through the Scope activity support: Azure, Azure Global, China, Germany or US Government. The default value is Global.
• Connections through Integration Service support: Default, US Government L4, US Government L5, and China.

Integration Service-Verbindungen

Integration Service connectors use OAuth 2.0 authorization code flow with delegated permissions.

The Microsoft 365 modern activities and triggers establish an authenticated connection to the Integration Service Microsoft OneDrive & SharePoint and the Microsoft Outlook 365 connectors. To learn more about Integration Service connections, refer to Set up Integration Service connectors.

When you connect to the Microsoft connectors in Integration Service, you have the option to use the standard UiPath public application (with a set of default, non-configurable scopes) or create your own application with Microsoft and customize the scopes you need.

Microsoft 365 Scope connections

The Microsoft 365 Classic activities establish an authenticated connection to your Microsoft 365 applications via the Microsoft 365 Scope activity.

The activities need authorization from the Microsoft identity platform. To enable authorization, you first register your Microsoft 365 application in your Azure Active Directory. When registering your application, you assign Microsoft Graph API permissions to specify the resources your Robot can access on your behalf.

After registering your Microsoft 365 application, Azure Active Directory assigns a unique application (client) ID that you enter in the Microsoft 365 Scope activity. The Application ID is used to collect the necessary information about your registered app to initiate authentication and get the access token to establish the connection.

When you add an activity to Microsoft 365 Scope, its required scopes are automatically detected. You can also choose to allow additional scopes.

Interaktives Token

Überblick

• Runs: as a user.
• Scenario: attended automation.
• Delegated permissions.

Hinweis: Dies ist dieselbe Authentifizierungsmethode, die im Integration Service unterstützt wird, entweder über die öffentliche UiPath-App oder eine private benutzerdefinierte Anwendung (Bring Ihre eigene App-Methode mit).

Details

• When registering your application, you must select an application type. For interactive token authentication, use a mobile/desktop application (which uses OAuth 2.0 authorization code flow).

• Der Authentifizierungstyp „Interaktives Token“ kann für die Attended-Automatisierung verwendet werden und wenn eine mehrstufige Authentifizierung (MFA) erforderlich ist. Dies ist die Standardoption, die wir in unseren Beispielen verwenden. Wenn Sie das Aktivitätspaket ausprobieren möchten, ist diese Option einfach zu konfigurieren und funktioniert gut für persönliche Konten (mit dem Standardumleitungs-URI, der in Schritt 7 im Abschnitt Registrieren Ihrer Anwendung der Einrichtungsanleitung angegeben ist).

• You have the option to register and use your own Azure app (i.e., OAuthApplication = Custom) or the one provided by UiPath (OAuthApplication = UiPath).
• When you run the Microsoft 365 activity for the first time using this authentication type, you are prompted to authorize access to the resources (you granted permissions to when registering your app) via a consent dialogue box. See Get access on behalf of a user.

• If you select this authentication type in Microsoft 365 Scope, leave the Username, Password, and Tenant fields empty.

Integrierte Windows-Authentifizierung (IWA)

Überblick

• Runs: as a user.
• Scenario: unattended automation.
• Delegated permissions.

Note: This authentication type does not work when multi-factor authentication (MFA) is enabled. If your application requires MFA, you can run attended automation using the Interactive Token authentication type or unattended automation using Application ID and Secret and Application ID and Certificate. Application ID and Secret and Application ID and Certificate authentication types are appropriate for unattended automation and work regardless of whether the MFA is enabled or disabled.

Details

• Der Authentifizierungstyp „Integrierte Windows-Authentifizierung“ kann für die Unattended-Automatisierung verwendet werden. Diese Option kann für gehostete Windows-Anwendungen gelten, die auf Computern ausgeführt werden, die mit einer Windows-Domäne oder Azure Active Directory verbunden sind.

• When registering your application, you must select an application type. For IWA authentication type, you must use a mobile/desktop application (which uses OAuth 2.0 authorization code flow).

• Works only for federated users and if your registered Azure application is configured to support IWA. Doesn't work for multi-factor authentication (MFA). See details here: IWA on GitHub.
• You should only select this option if your registered application is configured to support Integrated Windows Authentication.

• If you select this authentication type in Microsoft 365 Scope, leave the Username and Password fields empty. The Tenant field is optional.

UsernameAndPassword

Zusammenfassung

• Runs: as a user.
• Scenario: unttended automation.
• Delegated permissions.

Note: This authentication type does not work when multi-factor authentication (MFA) is enabled. If your application requires MFA, you can run attended automation using the Interactive Token authentication type or unattended automation using Application ID and Secret and Application ID and Certificate. Application ID and Secret and Application ID and Certificate authentication types are appropriate for unattended automation and work regardless of whether the MFA is enabled or disabled.

Details

• This authentication type is provided only for legacy reasons. We do not recommend using this option, as it goes against the principles of modern authentication. It doesn't work for multi-factor authentication (MFA). See details here: User & Password on GitHub.

• Obwohl dies von Microsoft nicht empfohlen wird, können Sie diesen Authentifizierungstyp in öffentlichen Clientanwendungen verwenden. Die Verwendung dieses Authentifizierungstyps erlegt Ihrer Anwendung Einschränkungen auf. Apps, die diesen Flow verwenden, können sich beispielsweise nicht für einen Benutzer anmelden, der eine mehrstufige Authentifizierung (bedingter Zugriff) durchführen muss. Dadurch kann Ihre Anwendung auch nicht von der einmaligen Anmeldung profitieren.
• The ApplicationID property is required when selecting the Username and Password authentication type. You can register your Microsoft 365 Application using your personal, work, and/or school account.

Anwendungs-ID und Geheimschlüssel

Zusammenfassung

• Runs: as background service.
• Scenario: unattended and unattended with MFA enabled.
• Application permissions.
• Recommended for unattended executions or when you want to access the Microsoft Graph API as an application (a background service / daemon) without a signed-in user.

Details

• When registering your application, you must select an application type. For application ID and secret authentication type, use a confidential/web application (which uses OAuth 2.0 client credentials flow).

• Die entsprechenden API-Berechtigungen müssen für die Azure-Anwendung konfiguriert werden, damit Microsoft 365-Aktivitäten ordnungsgemäß funktionieren (z. B. sollten die Anwendungsberechtigungen Group.Create, Group.Read.All und Group.ReadWrite.All für Microsoft Graph konfiguriert werden, wenn Gruppenaktivitäten verwendet werden).

• A single organization can have multiple application (client) IDs for their Microsoft 365 account. Each application (client) ID contains its own permissions and authentication requirements. For example, you and your colleague can both register a Microsoft 365 application in your company's Azure Active Directory with different permissions. Your app can be configured to authorize permissions to interact with files only, while your colleague's app is configured to authorize permissions to interact with files, mail, and calendar. If you enter your application (client) ID into this property and run attended automation, the consent dialogue box would be limited to file permissions (and subsequently, only the Files activities can be used).

• Some activities can't be used with this type of authentication because the corresponding Microsoft Graph API does not support application permissions (e.g. Find Meeting Times).

• Bei E-Mail-Aktivitäten muss ein Wert für den Parameter Account angegeben werden (d. h. welches Postfach aller Mandantenpostfächer Sie verwenden möchten).

• Use Sites.Selected application permission to allow the application to access just the specific SharePoint site collections rather than all.
• When using this authentication type, the application has access to all mailboxes from your tenant, the reason being that application API permission Mail.Read means Read mail in all mailboxes and Mail.ReadWrite means Read and write mail in all mailboxes. One solution is to restrict Application permissions to specific mailboxes, so the application has access only to the specified mailboxes. For more information, see Scoping application permissions to specific Exchange Online mailboxes.

AnwendungsID und Zertifikat

Zusammenfassung

• Runs: as background service.
• Scenario: unattended and unattended with MFA enabled.
• Application permissions.

Details

• When registering your application, you must select an application type. For application ID and certificate authentication type, use a confidential/web application (which uses OAuth 2.0 client credentials flow).

• This authentication mtehod is similar to application ID and secret, but it uses a certificate as a secret instead of a client secret string.

Using certificates

To authenticate using a certificate as a secret, take the following steps:

1. In the the Azure portal:

   • Suchen Sie Ihre registrierte Microsoft 365-Anwendung.
   • Wählen Sie Zertifikate und Geheimnisse aus, und laden Sie Ihre Zertifikatsdatei (öffentlicher Schlüssel) hoch. Sie kann einen der folgenden Dateitypen haben: .cer, .pem, .crt.
     
     

     

     
     
2. Convert the raw contents of your .pfx file representing the certificate to a base64 string. You can use a web-based tool like Base64.Guru or assign the Convert.ToBase64String(System.IO.File.ReadAllBytes(pfxFilePath)) value to a String variable.
3. In the Microsoft 365 Scope activity:

• Set Authentication Type to Application ID and Certificate.
• Legen Sie CertificateAsBase64 auf die base64-Darstellung des Zertifikats fest.
• Wenn für die Verwendung des Zertifikats ein Kennwort erforderlich ist, legen Sie auch den Wert für die Eigenschaft Zertifikatkennwort fest.

So verwenden Sie Microsoft 365-Aktivitäten ohne Integration Service-Verbindungen

Über

Sie können jetzt die neueren Microsoft 365-Aktivitäten über Microsoft 365 Scope auch dann verwenden, wenn Sie nicht über Integration Service verfügen.

The Microsoft 365 activities designed specifically for Integration Service feature a Connection field, which enables you to choose a connection created through an Integration Service connector. When used inside Microsoft 365 Scope, the activities simply inherit the connection information from the Scope.

Matrix von Authentifizierungs- und Projekttypen

Microsoft 365
	Cloud		Lokal
	Microsoft Office 365-Anwendungsbereich	Integration Service	Microsoft Office 365-Anwendungsbereich	Integration Service
Plattformübergreifend
App-ID und Zertifikat
App-ID und Geheimschlüssel
OAuth - Bringen Sie OAuth durch OAuth auf
OAuth – UiPath App
Benutzername und Kennwort
Integrierte Windows-Authentifizierung
Windows
App-ID und Zertifikat
App-ID und Geheimschlüssel
OAuth - Bringen Sie OAuth durch OAuth auf
OAuth – UiPath App
Benutzername und Kennwort
Integrierte Windows-Authentifizierung

Verbindungsmethoden

Es gibt zwei Möglichkeiten, eine Verbindung in der Aktivität Microsoft 365 Scope einzurichten.

Verbindungsmethode		Beschreibung	Vorteile	Nachteile
Asset Hinweis: Empfohlen.		Verwendet ein Orchestrator-Asset, um die Verbindung zusammen mit der Scope-Konfiguration zu speichern. Das Asset hat ein JSON-Format. Bei jeder Verwendung ruft die Aktivität die Konfiguration aus dem Asset ab. Basierend auf der Asset-Konfiguration verhält sich der Scope unterschiedlich; Sie identifiziert den Authentifizierungstyp und blendet nicht benötigte Felder aus. Wenn die Asset-JSON nicht richtig festgelegt ist, wird ein Validierungsfehler ausgelöst.	Die Aktivitäten profitieren von Suchen zur Entwurfszeit und können Dateien, Ordner, Listen, Bereiche usw. erkennen. Die Verbindung ist leicht übertragbar, da Anmeldeinformationen nicht im Klartext von einem Benutzer an einen anderen weitergegeben werden. Kann von einem Administrator konfiguriert werden. Es ist sicherer, da die Anmeldeinformationen den Studio-Workflow nicht erreichen.	Erfordert einen fortgeschrittenen Benutzer, um das Asset zu konfigurieren. Für einen Citizen Developer nicht einfach einzurichten.
Eigenschaften-Panel		Verwenden Sie den vorhandenen Eigenschaftenbereich, um die Verbindungsanmeldeinformationen zu konfigurieren. Die Konfiguration kann im Klartext oder über Variablen hinzugefügt werden.	Einfacher zu verwenden. Die Abwärtskompatibilität bleibt erhalten.
	Konfiguration durch Klartext Hinweis: Nicht empfohlen.	Konfigurieren Sie den Eigenschaftenbereich mit Nur-Text-Werten.	Die Aktivitäten profitieren von Suchen zur Entwurfszeit und können Dateien, Ordner, Listen, Bereiche usw. erkennen.	Weniger sicher, weil die Anmeldeinformationen in Klartext zwischen Benutzern übergeben werden müssen.
	Konfiguration über Variablen	Konfigurieren Sie den Eigenschaftenbereich mit Variablen.	Mehr Sicherheit, da die Anmeldeinformationen den Studio-Workflow nicht erreichen.	Die Aktivitäten können zur Entwurfszeit keine Ressourcen erkennen.

Microsoft 365 Scope-Asset-Asset-Format

Standard-Asset-Format

{
    "CertificateAsBase64": "",
    "CertificatePassword": "",
    "ClientSecret": "",
    "Environment": "Default" | "Global" | "China" | "Germany" | "USGovernment" | "USGovernmentDOD",
    "Mode": "interactive" | "integrated" | "uap" | "appidsecret" | "appidcertificate",
    "OAuth2AppData": {
        "ApplicationId": "",
        "TenantId": ""
    }
}

UiPath application asset configuration

{
    "CertificateAsBase64": "",
    "CertificatePassword": "",
    "ClientSecret": "",
    "Environment": "Default",
    "Mode": "interactive" | "integrated" | "uap" | "appidsecret" | "appidcertificate",
    "OAuth2AppData": {
        "ApplicationId": "f2f43f65-16a6-4319-91b6-d2a342a88744",
        "TenantId": ""
    }
}

Benutzerdefinierte Konfiguration der Anwendungs-Assets

Hinweis: Dies ist nur ein Beispiel. Konfigurieren Sie Ihre eigene Anwendung und rufen Sie die erforderlichen OAuth2AppData ab.

{
    "CertificateAsBase64": "",
    "CertificatePassword": "",
    "ClientSecret": "",
    "Environment": "Default",
    "Mode": "interactive" | "integrated" | "uap" | "appidsecret" | "appidcertificate",
    "OAuth2AppData": {
        "ApplicationId": "d47f7253-65ae-58n5-ag04-26109734e6de",
        "TenantId": "3ce4ef03-chb1-871f-94b0-345136965f10"
    }
}

Einschränkungen

Die folgenden Funktionen sind nicht verfügbar, wenn Aktivitäten innerhalb von Microsoft 365 Scope verwendet werden: Trigger, Bindungen und Überschreiben.

Tokenaktualisierung

Es ist kein Dienst zum Aktualisieren Ihrer Verbindungstoken verfügbar, wie der, der im Integration Service verfügbar ist.

If the Authorization Token isn't refreshed for a certain number of days, it expires, and you must re-authenticate. To avoid the expiration of authorization tokens, run a robot with that specific connection. Running an automation with the Scope activity refreshes the authorization token.

Zusätzliche OAuth 2.0-Ressourcen:

• Mit Genehmigungsablauf des Administrators: OAuth 2.0-Client-Anmeldeinformationen werden auf der Microsoft Identity-Plattform genutzt
• Ohne Administratorgenehmigungsflow: Microsoft Identity-Plattform und OAuth 2.0-Autorisierungscodeflow – Microsoft Identity-Plattform