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).___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
