For example, an application can use OAuth 2. It is designed for applications that access APIs only while the user is present at the application. These applications are not able to store confidential information. In this flow, your app opens a Google URL that uses query parameters to identify your app and the type of API access that the app requires. You can open the URL in the current browser window or a popup. The user can authenticate with Google and grant the requested permissions.
Google then redirects the user back to your app. The redirect includes an access token, which your app verifies and then uses to make API requests.
Given the security implications of getting the implementation correct, we strongly encourage you to use OAuth 2. It is a best practice to use well-debugged code provided by others, and it will help you protect yourself and your users.
To enable the appropriate APIs for your project: Select the project associated with your application. Create a project if you do not have one already. Use the Library page to find each API that your application will use.
Click on each API and enable it for your project. Create authorization credentials Any application that uses OAuth 2. The following steps explain how to create credentials for your project. Your applications can then use the credentials to access APIs that you have enabled for that project.
Set the application type to Web application. The origins identify the domains from which your application can send API requests. Identify access scopes Scopes enable your application to only request access to the resources that it needs while also enabling users to control the amount of access that they grant to your application. Thus, there may be an inverse relationship between the number of scopes requested and the likelihood of obtaining user consent. Before you start implementing OAuth 2.
Your application must have that consent before it can execute a Google API request that requires user authorization. These objects enable your application to obtain user authorization and to make authorized API requests.
The client object identifies the scopes that your application is requesting permission to access. These values inform the consent screen that Google displays to the user. The Choosing access scopes section provides information about how to determine which scopes your application should request permission to access.
It handles the redirect from that server back to your application. It validates the access token returned by the authorization server. It stores the access token that the authorization server sends to your application and retrieves it when your app subsequently makes authorized API calls. The code snippet below is an excerpt from the complete example shown later in this document. This code initializes the gapi. When that object is created, the gapi. The call to gapi. The apiKey and clientId values specify your application's authorization credentials.
As discussed in the creating authorization credentials section, these values can be obtained in the API Console. Note that the clientId is required if your application makes authorized API requests. Applications that only make unauthorized requests can just specify an API key.
The scope field specifies a space-delimited list of access scopes that correspond to the resources that your application needs to access. We recommend that your application request access to authorization scopes in context whenever possible.
Finally, the code sets a listener that calls a function when the user's sign-in status changes. That function is not defined in the snippet. Redirect to Google's OAuth 2. The code snippet below demonstrates how you would initiate the user authorization flow. Note the following points about the snippet: The GoogleAuth object referenced in the code is the same as the global variable defined in the code snippet in step 1.
The updateSigninStatus function is a listener that listens for changes to the user's authorization status. Its role as a listener was also defined in the code snippet in step 1: This value can be set when the app loads and updated if the user signs in or out of the app.
In this snippet, the sendAuthorizedApiRequest function checks the variable's value to determine whether the app should attempt an API request that requires authorization or prompt the user to authorize the app. The object's value is set when the app calls the sendAuthorizedApiRequest function.
If the user has authorized the app, the request is executed right away. Otherwise, the function redirects the user to sign in. After the user signs in, the updateSignInStatus function calls sendAuthorizedApiRequest, passing in the same request that was attempted before the authorization flow started.
In that case, proceed with that API request. The Google authorization server supports the following query string parameters for web server applications: The client ID for your application. You can find this value in the API Console. Determines where the API server redirects the user after the user completes the authorization flow.
Specifies any string value that your application uses to maintain state between your authorization request and the authorization server's response. You can use this parameter for several purposes, such as directing the user to the correct resource in your application, sending nonces, and mitigating cross-site request forgery. If you generate a random string or encode the hash of a cookie or another value that captures the client's state, you can validate the response to additionally ensure that the request and response originated in the same browser, providing protection against attacks such as cross-site request forgery.
See the OpenID Connect documentation for an example of how to create and confirm a state token. Enables applications to use incremental authorization to request access to additional scopes in context. If you set this parameter's value to true and the authorization request is granted, then the new access token will also cover any scopes to which the user previously granted the application access.
See the incremental authorization section for examples. If your application knows which user is trying to authenticate, it can use this parameter to provide a hint to the Google Authentication Server.
The server uses the hint to simplify the login flow either by prefilling the email field in the sign-in form or by selecting the appropriate multi-login session.
Set the parameter value to an email address or sub identifier, which is equivalent to the user's Google ID. A space-delimited, case-sensitive list of prompts to present the user. If you don't specify this parameter, the user will be prompted only the first time your app requests access. Must not be specified with other values. Sample redirect to Google's authorization server An example URL is shown below, with line breaks and spaces for readability.
Since this OAuth 2. Google prompts user for consent In this step, the user decides whether to grant your application the requested access.
At this stage, Google displays a consent window that shows the name of your application and the Google API services that it is requesting permission to access with the user's authorization credentials. The user can then consent or refuse to grant access to your application. Your application doesn't need to do anything at this stage as it waits for the response from Google's OAuth 2. That response is explained in the following step.
Handle the OAuth 2. If you set a listener to monitor changes in the current user's sign-in state, that function is called when the user grants the requested access to the application. If the user approves the request, then the response contains an access token. If the user does not approve the request, the response contains an error message. The access token or error message is returned on the hash fragment of the redirect URI, as shown below: An authorization code response: If the state parameter was specified in the access token request, its value is also included in the response.
By validating, or verifying, the token, you ensure that your application is not vulnerable to the confused deputy problem.