Hi @jkowalski,

As people reported in #2656, the current GDrive auth doesn't really work as the service account's quota is used instead of the user's. To fix this, we need to migrate to OAuth-based auth. I'm interested in taking on this work, but I'd like your review on this design.

We have two options in terms of grant scope:

• Use https://www.googleapis.com/auth/drive - Kopia will have all access to user's Drive files, which I'm not very comfortable with.
• Use https://www.googleapis.com/auth/drive.file - Kopia will have access to specific folders user has chosen, which is closer to the current model and more secure. I lean towards this option.

With drive.file scope, we need to ask the user to grant us access to one Drive folder. As far as my research goes, the only way is through the Drive File Picker API, which must be embedded in a web page. One way to do it is to run a temporary HTTP server for this.

The upside of this approach:

• The user selects a folder and grants us access in one go. It's slightly more streamlined than the current GDrive onboarding, where they need to create a service account on GCloud, share the folder on Drive, and then come onto the CLI.
• We can integrate this whole flow into the Kopia React app for UI users.

The downsides:

• repository create needs to show a link that the user needs to visit and interact with the Drive widget. If the user runs this command from a headless server behind a NAT, they may need to port-forward the server to their desktop. Alternatively, they can run repository create on a desktop and copy the files over. repository connect is unaffected.

Questions:

• Is it weird to run a HTTP server as part of repository create? Can you think of a better way through this?

Best,

xkxx