OneDrive token configuration failure

rclone v1.50.2

  • os/arch: linux/amd64
  • go version: go1.13.4

I followed the instructions for configuring a Onedrive for Business endpoint, but the acquisition of the access token fails.
The browser shows the following link in the address bar:

If I can hazard a guess, this seems to indicate that rclone config (or rclone authorize) tries to obtain the OAuth token using a URL referring to the common endpoint which appears to be not the endpoint expected by Azure, i.e. as in<Directory (tenant) ID>/oauth2/token

Did I do something wrong?

A bit of searching brings up this stack overflow answer - can you try that?

Can you post the rclone config session too please so I can see what you typed (obscure any secrets) - thanks.

I did see that SO answer but I do not think it provides any help, because what it suggests refers to something that the application does and I don't think I have any control on that.

Anyway, the problem can be reproduced with:
rclone authorize "onedrive" "d9ebbc9f-cffe-471a-9013-31917c25bddc" "<client secret>"
(The is the one generated on the Azure site, where I registered the rclone Web app, as per instructions).

This launches the browser and, after a second or so, I get the failure.

As I mentioned in my first post, it looks as if the endpoint (as MS seems to call the URL to access the OAuth API) now requires the Tenant Id (which one can glean from the Azure site where one gets the application id and client secret).
Should I perhaps register the rclone app as a multi-tenanted app? Or can I specify the Tenant Id somewhere in the configuration?

I think that is what the error message is suggesting.

Is this a new thing do you think?

Does the standard rclone build in app (leaving client_id and client_secret blank) not work?

There isn't an option for that at the moment. I expect one could be added though.

Good news: it seems it may only be a matter of updating the documentation for OneDrive configuration, in particular in the "Getting your own Client ID and Key" section. Here's the story.

I had another go at registering the app as multi-tenanted, which I tried yesterday without success.
Just for reference, this is done by choosing Authentication under the Manage heading in the left panel in Azure App Registration (where you have to go to get the Application (client) ID and the Client Secret). Then scroll down and, under "Supported account types", choose "Accounts in any organizational directory (Any Azure AD directory - Multitenant)".
Then make sure to click on Save at the top, once you're done.
The reason it did not work the first time has to do with the cookies. To make it work I had to remove the cookies for in the default browser (Firefox, for me).
After these steps, rclone config managed to get the token successfully (after I gave permission for rclone to access data, etc.).
I verified that things work by running "rclone lsd remote:" which listed the content of the top directory of my repository.

Finally, I do not know if this is a new thing that affects everyone or just a change that was enforced by the administrators of the specific instance of "OneDrive for Business" I am using.
It seems nobody else has raised a similar issue so far.
Maybe one could add to the documentation that "some users reported that the app must be configured as multi-tenanted" and explain how to do that.

The only concern I have is whether I introduced some security issues by configuring the app as multi-tenanted. I don't think I did, because the access is still gated by the "Client Secret", but I do not know enough about MS Azure security model to be sure.

By the way, thanks for developing this very useful tool!


I don't know either. I do know that the Microsoft authentication is very configurable and can get very complicated!

Do you fancy sending an update to about that? Either send a pull request or write some suggested text here and I'll paste it in.

The client_id and client_secret are really just a way for Onedrive to identify the client software. All the authentication is done when you do the token exchange in the browser. So if your client_id and client_secret was leaked then people would be able to impersonate your client, but not read any of your data.

You are welcome!

Today when I checked the steps for the app registration in preparation for the Pull Request we discussed, I realized that rclone config works seamlessly if I use blank "Microsoft App Client Id" and "Microsoft App Client Secret".
I could have sworn I tried that.
So, it seems that there is no need to go through the rigmarole of registering the app on Azure, after all (at least in my case) and there is no need to change the documentation.
Sorry for creating noise

Ah! Perhaps we need something about that in the docs?

In fairness, the docs do not say that one has to get an App Id and a Client Secret.
In my case, I ended up doing that after using rclone after a hiatus of a few months and seeing the application fail, complaining about expired credentials. When I set about obtaining new credentials, I can't remember exactly what I did, but it failed.
So I thought that the reason for the failure was that I was supposed to follow the instructions in the "Getting your own Client ID and Key" (and then I stumbled on the single-tenanted v. multi-tenanted).
But in fact if one deletes the remote with the expired credentials and recreates it from scratch, rclone config works with the default blank App Id and Client Secret (and there is no need to mess around with registering the app, etc.).
Perhaps the only clarification that the documentation needs is that the "Getting your own Client ID and Key" section is relevant only if the blanks defaults do not work or if the throttling issues are observed.
Also, also in Item 2 of that section, "choose your account type" sounds unclear to me. Here, in my experience, one must choose the "Multi-tenanted" option.
But my knowledge of Authentication techniques is rudimentary at best, so I am hesitant to make recommendations of general applicability.

What do you think?

I think that sounds like a useful change.

I propose changing the section to this - what do you think?

Getting your own Client ID and Key

You can use your own Client ID if the default (client_id left blank)
one doesn't work for you or you see lots of throttling. The default
Client ID and Key is shared by all rclone users when performing

If you are having problems with them (E.g., seeing a lot of throttling), you can get your own
Client ID and Key by following the steps below:

  1. Open, then click New registration.
  2. Enter a name for your app, choose account type Any Azure AD directory - Multitenant, select Web in Redirect URI Enter http://localhost:53682/ and click Register. Copy and keep the Application (client) ID under the app name for later use.
  3. Under manage select Certificates & secrets, click New client secret. Copy and keep that secret for later use.
  4. Under manage select API permissions, click Add a permission and select Microsoft Graph then select delegated permissions.
  5. Search and select the follwing permssions: Files.Read, Files.ReadWrite, Files.Read.All, Files.ReadWrite.All, offline_access, User.Read. Once selected click Add permissions at the bottom.

Now the application is complete. Run rclone config to create or edit a OneDrive remote.
Supply the app ID and password as Client ID and Secret, respectively. rclone will walk you through the remaining steps.

Sounds good to me!

I merged those changes - they will go live when 1.51 is released

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.