Setting up OneDrive (personal)

Thanks for the explanation. It does clarify a few things for me, though I think I still need to read up on a few things to really understand. I guess that the main thing that I don’t understand is why Duplicati itself doesn’t contain the functionality offered by the auth-handler service. The option to run a custom (trusted) version is interesting and would solve the issue, but it may go too far for me at this time.

I suppose that for me, for now, it means that backing up to OneDrive is not a viable option without requiring a lot more effort, meaning that it is most likely easier to find a different cloud solution. I will have to weigh some pros and cons against each other again.

That is due to the design of the OAuth protocol. It is not a great fit for solutions that does not have a web-based user interface (i.e. anything that is not a web page).

It is trivial to write the OAuth handler in C# or just bundle the Python version with Duplicati. But for it to work it needs the “application secret”, which is a secret value obtained when signing up as a third-party provider. Any communication with OneDrive needs the “application secret” or it will be rejected. The provider (Microsoft in this case) uses this to revoke access to applications that are not compliant with their ToS.

If I were to ship the “application secret” with Duplicati, it would be publicly visible and hence not a secret. This would allow anyone to pretend to be Duplicati and impersonate requests. Once this happened, Microsoft would revoke the token, causing all Duplicati users to loose access.

The reason why I am not shipping the OAuth handler with Duplicati is because it is useless without an “application secret”.

To get that part you sign up as a third-party application with Microsoft, approve the ToS, set up an application, and then enter the “application secret” locally into the service. For most users this setup would be too much of a hassle.

Aaah ok, I think I see what you mean now…

It would appear that I either need to get over my ‘trust issues’ or stay with a different storage provider then. Thank you for answering my questions!

There are still numerous Storage Providers not seen on Duplicati OAuth Handler screen.

Not all OAuth server uses are the same, for example Google Drive (limited) login
scope limits Duplicati to files it made. It can’t see others. It lowers risk, but is confusing…

An Illustrated Guide to OAuth and OpenID Connect first 11 minutes shows some basics.

@kenkendk
This thread was a real eye-opener for me. I appreciate the transparency on security in this thread, and IMO this information is important and needs to be much more widely available than it is buried here.
The fact that Duplicati is not 100% E2EE/ZK – when OAuth is involved – was a total surprise to me and is a big deal from a security point of view. I think it needs to be spelled out very clearly in the core documentation.
Yes the Duplicati documentation doesn’t say that Duplicati is E2EE/ZK (as far as I can tell), but anyone reading the documentation would assume it is, given that Duplicati is positioned as software running on the user’s computer. Nowhere is there any (obvious enough) mention that it doesn’t run entirely on the user’s computer.
This also raises the important question: are there any other components of the backup functionality (other than the OAuth handler mentioned in this thread) that runs in the cloud (i.e., anywhere else than on the user’s computer)?
I love Duplicati and have found it very functional and reliable, but I have to admit that my love is a bit less enthusiastic now that I know it’s not E2EE/ZK - especially since I only found that out because I just happened to read this forum thread.
.
Can I make some “wish list”-type suggestions for changes to the Duplicati.com website content and the help pages (readthedocs.io)? (My apologies if some of this exists but I didn’t find it.)

  1. The “How we get along with OAuth” page talks about a “service” that handles OAuth. But reading this, a user would assume (at least I did) that this service was running on my own computer, like the rest of the Duplicati software, which is in fact running as a service. It’s critical from a security point of view to make it very clear that the OAuth handler service is actually running in the cloud.
  2. There should be a new help page that describes Duplicati’s security and security model and all issues like the above.
    • The new page would describe that everything runs on the user’s computer, except for X, Y, and Z which run in the cloud. (E.g., X = OAuth for One Drive and some other services)
    • It would list all the storage providers that depend on something running in the cloud, and for each one would list what is the thing running in the cloud. (E.g., OneDrive: OAuth handler service running in Google App Engine)
    • It would describe all the security measures you’ve taken to protect the cloud OAuth handler service, and would list the risks that you can’t do anything about (residual risks).
    • It would explicitly describe how Duplicati is E2EE/ZK unless the storage provider needs any of those X, Y, and Z things. (Or maybe some of the Y and Z don’t affect E2EE/ZK-ness or any other security aspect?)
    • It would point to the “How we get along with OAuth” page, and to the “Duplicati OAuth Handler” page.
  3. There should be a short blurb on the Duplicati.com main page that talks about security and links to the new help page I suggested. The existing “Strong encryption” blurb could be replaced with something like “Strong security” and this new blub.

I think this is not a correct interpretation. Duplicati performs all encryption client-side and is treating any remote storage service as a “bucket of encrypted blobs”. In my view that is a 100% compliance to TNO or EE2E/ZK.

No. The system designed is made so there is minimal need for service maintenance by me. The OAuth service was added because all the storage providers want to prevent users storing their real account credentials in third-party applications, and because the OAuth design is not ideal for a client-only application such as Duplicati.

There are two other pieces to the Duplicati service eco-system: logging and updates. Each of these run separately and have no impact on backups. Both can be disabled completely.

Just to make it clear: the OAuth service is an unwanted necessity that ensures that your real username/password is newer exposed to Duplicati. The OAuth setup essentially swaps your username/password with a token that has limited permissions. This ensures that you can revoke any access to Duplicati and that the service provider can disable Duplicati if they deem it necessary.

The need for the OAuth service arises because the authentication returns two tokens: access token and refresh token. The access token can be used directly instead of username/password but expires “quickly” (typically 4 hours). The refresh token is used to obtain a new access token, but requires the presence of the application secret (mentioned previously in this thread).

This has two important implications:

  • Anyone with a valid access token can access the same files as Duplicati
  • If the OAuth service breaks, backups cannot start

To limit the possibility of the first implication, everything stored in the OAuth service is encrypted with the AuthID.

The second implication is not mitigated. Once PATs are more generally in use, we can retire the OAuth service.

To sum up: the OAuth service does not see any files or operations performed on the storage. A compromised OAuth token allows an attacker to perform the same remote file operations as Duplicati (list, put, get, delete). Any operations are executed by the client; the OAuth service does not interact with the storage in any way.

We wrote the “How we get along with OAuth” page with the exact intention of describing the security implications, as the rest of Duplicati works without any external service.

If you have specific changes that you request, you can make a pull request for the main site.

Settings in Duplicati mentions (probably less sensitive) updates and usage reports (even prints URL).

Any OAuth issue is only relevant to OAuth. In AuthID setup you can see URL and read privacy policy:

Not everyone pays attention to the URL they are at, or reads privacy policy (which does get technical).

Duplicati OAuth Service Privacy Policy =

This document describes what information the Duplicati OAuth service collects, how it is used, how and where it is stored, whom it is shared with, and how you can remove the stored information.

== How we use your data ==
The Duplicati OAuth service attempts to collect and store as little information as possible. When you connect to any of the supported OAuth providers, Duplicati obtains a long-term session key. This key, combined with a secret known only to the Duplicati OAuth service, can be exchanged for a short-term key, which can be used to access your account on the site that you have authenticated with.

== How we store your data ==
To avoid transmitting the long-term session key, we store the long-term session key. To prevent unwanted access to your account, we encrypt the long-term session key with a password before we store it. This password is given to you in the form of an “AuthID” string. It is not possible to recover the long-term session key without this password, meaning it is only possible to intercept this key during a login (and shortly after, as the key is briefly kept in cache). Due to the way OAuth is constructed, we do not have access to, and thus do not store, any personally identifiable information. This includes not storing username, email or password to the authenticating site.

== Where we store and handle your data ==
The data is stored on Google App Engine, using their scalable storage and server infrastructure. As part of using GAE we are storing log information that shows IP addresses and some request information. This data is stored for a short period, as the amount of data is quite large, and new data overwrites existing data.

== Who we share your data with ==
As part of the login process, we send the long-term session token to the provider who issued it (after it has been decrypted with the client-provided key). The resulting short-term session key is sent directly to the requesting client, and not stored on the server.

Apart from this exchange of secrets, we do not share your information with anyone. This is enforced since we do not store any information that we could share, except from the log data as described above. Please note that as the service is running on GAE, Google will also have access to the log data.

== How to remove the stored information ==
You can remove a stored “AuthID” at any time by providing the “AuthID” you want to remove to the removal page, listed on the website. Removal is performed immediately and irrevocably.

If you do not have the AuthID, we cannot remove the information, but since it is encrypted it is not accessible by anyone either.

To ensure that permissions are revoked, you can also use the site you are authenticating with, and revoke access by Duplicati. This will permanently invalidate all the stored (and encrypted) long-term session tokens on the Duplicati OAuth service.

Logins that have not been used for a long period of time are automatically removed.

I suppose OAuth service’s blurb could say “cloud service”. There’s probably an update coming soon.
The manual is a third-party project. Its maintainer seems to be short on time but invites pull requests.
Duplicati is a community effort, and is entirely limited by the volunteers who support it with their time.

Anybody who appreciates the benefits that sometimes only non-commercial works offer, please help.
Almost anybody can contribute their skills to some area (even forum), even if they’re not a developer.

