The "Right" Way to Make oAuth from a Mobile Client

Question

I am creating a cross-platform mobile application (using Xamari, MonoTouch / MonoDroid tools). I am trying to work through the authentication process and am in a stumbling block. I searched for the whole clear answer and have not yet found it.

Here is an overview of my current setup.

I have a website built into nodejs. I use pass.js to log in to the site. This works great, users can log in to my site using Twitter or Facebook.

Now I want to expand the same functionality for logging in to mobile clients.

I see 2 options

• Paste the app and app secret code into mobile clients and make oAuth direct calls to FB or Twitter from the mobile app.

• Proxy - calling oAuth through my existing nodejs web server (saving private keys on the server)

Option 2 seems preferable (since it avoids the need to "send" a secret in mobile applications).

I mainly use the proxy approach.

• I open WebView in my mobile client and point it to http://mysever/auth/twitter
• This goes through my existing passport.js code and redirects the mobile WebView to the Twitter login page.
• The user then enters their credits on the Twitter web page on the device.
• Twitter then calls my oAuth callback URL (which is my nodejs web server).
• My server and Twitter process the fourth handshake to get information about the user profile ( . As far as I understand, this is the key to this approach, my server and twitter handle the handshake, the mobile client does not have to do anything or transfer any tokens during this process )

Here is my problem :

• This is the last step that kneels me. As soon as the handshake is completed on my server, I have the user information that I need on the server, and I need to send it back to the mobile client application

  I just can't figure it out in a WebView control to grab a response object and grab a cookie or header value (for example, this is similar to Android and iOS). I do not think this is a specific platform. I think I'm trying to do something that the WebView widget on mobile platforms just doesn't support. It makes me think I'm missing something obvious.

The only thing I found out was to force my web server to “redirect” the mobile client browser to a fake URL that contains user information in the query string. Something like myapp: // info? Userid = 1234

Then in the mobile application, I can capture the loading of the URL and capture that URL and get the data I need. Then I can cross out this account, close the WebView control and go to my own screen in the mobile application and userinfo in any subsequent REST calls on my nodejs server as a means of identifying the user.

It is massively kludgy for several reasons. The biggest of them is that the URL is sent unencrypted over the wire and contains all the data in plain text.

Should there be a better way to return data from a web server to a mobile client?

Or am I doing everything wrong?

Answer 1

The easiest way to implement oauth for Xamarin, for both iOS and Android, is using Xamarin.Auth . The starter documentation for the client is here . I think it should support everything safely, and you don’t have to worry about having to use your node server as a proxy.

You will need to provide your application id as part of the calls, but I don't have too many or any security issues to worry about it.

I know that this is contrary to what you have already implemented, but maybe this can simplify things a bit.

Answer 2

This is the same dilemma I was dealing with. This is how I do it now. In my application, the client can directly or through another service, such as facebook, which is my main and, therefore, the one that I focus on.

Facebook can redirect through POST (desktop applications) or GET (mobile).

I check the original request to see if there is a service identifier - for example, facebook GET.

 app.get('/', function(req, res) { var paraUrl = URL.parse(req.url,true).query; //The fb_source is shown - //i need to go striaght to the facebook authorization since //its coming from //from a mobile device. if (paraUrl.fb_source){ res.redirect('/auth/facebook'); //this is the passport part return; } res.sendfile('index.html'); } 

On Facebook POST, it’s a little different that you get the access code for tokens in base64url. GET gives you a code that you can exchange for an access token, but I had problems with it, and I just chose the binding to the passport system.

If the client comes directly, I check the session or the encrypted cookie that is associated with the local strategy. Then it checks the db for the access token, which can be used, for example, to access the facebook api.

If the client is not recognized, it is given the opportunity to authenticate via facebook, google, etc.

The main thing is that only 2 pieces of information, the passport session identifier and the application user identifier are stored with the client

connect.sid - encypted cookie

userId - encypted cookie

I would be interested to know how other people face the problem.