To authenticate with Azure Active Directory, simply call one of the Microsoft365R client functions.
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
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
For authentication purposes, the package is registered as an app in the ‘aicatr’ AAD tenant; 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 app, including the permissions it requires.
Rather than getting the Microsoft365R app approved, you can also use your own app registration for authentication. If you want to use the default authorization code flow, the app registration should have a redirect URI of
https://localhost:1410, and if you want to use the device code flow, the “Allow native client” setting should be enabled. It should also have the same default permissions as the Microsoft365R app (see above).
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
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.
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!
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: