Sign in/up with 3rd party ONLY?

Being unable to create or sign on to oDrive with user accounts that are not based on a 3rd party is a big concern.

As it stands some of our stuff is in Google Drive, some in OneDrive and some in Dropbox and we want to eliminate having files stored and sharing being done in a bunch of different places. Using accounts they setup themselves.

We don’t want that happening any more. We don’t want them using those services/accounts. We want them to each have an oDrive account connected to a single cloud storage server.

With this new “single sign-on” actually means we end up with MULTIPLE sign-on. You have to sign-on to Dropbox or Google or OneDrive et cetera to sign on to oDrive to connect to the cloud storage server.

It really sucks. Because I fell in love with oDrive and it’s features and functionality. And I guess oDrive misses out on roughly 15 pro subscriptions — as of today. It’ll be closer to 50 this time next year.


Thanks for reaching out.

Can you explain a little bit more on what you are wanting to accomplish?

Generally speaking, a user will need to authorize at least one cloud storage provider (using OAuth) to link storage to odrive, unless they are only using something like WebDAV, FTP, or SFTP. We streamline that process so that you login with odrive using the account you first linked.

Is your goal to try to prevent users from linking other storage accounts and mandating only using a single storage service, like Google Drive? If so, are you providing them with the account?

1 Like

Yes! Something to that effect.

The idea is we want to setup a Google Drive or say… WebDAV or BackBlaze B2 or ADrive — one storage server.

And then as admin of the oDrive organization, I want to be able to setup an oDrive account for each team member and then link that single storage service — so all company files and such are stored in one centralized location and all sharing or syncing or editing/uploading/downloading by team members occurs within oDrive.

This is to avoid commingling their personal (DB, G+, OD, et cetera) accounts with business accounts. I want oDrive to be their business account.

That way users can ONLY access/edit/add within the storage ‘buckets’ or ‘folders’ they are allowed to access but can create sharing links for people outside the company.

Because if they have to login with their Dropbox account — some of them my start saving files into Dropbox and creating share invites and share links within that. Then the file is stored in that location — not within the company cloud server/service


These types of team-oriented storage management features are aligned with what we have planned as part of Org:

We should be moving on these within the next few months, so keep an eye on our Announcements.

Thanks for the feedback!

Well… think about this for example…

What if someone just wanted to setup an odrive personal account — but does not have a Dropbox, Google, Amazon, Microsoft, Facebook or OneDrive Business account? Yes… I realize they’re probably living in a small hut or a bunker somewhere with a tinfoil hat, a huge can of baked beans and enough armaments to take on Bolivia… but for arguments sake… even if they did have those accounts, but did not want to connect or use that service to access yours?

You said that you have to link at least one cloud storage to use odrive — what if they are using Adrive or WebDAV or BackBlaze or Yandex or S3[1] or some other storage service or protocol only?

OAuth is nice for connecting one service to another service should you choose to — but to eliminate traditional user accounts completely is not cool. Not. Cool. Dudes. :smirk:

Which is. shame, because you have created a really slick service with a great feature set and a very nice a clean UI.

[1] your Amazon S3 really needs people to allow to specify the host URL — not all S3 servers are actually from Amazon themselves — DreamObjects from Dreamhost for example

Thanks, again, for the feedback. I definitely understand where you are coming from, and I don’t disagree that there is a valid argument for managing unique credentials for odrive.

The thinking behind the current implementation is is that almost everyone will already have one of the accounts we offer. They have already, presumably, vetted the service and trust it with their credentials, adding 2 factor auth, etc.

Using OAuth means we never see the credentials you use for signing into odrive. It prevents yet another username and password for the user to manage and has the added benefit of simplifying initial linking of your account, as you can immediately start using odrive after a one-step sign-up.

This doesn’t cover all cases, of course, but it does cover a very large majority and simplifies a great many things. I see the attraction of having odrive offer it own account login method. It would make managing a multi-user setup easier, much like using Google for Worx, AWS, Dropbox for Biz, etc. Or, as you mention, for people who don’t use Google, Amazon, Dropbox, Microsoft, Amazon, or Facebook (let’s leave aside whether such folks would need cloud storage anyway).

My preference is that odrive not support non-OAuth logins. Odrive is a powerful tool, giving access to a wide variety of cloud providers under a single interface. As such, it also poses a potentially huge security risk. Break into odrive and all your connected cloud accounts are open for harvesting. I prefer that the odrive devs stay focussed on what they excel at - building a provider agnostic sync tool - rather than expanding odrive’s attack surface dramatically by managing account logins as well.