0

In a nutshell: Shall I share oauth2-credentials in our source code with the scope of full write-access to a google drive from a dedicated single-purpose google-account?

so, I've written a python script which saves some data into either a pre-existing google-sheets file or creates a new google-sheets file into a given google drive folder (both of which are publicly editable for sharing purpose between teams).

For this I followed the steps and tutorials outlined by google and other sources whereafter I have obtained oauth2-credentials needed for my script to be authenticated with the google drive and google sheets API.

Those credentials are derived from a single-purpose google-account which I have created for this script.

Now I would like to share this script with other team-members but am unsure about how to proceed regarding the credentials; either:

A.) I would incorporate the suggested google workflow which would let the user of the script authenticate him/herself, i.e. the user starts the script, then is directed to the google-authentication weblogin, authenticates the script, and then the script would save and use those credentials of the user for writing data into a public google-sheets file (not necessarily a private one owned by the user).

This has the downsides that:

  • the user would trust my script with credentials which could enable it to read/write all of the data of the user's drive account. While I do not mean any harm of course, it still seems rather too much to ask and be responsible for
  • it breaks the intended straight-forward workflow of my script.
  • is not necessary at all technically, because the script shall only write into public sheets-files / drive folders; so why should it need write-access to all the user's drive files?.

B.) hardcode the credentials of our single-purpose account into the script; which has the only downside that when the script's source code would be shared, that anyone could obtain those credentials. But these credentials would only enable an attacker to write/read data into the account's google drive, but not take control over the whole account itself due to the limitations of the scope of the oauth2 credentials (I've used the "https://www.googleapis.com/auth/drive" scope). Additionally, as said before, we would only use the script to read/write data into public sheets-files which are owned by real google-accounts, so never would we use the drive of the single-purpose account and thus no attacker could destroy our data.

Thus, I am rather opting for option B, but I can't help the anxiety which comes from hardcoding publicly readable credentials...

What would you suggest?

|improve this question
  • If you don't mind to use shared account just use it and share it completely with users. If you need to keep track who made what changes you will need every user to use own account. Keep in mind when somebody will left company he will still be able to use that account. You say that attacker can not destroy your data. But he at least can make them inaccurate as he can write something you don't expect. Its not also clear if he can modify existing (not just destroy). – Fis May 23 '18 at 23:43
  • Hi Fis, thanks for your input. Actually, the shared account's drive data is never even written to or read from since this account was only created to get any kind of credentials which are needed to write into shared files by other users. So we always use our own shared drives and files but never the shared account's data. So even if someone would write/read/delete data from that account, we would never notice. Which makes it probably fine I guess. – onoSendai May 24 '18 at 9:46
  • What if someone uploads illegal content and makes it public from the shared account, you may be liable for that content – jrtapsell May 24 '18 at 17:14
  • Thank you @jrtapsell, that's indeed a possibility which I have not considered yet. We will take this into account. – onoSendai May 25 '18 at 9:57
0

We decided for option A: users need to create client_secret.json and credentials.json files themselves. It is unfortunately not the most straight forward, but the most secure one. Sharing credentials in a public repo is just a big no-go, no matter the details.

Also for the sake of completeness: another alternative would be to have our application running on a server where we could save the client_secret, so then a user would just be presented with a browser-popup where he/she would authorize our service.

But we don't follow that option either since the script shall only contain the core logic and it shall be a base for other to develop upon.

That's our motivation behind the decision.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.