To authenticate with Azure Active Directory, simply call one of the Microsoft365R client functions.
get_personal_onedrive()
get_business_onedrive()
get_personal_outlook()
get_business_outlook()
get_sharepoint_site()
get_team()Notice that you do not provide your username and password in the function call. Instead, Microsoft365R will use your Internet browser to obtain your credentials, in a similar manner to other web apps. You will get a dialog box asking for permission to access your information. Your login information is saved, so you should only have to authenticate once.
The default authentication method assumes that your R session can access the Internet via a browser. If this is not the case, for example if you are using Databricks or RStudio Server, you can switch to the device code flow by passing the auth_type="device_code" argument:
This will print an access code and URL on the screen. You login to the URL using a browser on another device, and type in the code. Once this is done, Microsoft365R will complete the authentication process. Again, you do not provide your username and password in the function call.
When authenticating to the Microsoft 365 Business services, Microsoft365R will detect your Azure Active Directory tenant from your logged-in credentials in the browser. Sometimes this doesn’t work, in particular if you are logged in with a personal account that is also a guest account in a tenant. To solve this, specify your tenant name with the tenant argument:
Microsoft365R comes with a default app registration for authenticating with AAD; depending on your organisation’s security policy, you may have to get an admin to grant it access to your tenant. See app_registration.md for details on the permissions that Microsoft365R requires.
Rather than getting the default app registration approved, you can also create your own registration for authentication. If this is for use in a local R session, it should have a mobile & desktop redirect URI of https://localhost:1410 (not a web or SPA redirect), and the “Allow native client” setting should be enabled. You can use the same permissions as the default app, or set your own: for example, if you know you don’t need to interact with Outlook, you can omit the Mail.Send and Mail.ReadWrite permissions.
Once the app has been registered, you can pass the app ID to Microsoft365R in a couple of ways.
The client functions can accept the app ID as the app argument:
Alternatively, if the environment variable CLIMICROSOFT365_AADAPPID is set, Microsoft365R will use its value as the app ID for authenticating to the Microsoft 365 Business services (Teams, SharePoint and OneDrive for Business). This environment variable is defined by the CLI for Microsoft365, an open source tool for managing Microsoft 365 accounts; you thus can reuse the same app ID for both the CLI and Microsoft365R.
If you want to use Microsoft365R outside a local R session, creating a custom app registration is required. In particular, this includes the following common scenarios:
See the vignettes “Using Microsoft365R in a Shiny app” and “Using Microsoft365R in an unattended script” for more on these use cases, including how to configure the app registration in Azure Active Directory.
The above methods are the recommended solutions to dealing with access restrictions on Microsoft365R. If they are not feasible, it’s possible to work around these issues by piggybacking on other apps:
By setting the R option microsoft365r_use_cli_app_id to a non-NULL value, Microsoft365R will authenticate using the app ID for the CLI for Microsoft 365—effectively pretending to be the CLI itself. Technically this app still requires admin approval, but it is in widespread use and is maintained by Microsoft employees, and so may already be allowed in your organisation. The CLI supports most Microsoft 365 services, but not Outlook or personal OneDrive.
You can authenticate using the Azure CLI’s app ID: 04b07795-8ddb-461a-bbee-02f9e1bf7b46. This is a first-party Microsoft app, and hence can be used in any tenant. It is not intended for use with Microsoft 365, so not all functionality may be supported; however it should be possible to access Teams and SharePoint sites (but not Outlook, personal OneDrive or OneDrive for Business).
Be warned that these workarounds may draw the attention of your admin!
In some circumstances, it may be desirable to carry out authentication/authorization as a separate step prior to making requests to the Microsoft 365 REST API. This holds in a Shiny app, for example, since only the UI part can talk to the browser while the server part does the rest of the work. Another scenario is if the refresh token lifetime set by your org is too short, so that the token expires in between R sessions. In this case, you can authenticate by obtaining a new token with AzureAuth::get_azure_token, and passing the token object to the client function.
When calling get_azure_token, the scopes you should use are those given in the scopes argument for each client function, and the API host is https://graph.microsoft.com/. The Microsoft365R internal app ID is d44a05d5-c6a5-4bbb-82d2-443123722380, while that for the CLI for Microsoft 365 is 31359c7f-bd7e-475c-86db-fdb8c937548e. As noted above, however, these app IDs only work for a local R session; you must create your own app registration if you want to use the package inside a Shiny app.
# authenticating separately to working with the MS365 API
scopes <- c(
"https://graph.microsoft.com/Files.ReadWrite.All",
"https://graph.microsoft.com/User.Read",
"openid", "offline_access"
)
app <- "d44a05d5-c6a5-4bbb-82d2-443123722380" # for local use only
token <- AzureAuth::get_azure_token(scopes, "mytenant", app, version=2)
od <- get_business_onedrive(token=token)The AzureR packages save your login sessions so that you don’t need to reauthenticate each time. If you’re experiencing authentication failures, you can try clearing the saved data by running the following code:
You can also consult the vignettes from the AzureAuth and AzureGraph packages for more information on this topic.