google oauth from installed clients (ios/android) fails in authorization code exchange for access token

[nsolter]

The standard oauth2 authentication process via the accounts-google and google packages requires the user to authenticate in the client, which triggers a redirect call to the server with a one-time authorization code. The server then makes a call to https://accounts.google.com/o/oauth2/token with a grant_type of authorization_code to exchange the authorization code for an access_token and refresh_token. This works fine because the client and the server are using the same Google client id.

However, when authenticating on an installed client (such as an ios or android app), the client needs a separate "installedClient" Google client id, which is different from the server's client id. In this case, the authorization code exchange call is required to NOT specify a redirect_uri, or the call fails with "redirect_uri_mismatch" (see https://developers.google.com/identity/protocols/CrossClientAuth#offlineAccess). Unfortunately, the exchange call when the client and server are the same does require the redirect_uri be specified. Thus, that argument must be conditional depending on whether the client is an installed client or the web client.

The solution I'm using in my project requires coordination between the installed client and the server via an extra "installedClient" parameter that's passed in the first oauth redirect call (the one containing the authentication code). This approach allows the standard meteor web client to work without change. The diff is here: emmerge@bd20524 This works because in the installed client case the first redirect back from google goes back to the app, not to the server like in the web client case. Then, the client turns around and manually makes the _oauth/google "redirect" call to the server, passing the extra installedClient argument.

[martijnwalraven]

Thanks for opening this issue and describing your solution. Improving OAuth authentication on mobile apps is something I hope to work on after the Meteor 1.2 release. It seems to me we'd ideally want to solve this in a more general manner, which probably involves supporting the native login flow (such as Google Sign-In). Would that also work for your use case?

[nsolter]

@martijnwalraven, thanks for looking into this. On the client side I am using the Google Sign-In flow for ios described in https://developers.google.com/identity/sign-in/ios/offline-access and https://developers.google.com/identity/sign-in/ios/sign-in#enable_sign-in . Is that what you meant by the native login flow? The problem with meteor only arises in the server exchange of the authentication code obtained in this way for an access token.

[martijnwalraven]

Ah, it wasn't clear to me you were using Google Sign-In. That's indeed what I meant by native login flow. It's been a while since I looked into the Google authentication mechanisms, so thanks for the links. I won't be able to work on this immediately, but I'll get back to you when I do.

[nsolter]

OK, no problem. I'm happy to help with design and coding of a general-purpose solution here.

[barzhomi]

Hello everyone. I've found a solution how to get an access_token on iOS and Android devices without additional server, please have a look on my comment here https://stackoverflow.com/a/44706474/5023697

More likely it is already useless for reporter but maybe it saves the time for someone who google that issue and comes here

[hwillson]

There have been quite a few changes to Meteor's Google OAuth support since this issue was created, mostly because of Google's decision to no longer support OAuth when coming from a WebView (see #8253). Please try things out with a modern version of Meteor, and report back if you're still having issues using the newer Google Sign-In approach. Closing for now - thanks!