How do I validate a client-side google+ login?

Question

So, following the basic tutorial here (https://developers.google.com/+/web/signin/javascript-flow) you can easily add a client-side login for google accounts.

By modifying the code to query /people/me, as follows:

function signinCallback(authResult) {
  if (authResult['status']['signed_in']) {
    gapi.auth.setToken(authResult);
    gapi.client.load('plus','v1', function(){
      var request = gapi.client.plus.people.get({
        'userId': 'me'
      });
      request.execute(function(resp) {
        console.log(resp);
      });
  });
}

You can gain access to the basic account information; user id, image, name, etc.

You also have a valid access token from the oauth login.

Now, unless you have an entirely client-side application, as some point you're going to have to notify the server that the user is logged in, to get application data for that user.

What I want to do is POST to /login/gauth {'access_token': ..., 'user_id': ....} which will respond with an auth cookie and redirect back; except now we have a persistent local auth token which we can use to identify the user.

On the server I need to do is access the same REST api (/people/me) using the access token, and validate the user id it returns; any other provided information is forge-able on the client side.

The problem is, I can't find any way of validating/using an access token on the server side.

I can setup a new OAuth login on the server, and do a server only login process, but that's fairly involved, and seems wasteful considering I already have a valid access token.

How do I use it?

Answer 1

You probably want to use the hybrid flow that is outlined at https://developers.google.com/+/web/signin/server-side-flow. In this flow, your client does roughly the same thing it does now, but your client also gets a short-lived "code" that it should pass to the server along a secure channel. The server then validates this against the server to get its own access (and possibly refresh) token. This is safer than the client trying to send the access_token, since it reduces the window that a man-in-the-middle can exploit it and it can only be used once, reducing the opportunity.