Using OAuth 2.0 for Client-side Web Applications

The Google OAuth 2.0 endpoint supports JavaScript-centric applications. These applications may access a Google API while the user is present at the application, and this type of application cannot keep a secret. This authorization flow is known as the implicit grant flow.

This article describes how to use OAuth 2.0 when accessing a Google API from a JavaScript application.


This scenario begins by redirecting a browser (full page or popup) to a Google URL with a set of query parameters that indicate the type of Google API access the application requires. As in other scenarios, Google handles user authentication and consent, and the result is an access token. Google returns the access token on the fragment of the response, and client side script extracts the access token from the response.

The application may access a Google API after it receives the access token.

Note: Your application should always use HTTPS in this scenario.

Forming the URL

The URL used when authenticating a user is This endpoint is accessible over SSL, and HTTP connections are refused.

Endpoint Description This endpoint is the target of the initial request. It handles active session lookup, authenticating the user, and user consent.

The set of query string parameters supported by the Google Authorization Server for client-side applications are:

Parameter Values Description
response_type token JavaScript applications should use token. This tells the Google Authorization Server to return the access token in the fragment.
client_id The client ID you obtain from the API Console. Identifies the client that is making the request. The value passed in this parameter must exactly match the value shown in the Google API Console.
redirect_uri One of the redirect_uri values listed for this project in the API Console. Determines where the response is sent. The value of this parameter must exactly match one of the values listed for this project in the Google API Console (including the http or https scheme, case, and trailing '/').
scope Space-delimited set of permissions that the application requests. Identifies the Google API access that your application is requesting. The values passed in this parameter inform the consent screen that is shown to the user. There is an inverse relationship between the number of permissions requested and the likelihood of obtaining user consent. For information about available login scopes, see Login scopes. To see the available scopes for all Google APIs, visit the APIs Explorer. It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. For example, an app that wants to support purchases should not request Google Wallet access until the user presses the “buy” button; see Incremental authorization.
state Any string Provides any state that might be useful to your application upon receipt of the response. The Google Authorization Server round-trips this parameter, so your application receives the same value it sent. Possible uses include redirecting the user to the correct resource in your site, and cross-site-request-forgery mitigations.
prompt 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. Possible values:
none Do not display any authentication or consent screens. Must not be specified with other values.
consent Prompt the user for consent
select_account Prompt the user to select an account
login_hint email address or sub identifier When your application knows which user it is trying to authenticate, it can provide this parameter as a hint to the Authentication Server. Passing this hint will either pre-fill the email box on the sign-in form or select the proper multi-login session, thereby simplifying the login flow.
include_granted_scopes true or false If this is provided with the value true, and the authorization request is granted, the authorization will include any previous authorizations granted to this user/application combination for other scopes; see Incremental Authorization.

An example URL is shown below, with line breaks and spaces for readability.

Handling the response

Google returns an access token to your application if the user grants your application the permissions it requested. The access token is returned to your application in the fragment as part of the access_token parameter. Since a fragment is not returned to the server, client-side script must parse the fragment and extract the value of the access_token parameter.

Other parameters included in the response include expires_in and token_type. These parameters describe the lifetime of the token in seconds, and the kind of token that is being returned. If the state parameter was included in the request, then it is also included in the response.

An example User Agent flow response is shown below:

Note: Other fields may be included in the response, and your application should not treat this as an error. The set shown above is the minimum set.

Below is a JavaScript snippet that parses the response and returns the parameters to the server.

// First, parse the query string
var params = {}, queryString = location.hash.substring(1),
    regex = /([^&=]+)=([^&]*)/g, m;
while (m = regex.exec(queryString)) {
  params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);

// And send the token over to the server
var req = new XMLHttpRequest();
// consider using POST so query isn't logged'GET', 'https://' + + '/catchtoken?' + queryString, true);

