What is the role of the redirect URI in the context of a mobile Android application using own back-end API?

Question

My scenario is that I have an Android application which has a back-end server. I'm implementing the ability to sign in using Google as an alternative to setting up an account with specified credentials.

On the server side I am using LoopBack, which underneath uses the Node/Express Passport library for OAuth2. On the Android side I am using Google's modern Sign-In library.

The Android Sign-In library takes all care of prompting the user to choose a Google account to sign in with. Once this succeeds, the library provides me with a server auth token.

This server auth token may then be passed to /auth/google/callback?token=... at my back-end, which then logs me in.

So far, all of this works to an extent. So far, my back-end runs on my development machine. In the Google API console, the callback URI for the OAuth2 key points to http://localhost:3000/auth/google/callback. Specifically, on my Android app, I successfully get an auth token. If I manually paste this into Postman running on my development machine to GET to http://localhost:3000/auth/google/callback it successfully authenticates. However, if I attempt to complete the final piece of the puzzle such that the app itself passes the token to the server application, a redirect URI mismatch error occurs. This, I can only assume, is because the HTTP request from Postman on the same machine contains 'localhost' in the host header. But a request from anything else has the machine's LAN IP in the host header.

Firstly, although I generally understand the OAuth2 flow and I understand that the purpose of the callback is for Google's server itself to deliver an auth token back to your server in the context of a web application, what I don't fully understand is the relevance of the callback URI in the case where an application receives the auth token and then performs the task of passing the token to the back-ends callback URI itself.

Secondly, how can I successfully pass the auth token to my development server and authenticate successfully? The Google API console will allow me to specify localhost, but obviously not a LAN IP.

Answer 1

What I have discovered is that this is to do with the callbackURL property that exists in LoopBack's providers.json file as part of the Passport configuration.

Initially, I had it set to /auth/google/callback. Now, from what I can only assume, this process happens:

• If I use Postman on the development machine to submit the auth token to the LoopBack application, then Passport appends localhost:3000 to /auth/google/callback. So, when Passport makes its request to the Google server, the complete callback URI it has formed matches my whitelisted callback URI in the API console (http://localhost:3000/auth/google/callback) and the request succeeds.

• My other device on the LAN (Android device) makes a HTTP request on my development machine running the LoopBack application. Then, I can only assume that Passport is building the absolute callback URI from what's in the HTTP host header (my machine's 192.168.x.x IP) and appending the /auth/google/callback. Therefore the request from Passport to Google fails because http://192.168.x.x:3000/auth/google/callback doesn't match http://localhost:3000/auth/google/callback. I am guessing that, if Passport is configured with a relative callbackURL, then presumably it gets concatenated with req.headers.host or something. I assume this is fine if you want to have an app that runs in both development and production without needing to do any configuration change, but it throws a spanner in the works when I want to use my Android app against the devopment server.

So, one solution that works, in terms of allowing the Android device to submit the auth token to the server application on my development machine which the server app successfully redeems with Google, is for me to have NO callback URI defined in the API console, AND to ensure that the callbackURL parameter is omitted from the Passport configuration. The problem with this though is that conventional web sign-in doesn't work (because the Google web page provides a 400 error, stating that the callback URI is missing).

The alternative is that I set the callbackURL to the absolute http://localhost:3000/auth/google/callback (rather than relative one) and put that as the callback URI at the API console. With this method, I can sign in using the web front-end of the server application, and authenticate from my Android application as well.

I think what I am going to have to do is use environment configuration of the absolute callbackURL.

Answer 2

what I don't fully understand is the relevance of the callback URI in the case where an application receives the auth token and then performs the task of passing the token to the back-ends callback URI itself.

About your first question, I would have to say that, the responsibility of the /callback endpoint in the backend is exchanging authorization code obtained from google authentication to access_token and refresh_token being needed for calling google scopes.

However, as far as I've realized according to the google mobile app documentation, you don't need to call the backend /callback from your Android app. Actually, in the new pattern of oauth2 communication, it should be called by google itself. So I think in this way you won't encounter the redirect_uri mismatch error anymore.

Also, I guess according to this information you can deal with google API without any backend part. For example, you can call the https://oauth2.googleapis.com/token url rather than calling the /callback endpoint in the backend.

---

[NOTE]

Loopback IP address redirect has been deprecated ^Ref.