steffres
steffres

Reputation: 240

Best practice to share google drive API credentials for being used by a script?

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:

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?

Upvotes: 2

Views: 580

Answers (1)

steffres
steffres

Reputation: 240

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.

Upvotes: 2

Related Questions