The user is presented with an element enticing them to login. In the simplest case, you can redirect the browser to a resource on the OpenID Connect provider. Popups are probably a tad better.
The request should include parameters to approximate the permissions the application is requesting. These parameters are shown below.
|scope||https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile (list can be extended)|
|state||/ (the RP can add it's own value)|
|redirect_uri||https://oauthssodemo.appspot.com/oauthcallback (registered in the dev console)|
|client_id||8819981768.apps.googleusercontent.com (registered in the dev console)|
Scope is a concatenated list of requested permissions. The two shown in the table request basic profile information and email address (with verification)
State is used to correlate the response. It is reflected back to the site.
redirect_uri is registered with the Authorization server a prioris, and the Authorization Server uses it as a target for the response.
response_type indicates whether or not the site would like an access token or a code+refresh token. In this case, only an access token is needed.
client_id is used along with the redirect_uri to signal to the Authorization Server the application making the request.
The full URL of the target (with parameters) is: https://accounts.google.com/o/oauth2/auth?scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile&state=%2F&redirect_uri=https%3A%2F%2Foauthssodemo.appspot.com%2Foauthcallback&response_type=token&client_id=8819981768.apps.googleusercontent.com