Can I really not ship open source with Client ID? [closed]

Question

Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.

(https://developers.google.com/terms/, my emphasis)

Does this mean that my Open Source Drive command line client needs to force every user of my software to set up a new project in the Google Cloud console? Is there a better option?

It's not like it's hard to extract client ID and client "secret" from non-opensource, so why the distinction?

"Install applications" client IDs and secrets aren't really secrets, and Google documentation seems to agree:

The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)

(https://developers.google.com/accounts/docs/OAuth2, again my emphasis)

Answer 1

On November 5th 2014 Google made some changes to the APIs terms of Service.

Like you I had an issue with the following line.

Asking developers to make reasonable efforts to keep their private keys private and not embed them in open source projects.

I have several open source projects on GitHub they are basically tutorials for using the Google APIs some of the APIs are still in beta and it takes time to get beta access. I had my client id imbedded in my projects to that my users would be able to test the applications out.

Now I have some contacts at Google so I was hoping I could get some kind of dispensation here. I managed to track down the author of the above offending change of service Dan Ciruli and sent him an email.

My email was quite log you can read it here: Changes of service

To make a long story short No you can't release your client id with your open source project here is Dan's email back to me explaining why.

You are, however, allowing them to “impersonate” you in Google’s eyes. If our abuse systems detect abuse (say, should someone try to DoS one of our services using your key), you run the risk that they would terminate your account because of it (and please note — they wouldn’t just cut access to the key, they would shut down your console account). Moreover, you’ve been granted whitelisted access to APIs that are not available to the general public (and, in all likelihood required agreeing to a separate Terms of Service) and are sharing access to anyone who wants it. There is no doubt that is a violation of those terms. Sorry to not have the answer you are looking for, but keys are the one way we have to tell who is calling our services.

That is just part of his email back to me. You can read the full post in the link above. So if you are giving them the source code and they can see the client id. Your users are going to have to create there own project on the Google Cloud console. There is no way around this.

I hope this helped.

Answer 2

There is a better option and it is called OAuth 2.0 Dynamic Client Registration. That is still a work in progress though: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dyn-reg-21 and it may take a while for Providers to adopt and implement it.

Edit:

It is categorically impossible to ship authentication secrets with an open source app. [Honestly, it really doesn't make sense to ship them with any app; it's just more immediately obvious with open source apps.]