@kenkendk and @ts678:
Thanks for your detailed reply, and thanks for the Duplicati OAuth Service privacy policy (which I had not noticed), respectively.
My apologies, I should have thought about the security model a lot more before my previous post.
It’s now clear to me that the data transferred by the Duplicati client software to/from the cloud storage provider is in fact E2EE, because the encryption key never leaves my computer.

I can only think of one other question:
If an attacker completely compromises the Duplicati OAuth Service, and observes my client’s interactions with it, will that give the attacker access to all the other files stored in my cloud service, i.e., the files not managed by Duplicati?
If the access token limits the directory path scope to only Duplicati’s files, could the attacker request a different token to get access to the full contents of the cloud account?

That is service dependent.

To limit the impacts of this attack vector, I set up each integration so that it has the minimal permissions possible. For Dropbox this is set to scoped access so only files in the Duplicati folder is accessible to Duplicati. You can verify this by viewing the Dropbox app permissions on your profile. It should say:

  • Edit content of your Dropbox files and folders, view content of your Dropbox files and folders, and view and edit information about your Dropbox files and folders, only within the Apps › Duplicati backup folder
  • View and manage your Dropbox file requests, Dropbox sharing settings and collaborators, and manually added Dropbox contacts, only within the Apps › Duplicati backup folder
  • View basic information about your Dropbox account such as your username, email, and country

This means an attacker that obtains your refresh token and the Duplicati application secret will be able to interact with all Duplicati stored data, but not your other Dropbox contents.

NOTE: If you have a previously issued AuthID for Dropbox (aka a long-term token), it may have more access as the scoped access is a newer feature.

For Google Drive you can choose the “limited” option when logging in. This will make Duplicati able to access only files created by Duplicati, similar to the Dropbox scoped access. Unfortunately, this does not always work as certain interactions cause Google Drive to mark the files as owned by the user, which makes them invisible to Duplicati. Because of this, there is also a “full access” option which should only be used for recovery.

For the other services, make sure you look at the permissions granted when creating the AuthID to understand the security implications.

No. The token is issued with only the limited permissions and cannot be upgraded. I would have to change the Duplicati Dropbox-app settings, have it approved by Dropbox, and then each user would need to re-authorize before more access can be given.

Thanks. OneDrive is the storage service I’m using. I went through the re-auth process (3 times, to make sure I didn’t miss anything) but the workflow did not display any information about permissions.

I then went to the “Apps and services you’ve given access” page for my Microsoft account, and under Duplicati it says:

Access OneDrive files
Duplicati will be able to open and edit OneDrive files, including files shared with you.

So I’m guessing this means that the token Duplicati has for my OneDrive gives full access to all files in my OneDrive, not just to Duplicati’s files?

Yes, I think so. If there are ways to limit access in OneDrive let me know and I will try to get it fixed.

I have no experience at all with the OneDrive API, but it looks like “app special folders” might be the answer:

Understanding OneDrive API permission scopes - OneDrive dev center | Microsoft Docs

The Files.ReadWrite.AppFolder delegated permission is only valid for personal accounts and is used for accessing the App Root special folder with the OneDrive Get special folder Microsoft Graph API.

The two pages linked in the blockquote appear to provide all the info you’d need to restrict Duplicati’s access to only files and folders in the Duplicati app folder in a user’s personal OneDrive.

Update: I’m assuming that the OAuth request to the user would be restricted to this app special folder, but I didn’t verify this.

@ kenkendk
I just want to make sure you noticed this for the big to-do list…

@kenkendk
I want to make sure you noticed this for the big to-do list…

The official big to-do list is GitHub Issues. 849 open issues at the moment, many probably outdated.
You can always park something there to get it on record, but Duplicati needs many more volunteers.

Thanks. I’ve done s/w dev but this might be beyond my abilities. I’ll try to do some more research into the how-to, though.

In case it wasn’t clear, opening an issue requires no particular abilities beyond (ideally) good writing.
Actually getting issues resolved is where resource limits hit. Help anywhere on Duplicati is welcome.

Sorry if this has already been asked and answered as its a long thread.
If I have multiple PC’s with Duplicati all backing up to the same 1TB Onedrive (personal) account just different folders eg OneDrive Folders:
Duplicati/PC1
Duclicati/PC2
Duplicati/PC3
And have setup and recorded the Duplicati OAuth ID key for Duplicati/PC1 can I just use the same key when setting up Duplicati on PC2 & PC3 or do I need a new Duplicati OAuth ID key for each device for their created folder?
Note: None of these PC’s will be logged in with a Microsoft account if that matters, all will be local administrator accounts. Thanks in advance for any help.

Welcome to the forum @cms1303

One AuthID should work for any PC and any folder. It’s only associated with the (one) account.

Thankyou I shall give it a try in the next week