简体   繁体   中英

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

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?

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.

The details in the accepted answer are correct, but there's a much easier way of doing it that is only vaguely hinted at, rather than actually stated, but it turns up in the example code if you read carefully.

The key is:

https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=TOKEN

When TOKEN is the client side access token. This will return a json block like this:

{u'access_type': u'online',
 u'audience': u'...',
 u'expires_in': 3475,
 u'issued_to': u'...', <--- The client ID; use this to verify access token
 u'user_id': u'1234567890', <--- The unique google user id 
 u'scope': u'https://www.googleapis.com/auth/userinfo.profile')

Notice that this simply validates:

  • the token is valid (ie. user logged in)
  • the user_id <--> access_token binding is valid (not a client side hack to be a different user)
  • the application id is correct

If you want to query for additional details about a user, you need to use one of the OAuth libraries.

In many cases this may be sufficient to uniquely identify the user.

You can skip making a network request to the tokeninfo endpoint by verifying the authenticity of the users JWT id_token on your server. This can easily be done by using one of Google's API Client Libraries.

This also allows you to avoid needed to request a offline access code if not needed.

This is the method recommended in Google'sdocumentation .

Check there for more detailed instructions.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM