Updated Google provider so that login uses the recommended Google+ People endpoint

[qualquervalor]

Auth and Token have been updated based on values found in the OpenIDConnect discovery document:
https://accounts.google.com/.well-known/openid-configuration
Scope discussion can be found here:
https://developers.google.com/+/web/api/rest/oauth#plus.login
Goggle discovery doc for the plus service:
https://www.googleapis.com/discovery/v1/apis/plus/v1/rest
Documentation of response body:
https://developers.google.com/+/web/api/rest/latest/people#resource

[geek]

@qualquervalor please update so that this can be merged... thanks :)

[geek]

@qualquervalor looks good. Have you tried this with the /examples/google.js yet?

[qualquervalor]

Yes. I hadn't planned on checking in my updates to the example, but here they go.

[fson]

What is the purpose of requesting those Google+ permissions? Note that doing this, those permissions are asked from the user:
Before:

After:

From the documentation it seems that OpenID Connect is still a recommended way to implement authentication with Google using OAuth 2.0.

For OpenID Connect, the scope should be openid,email, openid,profile or openid,email,profile. (https://developers.google.com/identity/protocols/OpenIDConnect#scope-param)

Fetching the profile seems a bit more complex with OpenID Connect however: apparently you're supposed to fetch the Discovery Document and then make a request to the userinfo_endpoint URL specified in the document.

[qualquervalor]

The motivation was to use the latest and greatest as suggested in Google's migration guide https://developers.google.com/+/web/api/rest/auth-migration#oauth2login. A user has the ability to override the scopes. Simpler scopes are still supported as described here https://developers.google.com/+/web/api/rest/oauth#plus.login. I could swap out the newer scopes and replace them with ['profile', 'email'] for the default case, This would still use the newer Google+ endpoint and ask the same level of permission that were previously requested.

[fson]

Thanks for the detailed reply @qualquervalor! This all makes sense now.

I think whatever scope is sufficient for getting the very basic information (displayName, name, email) that is extracted by default in the provider code makes sense as a default scope. Users wanting to extract more information using the raw profile can then easily override the scope to include all the scopes they need.