1

I've taken over development of a Google Analytics API dashboard for a content management platform, and upgraded the code to use OAuth2 as the older oauth was disabled recently. The authentication flow and subsequent API calls are all working fine on my localhost for development.

The problem is when trying the code from a different domain. Google wants the redirect_uri to be whitelisted through the developer console, and if it isn't there, it throws Error: redirect_uri_mismatch

As this is a self-hosted (+ open source) package, people will be able of installing on their own servers, there is no way I'll be able of adding all possible redirect_uri values to the app key in the developer console.

After a bunch of Googling and trying to understand the docs, I get the impression there are 2 possible solutions.

  1. Instruct users to go to the Google Developer console, and to create an app key of their own, before also going through the OAuth2 flow within the distributed app to provide the code access to the data in Google Analytics.

  2. Use a redirect_uri value of urn:ietf:wg:oauth:2.0:oob with an Installed App key, instructing people to copy/paste the code back into the self-hosted app after authentication.

Neither of these are really appealing as it adds a bunch of complexity for the user (though option 2 sounds mostly doable). Are there other options, or am I simply overlooking something simple?

Linda Lawton - DaImTo
  • 106,405
  • 32
  • 180
  • 449
Mark Hamstra
  • 692
  • 1
  • 4
  • 16

1 Answers1

1

You actually don't have any choice in this matter. You must go with nr 1. When you state this is a dashboard and web application it leads me to believe this is some kind of scripting language. This means that the client id and client secret will be displayed to your users / customers. This is against googles terms of service.

Changes to the Google APIs Terms of Service
Asking developers to make reasonable efforts to keep their private keys private and not embed them in open source projects.

You may not release your client id and client secret to your users they are going to have to create there own. Which nicely solvers your redirect URI problem they have to make there own.

Further reading Can I really not ship open source with Client ID?

Community
  • 1
  • 1
Linda Lawton - DaImTo
  • 106,405
  • 32
  • 180
  • 449
  • That's interesting. According to https://developers.google.com/identity/protocols/OAuth2#installed it should be fine though with the "Installed Application" option? _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.)_ – Mark Hamstra May 20 '15 at 11:24
  • Installed applications are compiled applications. As in say a windows application using the api via a .exe file. No one will ever be able to see the client id and client secret in an installed application. But I think I will send some feed back on that that page isn't updated to the current terms of service. – Linda Lawton - DaImTo May 20 '15 at 11:29
  • You can read my email to Google on the subject of releasing this with open source projects and there response as to why we are not allowed to do this. http://www.daimto.com/changes-to-the-google-apis-terms-of-service/ – Linda Lawton - DaImTo May 20 '15 at 11:32
  • Thanks for the information DaimTo, really interesting. In this case, the package is in fact compiled to a special format before distribution (though arguably it's slightly easier to unpack than say an android app). When installed, the id and secret are available in the system configuration so people can set their own, with the existing values obfuscated. I will remove the values from the source code into a local build config so they're not in the VCS either. – Mark Hamstra May 20 '15 at 12:18
  • Sounds good just remove it from the configuration and instruct your users how to create there own. This solves your redirect URI issue nicely :) – Linda Lawton - DaImTo May 20 '15 at 12:32
  • @DalmTo "No one will ever be able to see the client id and client secret in an installed application" just FYI, that statement is not true. It's trivially easy to extract strings from client applications. I don't think that has much bearing on the rest of the discussion here though. Just thought I'd chime in with that tidbit. – Steve May 21 '15 at 02:59