OAuth application setup

This section explains how to set up the OAuth application, regardless of the authentication type you use, whether it is Interactive Token, Integrated Windows Authentication, Username and password, Application ID and secret, or Application ID and certificate.

You can either use the UiPath Public App (OAuthApplication = UiPath), which is the default one, or you can register and use your own Azure app (OAuthApplication = Custom):

• UiPath Public App registration: The advantage of using the UiPath public app is that you do not need to configure or maintain the application.
  Note: UiPath does not store any user data. The authentication token is saved only on your machine or in your Orchestrator bucket. For more details, check UiPath Public App registration.
• Bring your own app (BYOA): The advantage of using your own application is that you can manage, customize, and assign permissions within your organization more granularly. For more details, check Custom OAuth Application registration - Bring your own app (BYOA).

UiPath Public App registration

The UiPath Public App is registered with the following information:

• Name: UiPathStudioO365App
• Client ID: f2f43f65-16a6-4319-91b6-d2a342a88744
• Scopes: Calendars.Read, Calendars.Read.Shared, Calendars.ReadWrite, Calendars.ReadWrite.Shared, Chat.ReadWrite, email, EWS.AccessAsUser.All, Files.Read, Files.Read.All, Files.ReadWrite, Files.ReadWrite.All, Group.Read.All, Group.ReadWrite.All, Mail.Read, Mail.Read.Shared, Mail.ReadWrite, Mail.ReadWrite.Shared, Mail.Send, Mail.Send.Shared, offline_access, openid, Presence.Read, Presence.Read.All, profile, Sites.Read.All, Sites.ReadWrite.All, User.Read, User.Read.All.

Custom OAuth Application registration - Bring your own app (BYOA)

This section explains how to create an application for the Microsoft 365 Scope connections.

Overview

To enable the Microsoft 365 classic activities, your application must:

• be integrated with the Microsoft identity platform.
• have the correct Microsoft Graph API permissions assigned to it.

After you register your Microsoft 365 application, Microsot Entra ID assigns a unique application (client) ID that you enter in the Microsoft 365 Scope activity along with the services you assigned permissions to, which are files, mail, and calendar.

Register your own application (BYOA)

Tip: This process is described in detail in the Microsoft documentation in Quickstart: Register an application with the Microsoft identity platform. However, the Microsoft user interface may have changed since these steps were first documented.

1. Sign into the Azure portal using your personal, work, or school Microsoft 365 account.
2. Select Microsoft Entra ID.
3. Select the Add button and, from the drop-down list, select App registration.
4. On the Register an application page, fill in the following fields Name, Supported account types, and Redirect URI (optional).
5. In the Name field, enter a name for your application.
6. Under Supported account types, select the option that applies to you:
   • Accounts in this organizational directory only (UiPath only - Single tenant) - use this option if your target audience is internal to your organization. This represents a single tenant application.
   • Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) - use this option if your target audience is business or educational customers. This represents a multitenant application.
   • Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox) - use this option to target the widest set of Microsoft identities. This represents a multitenant application.
   • Personal Microsoft accounts only

   For more information about which option to select, refer to Who can sign in to you app?

7. Under Redirect URI (optional), enter a URI address, if applicable. The Microsoft Authentication Library (MSAL.NET) uses a default redirect URI: https://login.microsoftonline.com/common/oauth2/nativeclient. This value will likely work for you when using the Interactive Token authentication type.
   • Your selection is dependent on your authentication type. For more details, check How to connect to Microsoft 365 activities).
   • In our example, the organization supports multi-tenant authentication, and can only use the Interactive token authentication type which requires a redirect URI.
     • If you use Interactive Token and the default Microsoft Redirect URI, you must add a platform of type Mobile and desktop applications. For more details, check Configure platform settings in the Microsoft documentation.
     • If your authentication type is Integrated Windows Authentication (IWA) or Username and Password, you do not need to register a redirect URI for your application. These flows do a round trip to the Microsoft identity platform v2.0 endpoint, and your application will not be called back on any specific URI.
   • When working with Microsoft 365 in a UiPath Studio project targeting .NET 5.0, add http://localhost to the Redirect URI of the applications you own.

     For more details, check Desktop app-registration in the Microsoft identity platform documentation.

8. Select Register, which redirects you to the Overview page of your registered application.

To complete the application configuration, you must also add API permissions to it.

