33

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)

Linda Lawton - DaImTo
  • 106,405
  • 32
  • 180
  • 449
Thomas
  • 4,208
  • 2
  • 29
  • 31
  • 4
    I'm voting to close this question as off-topic because it is about licensing or legal issues, not programming or software development. [See here](http://meta.stackoverflow.com/questions/274963/questions-about-licensing/274964#274964) and [here](http://meta.stackexchange.com/questions/139804/can-licensing-questions-ever-be-on-topic) for details, and the [help] for more. – JasonMArcher Jun 18 '15 at 19:15

2 Answers2

32

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.

Linda Lawton - DaImTo
  • 106,405
  • 32
  • 180
  • 449
  • 1
    Well, if by "help" you mean put a nail in the coffin of my hope for a good solution, then yes. Sigh, so that's the way it has to be. Thanks for the very good answer. – Thomas Jan 25 '15 at 20:37
  • Sorry. If it helps you are not the only one who has been bitten by this. I have had this chat with a few other. Any php plugins for WordPress hit this as well. – Linda Lawton - DaImTo Jan 25 '15 at 20:40
  • 1
    Google's own instructions for setting up Google Sign-in (https://developers.google.com/identity/sign-in/web/sign-in) direct you to put the client id in a tag, which means it is public. Obviously the client secret should not be placed in the code, but the client id is intended to be public, is it not? – reynoldsnlp May 13 '15 at 12:47
  • (sorry if this is old) I do not see an answer to bebop's comment. I do not understand why the Client ID is supposed to be "secret" since I can easily grab about any client id I want just by accessing the said site by clicking a "google sign in". It is right in the URL. It is impossible to hide!? Maybe I should start a new SO question specifically about this. – Bernard Jan 08 '16 at 16:15
  • @Bernard did you make a question? – Yasushi Shoji Dec 31 '16 at 14:38
4

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.]

Community
  • 1
  • 1
Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • The question speaks of Google Oauth. Which doesn't support what you are taking about. How does this answer the question? – Linda Lawton - DaImTo Jan 24 '15 at 15:22
  • The fact that there's no real difference between putting credentials in open source and in closed source is why I can't understand this policy. Either way you can extract and reuse it. – Thomas Jan 25 '15 at 20:32
  • 2
    It is slightly harder to pull them from closed source cq. binaries and apparently that is where Google draws the line; obfuscation techniques may help a bit too (though the policy does not speak of that); besides that, there is no good for native mobile apps alternative until Dynamic Client Registration comes along (that's why I think it makes sense to mention it...) – Hans Z. Jan 25 '15 at 20:39