Managing Google API key secrets

["Michael Terry" <mike mterry name>]

There was a previous thread about how GOA's keys are only intended for GNOME-core apps and that third party apps should use their own keys. But there was also some uncertainty around how to do that for Google, since Google's TOS requires that you not commit key secrets to an open git.

Here's a solution that worked for me. Hopefully it will be useful for third party app developers looking to migrate away from GOA and maybe could even let GOA stop having a public secret key.

tl;dr; Register and use an iOS client key, which allows for a login flow that doesn't need a secret key.

The main problem is: you need an API secret to log in, but Google won't let you commit that secret anywhere public. So what's an open source app supposed to do?

Well, Google admits that installed apps can't keep a secret. So they allow mobile apps to use an alternative login flow that does not require a secret. Though for some reason, the "Other" key type for installed apps (vs "Android" or "iOS") does *not* allow that flow. But unfortunately, "Other" is exactly the key type that a GNOME developer would naturally use.

But if you *do* register as a mobile app, Google will let you do a "Proof Key for Code Exchange" (PKCE pronounced pixy) which is just basically giving Google an arbitrary string that you create at runtime and then include in all your requests. And you need to run a localhost http server on an arbitraty port, to accept the access token from Google. If you do all this, Google won't require a client secret, just a client id, which _can_ be public.

Now, none of this prevents someone from stealing your client id and masquerading as your app... But :shrug: at least you're following TOS. And that's the same risk any mobile app is currently taking.

When you register an iOS key, they'll ask for an application ID - but you can just give it your appid like org.gnome.XXX - they don't confirm that it's registered with the iOS store or anything.

Registering as a mobile app _is_ a lie, but a white one. I feel like it's following the spirit of the law, at least.

Here's documentation from Google about this flow and how to use it: https://developers.google.com/identity/protocols/OAuth2InstalledApp

Another interesting tidbit from that page is that Google prefers that you send the user to the system browser for the consent screen, rather than loading it in-app in a GtkWebKit frame or whatever (presumably so that the user knows they're actually on a Google page and the app isn't phishing them for their Google password).