Authentication Types Used In Microsoft Office 365 Scope Activity

What are the Authentication types used in Microsoft Office 365 scope activity and share comparison of Attended vs. Unattended authentication types in Microsoft Office 365 scope activity?

Authentication Types

As an User

As an Application (run as background service)

Attended

Unattended

Unattended

(MFA enabled)

Details

Application ID & Certificate

X

X

X

Available starting with version 1.9.0. Very similar with Application Id and Secret, the only difference being the usage of a certificate as a secret instead of a client secret string.
See the official documentation for details:
Microsoft Office 365 Scope - Application Id and Certificate

Application ID & Secret

X

X

X

  • This authentication type it is recommended for:
    • Unattended executions.
    • When you want to access the Microsoft Graph API as an application (a background service / daemon) without a signed-in user.
  • How to:
    • Register a new app in Azure portal configured with appropriate application API permissions. When authenticating as an application (as opposed to with a user), you can't use delegated permissions - scopes that are granted by a user. You must use application permissions, also known as roles, that are granted by an admin for the application.
    • In O365 Scope activity the following parameters are mandatory: Application Id, ApplicationSecret and Tenant.
    • If Tenant is not set, you can get errors like "The token contains no permissions, or permissions can not be understood." (Multitenant) or "Application with identifier ...was not found in the directory 'microsoft.com'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant." (Single Tenant)
  • Important:
    • Some activities do not support this type of authentication (e.g. Find Meeting Times, For Each FileFolder)
    • For email activities it is mandatory to specify a value for the Account parameter (i.e. which mailbox of all tenant's mailboxes do you want to use).

Scope to specific mailboxes

When using this authentication type, the application has access to all mailboxes from your tenant!

That's because application API permission Mail.Read represents "Read mail in all mailboxes" and Mail.ReadWrite means "Read and write mail in all mailboxes".

It is possible to scope application permissions to specific mailboxes, so the application has access only to the specified mailboxes: Scoping application permissions to specific Exchange Online mailboxes

Scope to specific sites

Use Sites.Selected application permission to allow the application access to just specific SharePoint site collections rather than all.

See How to Use Microsoft Sharepoint Sites - Selected Application In Azure AD


Testing Microsoft SharePoint App Permissions

Integrated Windows Authentication (IWA)

X

X

  • It works only for federated users and if your registered Azure application is configured to support IWA.
  • It doesn't work for Multi-Factor Authentication (MFA).
  • Details: IWA on GitHub

Interactive Token

X

X

You have the option to register and use your own Azure AD app (i.e., OAuthApplication = Custom) or the one provided by UiPath (OAuthApplication = UiPath)

Username & Password

X

X

  • Not recommended, provided for legacy reasons (it goes against the principles of modern authentication).
  • It doesn't work for Multi-Factor Authentication (MFA).
  • Details: User & Password on GitHub

Few references: