Social Login + OAuth2-secured REST API

Question

I'm implementing social login with Facebook, Twitter and Google+ on our OAuth2-secured REST API (secured using spring-security-oauth). I'd like to make sure that the following flow is secure and that I'm not introducing any security holes.

Overview

There's a REST API and three types of client applications: web, iOS and Android. Communication between the API and client applications is made through HTTPS.

Flow

1. Client applications initiate the social login flow either via the browser or native apps, and make the whole "OAuth dance". They obtain a user ID and an access token corresponding to this user ID.
2. Client applications send user ID and access token to the REST API as POST parameters to our OAuth2 token endpoint specifing a custom grant_type (either facebook, twitter or google).
3. The REST API contacts the corresponding social network and validate that
   • The access token is active.
   • The access token was generated for the specified user and for our application.
4. If the above conditions are met, we grab from our DB the user with the specified external ID and generate our own access token which can be used in further requests. The access token is never saved to our database, only the user ID.

I'd like to know whether this is the correct way of implementing social login in this scenario and if there are any pitfalls to this whole flow.

Answer 1

Your flow looks correct as stated, but there are difficulties. Let me explain.

First is the distinction between "authentication" and "authorization." Social login focuses on authentication: Rather than logging in with your application's user/password (or whatever), you're allowing your user to be already-logged-in with Google, Twitter, or Facebook.

Once your user is logged in (by whatever means), YOUR application decides what this user is authorized to do. We can forget that we got here via OAuth 2 (social login) rather than normal site login. That flow looks fine.

Where is the security issue? In that "OAuth 2 dance" which is your step 1, be sure you follow the current docs provided by Google, Twitter, and/or Facebook. Do NOT expose your application's secret API key to the client side (browser or native app). In other words, part of the dance needs to be done server-side. It's very easy to get this wrong, and THAT is the pitfall.

There's another way to look at this. Your application could choose to act as an OAuth 2 client. The token provides not just authentication, but also authorization. The token tells your application what this user is allowed, and not allowed, to do in your application. This is the classic OAuth use case: A third-party application is authorized to perform some task (such as obtaining and printing photos) without having the user's login credentials.

In working with OAuth 2, you can avoid many pitfalls by careful attention to the distinction between authorization and authentication. The OP correctly makes this distinction.