req.onreadystatechange = function (e) {
  if (req.readyState == 4) {
     if(req.status == 200){
       window.location = params['state']
  else if(req.status == 400) {
        alert('There was an error processing the token.')
    else {
      alert('something else other than 200 was returned')

This code sends the parameters received on the fragment to the server using XMLHttpRequest. If your application requires other JavaScript code to make calls to a Google API, you can store the access token in the browser's local storage. Also note that this code sends the parameters to the /catchtoken endpoint, and they are sent over an HTTPS channel.

Error response

The Google Authorization Server returns an error if the user did not grant your application the permissions it requested. The error is returned in the fragment.

An example error response is shown below:

Validating the token

Tokens received on the fragment MUST be explicitly validated. Failure to verify tokens acquired this way makes your application more vulnerable to the confused deputy problem.

You can validate a token by making a web service request to an endpoint on the Google Authorization Server and performing a string match on the results of that web service request.

TokenInfo validation

Verifying a token using the Google Authorization Server endpoint is relatively simple. Your application includes the access token in the access_token parameter for the following endpoint:

Endpoint Description Accepts an access token and returns information about that access token including which application was it issued to, the intended target of the token, the scopes the user consented to, the remaining lifetime of the token, and the user ID.

Below is an example of such a request:

The TokenInfo endpoint will respond with a JSON object that describes the token or an error. Below is a table of the fields included in the non-error case:

Field Description
audience The application that is the intended target of the token.
scope The space-delimited set of scopes that the user consented to.
userid This field is only present if the profile scope was present in the request. The value of this field is an immutable identifier for the logged-in user, and may be used when creating and managing user sessions in your application. This identifier is the same regardless of the client ID. This provides the ability to correlate profile information across multiple applications in the same organization.
expires_in The number of seconds left in the lifetime of the token.

On the wire, the response looks similar to the following:

  "scope":"profile email",

Note: When verifying a token, it is critical to ensure the audience field in the response exactly matches the client ID that you obtained in the API Console. It is absolutely vital to perform this step, because it is the mitigation for the confused deputy issue.

If the token has expired, has been tampered with, or the permissions revoked, the Google Authorization Server will respond with an error. The error surfaces as a 400 status code, and a JSON body as follows:


By design, no additional information is given as to the reason for the failure.

Calling a Google API

After your application obtains an access token, you can use the token to make calls to a Google API on behalf of a given user account or service account. To do this, include the access token in a request to the API by including either an access_token query parameter or an Authorization: Bearer HTTP header. When possible, the HTTP header is preferable, because query strings tend to be visible in server logs. In most cases you can use a client library to set up your calls to Google APIs (for example, when calling the Drive API).

You can try out all the Google APIs and view their scopes at the OAuth 2.0 Playground.


A call to the drive.files endpoint (the Drive API) using the Authorization: Bearer HTTP header might look like the following, though you'll need to specify your own access token:

GET /drive/v2/files HTTP/1.1
Authorization: Bearer 1/fFBGRNJru1FQd44AzqT3Zg

Here is a call to the same API for the authenticated user (me) using the access_token query string parameter:


You can try out with the curl command-line application. Here's an example using the HTTP header option (preferred):

curl -H "Authorization: Bearer 1/fFBGRNJru1FQd44AzqT3Zg"

Or, alternatively, the query string parameter option:


Incremental authorization

In the OAuth protocol, your app requests authorization to access resources which are identified by scopes, and assuming the user is authenticated and approves, your app receives short-lived access tokens which let it access those resources, and (optionally) refresh tokens to allow long-term access.

It is considered a best user-experience practice to request authorization for resources at the time you need them. For example, an app that lets people sample music tracks and create mixes might need very few resources at sign-in time, perhaps nothing more than the name of the person signing in. However, saving a completed mix would require access to their Google Drive. Most people would find it natural if they only were asked for access to their Google Drive at the time the app actually needed it.

In this case, at sign-in time the app might request the scope profile to perform a basic sign-in function, and then later request the scope at the time of the first request to save a mix.

Using the procedures described in Using OpenID Connect and Using OAuth 2.0 to Access Google APIs would normally result in your app having to manage two different access tokens. If you wish to avoid this complexity, you may add an extra parameter to the Authentication URI that you send to as the first step of any OAuth 2.0 flow. The parameter is include_granted_scopes and the allowed values are true and false (the default is false). When the value is true, the effect is that if your scope authorization request is granted, the Google authorization server will roll this authorization together with all the previous authorizations granted to the requesting user from the requesting app. The URI you construct might end up looking this this (line breaks and space inserted for readability):

Let’s call the resulting authorization the “combined authorization”; the following apply:

  • You can use the access tokens you get to access the resources corresponding to any of the scopes that are rolled into the combined authorization.
  • When you use the refresh token for a combined authorization, the new access tokens represent the combined authorization and can be used for any of its scopes.
  • The combined authorization includes any previously granted authorizations even if they were requested from different clients. For example, if you requested the profile scope from a desktop app, and then issued the request in the example URI above for the same user from a mobile app, and it was granted, the combined authorization would include both scopes.
  • When you revoke a token which represents a combined authorization, all of the authorizations are revoked simultaneously; this means that if you retain a token for one of the previous authorizations, it will stop working.