Document API-backed mobile app workflow

[DavidJFelix]

I'm opening this issue to begin discussing mobile app flow for google oauth2, which I feel is either under-documented or unsupported (and needs to be documented as unsupported).

Problem:

This library calls for both a client_id and client_secret with no mention of how to work without a client_secret. When generating a Oauth client ID in the google developer console, neither iOS app nor Android app generate a client secret.

Scenario:

Ueberauth is used for an API that backs an android app. Google sign-in is added to the app. Following the android documentation this will bring up native components rather than using a web-redirect flow. This is still a valid oauth scenario and something which an API could potentially desire.

I've manually implemented this auth flow in Python previously, and I'd be happy to help if there is development effort needed here.

[tsubery]

If I understand your use case correctly, this repository is not what you are looking for. If you don't have client_secret it means you can't use oauth callbacks to trade code for a token. This is basically what this library does.

If you have a valid access token acquired by other means and you just need to use it to communicate with google, oauth2 library allows you to do that.

[DavidJFelix]

@tsubery I'm pretty sure you can trade the code for a token, which is what the documentation I linked shows. It seems odd for such a modern use case to be unsupported by any strategy here. Neither the iOS nor Android clients for google sign in provide client secret because google does not expect a package code to be secret, so they manage client secret by requiring you to declare your package signing fingerprint when registering a library-based client.

I would say that if an Oauth library claiming integration with providers like google doesn't work with the documented way of handling google sign in for mobile devices, it should be outlined that this only works with a web flow. This "issue" is over the documentation. I'm pretty neutral to whether or not this library ought to support mobile login flows, but if it doesn't there should be a call out, especially since web flow on a mobile device will expose a the client_secret and really isn't the way that this should be implemented.

[tsubery]

@DavidJFelix This repo is definitely not a general purpose Oauth library. This repo is just a plugin for ueberauth that implements some parts of Oauth. Seems like your complaint has more to do with Ueberauth featureset or documentation than this particular strategy. This discussion might be relevant to your issue.