Note: This setup is just an example. Therefore, you can make selections based on the policies of your organization.

Add API permissions

Note:

• Interactive Token authentication uses delegated permissions.
• Permissions can vary depending on the activity, since each activity includes the permissions it needs for its specific features.

After you register your application, add the necessary API permissions as follows:

1. In the Azure portal , go to your registered application.
2. Expand the Manage option, and select API permissions.
3. Select Add a permission, which opens the Request API permissions side panel.
4. Select Microsoft Graph, under the Microsoft APIs tab.
5. Select Delegated permissions to show the list of permissions.
   Note:

   • Delegated permissions are used with Interactive Token.
   • Application permissions are used with Application ID and secret.

   For more details on permission types, check Configure a client application to access web APIs in the Microsoft Azure documentation.

6. Use the search bar or scroll down the list and select the following permissions:
   Note:

   • Permissions can vary depending on the activity, since each activity includes the permissions it needs for its specific features.
   • These permissions are not all mandatory. The following list represents the complete set of permissions required to run all Microsoft 365 activities. You can restrict permissions depending on your particular use case. Check outthe activities documentation pages to learn what permissions they need.
   • Calendar
     • Calendars.Read
     • Calendars.ReadWrite
   • Files
     • Files.Read
     • Files.Read.All
     • Files.ReadWrite
     • Files.ReadWrite.All
   • Sites
     • Sites.Read.All
     • Sites.ReadWrite.All
   • Mail
     • Mail.Read
     • Mail.ReadWrite
     • Mail.Send
   • Users
     • User.Read
   • Shared - scopes required to access resources shared with the user, but not owned by them.
     • Mail.Read.Shared
     • Mail.ReadWrite.Shared
     • Mail.Send.Shared
     • Calendars.Read.Shared
     • Calendars.ReadWrite.Shared
7. Select Add permissions to return to your list of API permissions.
   
   

   

   
   
8. Make sure your API permissions include your added Calendars, Files, User, and Mail permissions.
   
   

   

   
   

Restrict an application to specific websites

If you want to control which websites your application can access, proceed as follows:

First, assign the Sites.Selected permission to your application:

1. In the Azure portal , go to your registered application.
2. Expand the Manage option, and select API permissions.
3. Select Add a permission, which opens the Request API permissions side panel.
4. Under the Microsoft APIs tab, select Microsoft Graph.
5. Select Application permissions.
6. Search for sites and expand the Sites drop-down menu to view all the available site permissions.
7. Add a checkmark next to the Sites.Selected permission, and then select Add permission.

Then, allow the application to access a particular website using APIs:

1. Go to the Microsoft Graph explorer.
2. Create an API of type GET. For example https://graph.microsoft.com/v1.0/sites?search=FPH_Test, where FPH_Test is the name of a SharePoint site.
   Figure 1. Microsoft Graph Explorer page with the GET API
   

   

   
   
3. Select Run query.
4. Copy the site ID 6c964666-500d-48e6-9ca6-84acee41c5b9,f955b6bc-9d48-4155-b1f5-e722d5cea1b5 from the response body and paste it into a document for later use.
   Figure 2. The GET API response body in Microsoft Graph Explorer
   

   

   
   
5. To allow the application to access this website, create another API, this time of type POST. For example https://graph/microsoft.com/v1.0/sites/0yxd4.sharepoint.com,6c964666-500d-48e6-9ca6-84acee41c5b9,f955b6bc-9d48-4155-b1f5-e722d5cea1b5/permissions, where 6c964666-500d-48e6-9ca6-84acee41c5b9,f955b6bc-9d48-4155-b1f5-e722d5cea1b5 is the site ID.
6. Since this is a POST API, enter the payload data in JSON format in the Request body. For example:

   {
   	"roles": [
   		"write"
   	],
   	"grantedToIdentities": [
   		{
   			"application": {
   				"id": "14dbd4c1-9ebf-47e8-c3f75bffed2d",
   				"displayName": "BOYA_Nisarg"
   			}
   		}
   	]
   }

   Note:

   • Make sure the payload contains the application name and ID.
   • You can find the app ID when you access the application in Azure, under Overview.
7. Select Run query. If the query was ran successfully, the message Created - 201 is shown.

To check which applications can access specific sites, change the API from POST to GET, remove the payload, keep same API, and run the query. You can find in the response body all applications that can access that specific site.