iOS and Server: OAuth strategy

Question

I'm trying to working how to handle authentication when I have iOS clients accessing a Node.js server and want to use services such as Google, Facebook etc to provide basic authentication for my application. My current idea of a typical flow is this:

1. User taps a Facebook/Google button which triggers the OAuth(2) dialogs and authenticates the user on the device. At this point the device has the users access token. This token is saved so that the next time the user uses the app it can be retrieved.

2. The access token is transmitted to my Node.js server which stores it, and tags it as un-verified.

3. The server verifies the token by making a call to Facebook/google for the users email address. If this works the token is flagged as verified and the server knows it has a verified user. If Facebook/google fail to authenticate the token, the server tells iOS client to re-authenticate and present a new token.

4. The iOS client can now access api calls on my Node.js server passing the token each time. As long as the token matches the stored and verified token, the server accepts the call.

Obviously the tokens have time limits. I suspect it's possible, but highly unlikely that someone could sniff an access token and attempt to use it within it's lifespan, but other than that I'm hoping this is a reasonably secure method for verification of users on iOS clients without having to roll my own security.

Any opinions and advice welcome.

Answer 1

Yes somebody could potentially see this token in the packet, which is why it is also a good idea to use SSL encryption of all network traffic before and after authentication and distribution of a token.

Someone on an unencrypted wireless network, like at a Starbucks use this method all the time to pick up packets to services like Facebook that do not require SSL encrypted traffic. They then can use this token in their own requests to spoof another users session.

Likewise if I am a hacker and I were to compromise a particular machine behind a firewall where network traffic passes through, lets say a load balancer, I can then use that information to determine credentials and session tokens on unencrypted traffic that passes through.

The appropriate way to handle this is to utilize SSL encryption, even if it is a self-signed certificate then you are ensured that third parties cannot listen in on user requests.