Google Accounts Authentication and Authorization

OAuth 1.0 API Reference

The first section in this document describes how to migrate your code from OAuth 1.0 to OAuth 2.0. The rest of the document describes Google's implementation of the deprecated OAuth 1.0 open standard for authorization, and explains how to implement OAuth 1.0 in an application.

Contents

  1. Migrating from OAuth 1.0 to OAuth 2.0
  2. Getting and upgrading an OAuth 1.0 token (deprecated)
  3. Signing OAuth 1.0 requests (deprecated)
  4. Handling users with multiple accounts (deprecated)
  5. Testing and debugging OAuth 1.0 requests (deprecated)
  6. Revoking an OAuth 1.0 access token (deprecated)

Migrating from OAuth 1.0 to OAuth 2.0

This section describes how to migrate your application from OAuth 1.0 to OAuth 2.0, without the need for end-user intervention. After migration, your application can stop using the OAuth 1.0 library and can access resources using OAuth 2.0 tokens.

Prerequisites for this migration:

  • Your application must have a valid OAuth 1.0 access token (which implies that your application has a valid grant).
  • Your application must have an OAuth 2.0 client ID and client secret. You get these OAuth 2.0 credentials by registering the application as a web app or a native app in the Google Cloud Console.

To find your OAuth 2.0 credentials in the Google Cloud Console:

  1. Go to the Google Cloud Console.
  2. Select a project.
  3. In the sidebar on the left, select APIs & auth. In the displayed list of APIs, make sure all the APIs you are using show a status of ON.
  4. In the sidebar on the left, select Registered apps.
  5. Select an application.

You present both the OAuth 1.0 and OAuth 2.0 credentials in a single request; there is no other binding of the two grants. The idea is to exchange an OAuth 1.0 grant for an OAuth 2.0 refresh token. The basic flow is shown in the following figure.

The flow is as follows:

  1. The process is triggered when an OAuth 1.0 consumer (your application) sends a migration request to Google’s OAuth 2.0 token endpoint.
  2. The credentials in the migration request are validated.
  3. An OAuth 2.0 refresh token is issued to your application in the response to your migration request.
  4. Your application uses OAuth 2.0 flows to exchange the refresh token for an OAuth 2.0 access token. (Note that when the refresh token is used, the OAuth 1.0 access token will expire in 1 hour.)

As soon as your application obtains the OAuth 2.0 access token, it can drop the OAuth 1.0 token and use OAuth 2.0 tokens to access users' resources.

Sending a migration request

You send a grant migration request to the existing Google OAuth 2.0 token endpoint, which is https://accounts.google.com/o/oauth2/token. The request must be a POST, and you must send it via HTTPS. The endpoint refuses HTTP requests.

Signed-request flow for migration

Request

The request is a signed OAuth 1.0 request with additional OAuth 2.0 request parameters. You include the OAuth 1.0 consumer key, token secret, and signature in the OAuth 1.0 authorization HTTP header. For example:

Authorization: OAuth realm="Example",
               oauth_consumer_key="9djdj82h48djs9d2",
               oauth_token="kkk9d7dh3k39sjv7",
               oauth_signature_method="HMAC-SHA1",
               oauth_timestamp="137131201",
               oauth_nonce="7d8f3e4a",
               oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"

All the fields are required except realm. Applications can use any OAuth 1.0 library to generate the header.

There are three required OAuth 2.0 request parameters (grant_type, client_id, and client_secret) and an optional parameter (scope):

  • grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1

    Required. This is a fixed value.

  • client_id

    Required. This is the OAuth 2.0 client ID, which you get from the Google Cloud Console.

  • client_secret

    Required. This is the OAuth 2.0 client secret, which you get from the Google Cloud Console.

  • scope

    Optional. Use the scope parameter when you want to "down-scope" and request fewer OAuth 2.0 scopes than were granted via OAuth 1.0. List the requested scopes in the scope parameter, separated by spaces. Any other scopes are dropped, and the requested scopes are validated. If you do not provide the scope parameter, the requested scopes are those previously granted via OAuth 1.0.

An example request is shown below:

POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 88
Authorization: OAuth realm="Example",
               oauth_consumer_key="9djdj82h48djs9d2",
               oauth_token="kkk9d7dh3k39sjv7",
               oauth_signature_method="HMAC-SHA1",
               oauth_timestamp="137131201",
               oauth_nonce="7d8f3e4a",
               oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Amigration%3Aoauth1&
client_id=8819981768.apps.googleusercontent.com&
client_secret={client_secret}

Response

After a migration request is validated, your application is issued a refresh token with down-scoped scopes. The response body is in JSON format, and it contains only an OAuth 2.0 refresh token (no access token).

An example response is shown below:

{
  "refresh_token" : "1/IJ8bRmYIH4t6iE761H3XW9JwqzsGFCA8wnQ7gck_3NU"
}

Obtaining an OAuth 2.0 access token

Exchange the refresh token for an OAuth 2.0 access token, as described in Using a refresh token.

About refresh tokens:

  • Refresh tokens never expire unless revoked.
  • It is the responsibility of your client software to store the refresh token permanently and securely.

Unsigned-request flow for migration

If you have a native application and do not want to sign the request, you can use a no-signature flow. In this flow, your application sends all the necessary credentials in the request parameters over SSL. No authorization header is needed in this case. This also allows native applications to drop OAuth 1.0 libraries, either immediately or in a future version, and still have an upgrade path.

Request

In an unsigned-request flow, include the following OAuth 2.0 parameters in your request:

  • grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1
  • client_id
  • client_secret
  • scope

The rules governing the parameters, and their meanings, are identical to those in the signed-request flow.

Also include the following OAuth 1.0 parameters:

  • oauth_consumer_key
  • oauth_consumer_secret
  • oauth_token
  • oauth_token_secret
  • An example request is shown below:

    POST /o/oauth2/token HTTP/1.1
    Host: accounts.google.com
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 473
    
    oauth_consumer_secret=anonymous&
    oauth_consumer_key=anonymous&
    oauth_token={token secret}&
    client_id=8819981768.apps.googleusercontent.com&
    client_secret={client secret}&
    scope=https%3A%2F%2Fdocs.google.com%2Ffeeds%2F+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fgoogletalk+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdocs&oauth_token_secret=hrUbfZIRxIgpC_AN-arCYDsJ&
    grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Amigration%3Aoauth1
    

    As in the signed-request flow, the response is a refresh token. (For details, see Response).

    Validations that are performed on migration requests

    When you migrate your code from OAuth 1.0 to OAuth 2.0 and you send a migration request to Google’s OAuth 2.0 token endpoint, the credentials in the request are validated as described in this section.

    Client-type validation

    The OAuth 2.0 client type must match the OAuth 1.0 consumer type. In other words, they must both be native applications, or they must both be web applications. An application is identified as a native application if one of the following is true:

    • The application has set its native application name, or
    • The application is a Chrome extension.

    If your application is a native application, the OAuth 2.0 client must be registered as a native application. In addition, if the consumer type is Chrome extension, the OAuth 2.0 client type must be a Chrome extension.

    An application is identified as a web application if all of the following are true:

    • The application is not identified as a native application in the above validation, and
    • The OAuth 1.0 consumer key is not anonymous, and
    • The application's OAuth 2.0 redirect_uri is neither oob nor empty. (You set the redirect_uri in the Google Cloud Console.)

    If your application is a web application, the OAuth 2.0 client must be registered as a web application.

    Scope validation

    Scope validation is performed after down-scoping. None of the following are allowed in the list of requested scopes:

    • An empty scope list
    • Any scopes that were not previously granted via OAuth 1.0
    • https://www.google.com/accounts/OAuthLogin
    • https://www.googleapis.com/auth/plus.login

    Getting and upgrading an OAuth 1.0 token (deprecated)

    Before you can access a user's data, you must do the following:

    Version Update: OAuth v1.0 to OAuth v1.0a

    Google's OAuth 1.0 endpoints are updated for OAuth v1.0a. This update involves two major changes:

    • A new parameter, oauth_verifier, is now required by the OAuthGetAccessToken endpoint. This parameter takes a verification code, which is generated by Google once a user has granted access to the third-party application. The verification code is returned one of two ways:
      • If the third-party application supplies a callback URL, Google redirects the user back to the application after a successful call to OAuthAuthorizeToken, with query parameters containing token, token secret, and verifier.
      • If the third-party application does not supply a callback URL, Google displays a web page to the user containing the verification code. This scenario allows applications that can't process redirects to use this OAuth; it is assumed that these applications will provide a way for users to enter the verification code into the application.
    • The parameter oauth_callback has been moved from the OAuthAuthorizeToken endpoint to the OAuthGetRequestToken endpoint. This enables authorization providers, like Google, to confirm that a URL redirect back to the third-party application can be handled.

    For backward compatibility, Google continues to support applications using OAuth version 1.0, recognizing calls to OAuthAuthorizeToken with the oauth_callback parameter and calls to OAuthGetAccessToken without a verification code. Because of the lack of a verification code, however, applications using v1.0 will trigger the yellow warning box displayed to users on the Request Access page (see example).

    OAuthGetRequestToken

    Contact Google for a request token. Google verifies that the requesting application has been registered with Google or is using an approved signature (in the case of installed applications). The request token acquired with this request must be first authorized by the end user and then exchanged for an access token. A request token cannot be used to get access to a Google service.

    Send a request to: https://www.google.com/accounts/OAuthGetRequestToken with the following query parameters:

    Parameter Description
    oauth_consumer_key (required) Domain identifying the third-party web application. This is the domain used when registering the application with Google.
    oauth_nonce (required) Random 64-bit, unsigned number encoded as an ASCII string in decimal format. The nonce/timestamp pair should always be unique to prevent replay attacks.
    oauth_signature_method (required) Signature algorithm. The legal values for this parameter "RSA-SHA1" or "HMAC-SHA1". Google does not support "PLAINTEXT".
    oauth_signature (required) String generated using the referenced signature method. See Signing requests.
    oauth_timestamp (required) Integer representing the time the request is sent. The timestamp should be expressed in number of seconds after January 1, 1970 00:00:00 GMT.
    scope (required) URL identifying the service(s) to be accessed. The resulting token enables access to the specified service(s) only. Scopes are defined by each Google service; see the service's documentation for the correct value. To specify more than one scope, list each one separated with a space. This parameter is not defined in the OAuth standards; it is a Google-specific parameter.
    oauth_callback (required) URL the user should be redirected to after access to a Google service(s) is granted (in response to a call to OAuthAuthorizeToken). The response to this OAuthGetRequestToken call verifies that Google handles a callback URL. The callback URL can include url-encoded query parameters. To trigger an alternative sequence, in which Google displays a success page with a verification code that the user must then supply to the third-party application, use the value oob. In the subsequent call to OAuthGetAccessToken, the parameter verifier must be set to this value.
    oauth_version (optional) The OAuth version used by the requesting web application. This value must be "1.0"; if not provided, Google assumes version 1.0 is in use.
    xoauth_displayname (optional) String identifying the application. This string is displayed to end users on Google's authorization confirmation page. For registered applications, the value of this parameter overrides the name set during registration and also triggers a message to the user that the identity can't be verified. For unregistered applications, this parameter enables them to specify an application name, In the case of unregistered applications, if this parameter is not set, Google identifies the application using the URL value of oauth_callback; if neither parameter is set, Google uses the string anonymous.

    Depending on the type of request sent, these parameters can be placed in:

    • Authorization header of a GET or POST request. Use "Authorization: OAuth". All parameters listed above can go in the header, except for scope and xoauth_displayname, which must go either in the body or in the URL as a query parameter. The example below puts them in the body of the request.
    • Body of a POST request. The content type must be "Content-Type: application/x-www-form-urlencoded".
    • As URL query parameters in a GET request.

    For more details, see the OAuth specification, Section 5.2.

    OAuth 1.0 sample request

    This example illustrates a registered web application asking for a request token to access a user's Calendar and Picasa accounts.

    POST /accounts/OAuthGetRequestToken HTTP/1.1
    Host: www.google.com
    Content-Type: application/x-www-form-urlencoded
    Authorization: OAuth
    oauth_consumer_key="example.com",
    oauth_signature_method="RSA-SHA1",
    oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
    oauth_timestamp="137131200",
    oauth_nonce="4572616e48616d6d65724c61686176",
    oauth_version="1.0"
    oauth_callback="http://www.example.com/showcalendar.html"
    
    scope="http://www.google.com/calendar/feeds http://picasaweb.google.com/data"

    OAuth 1.0 request token response

    If the request for a request token is successful, Google responds with an HTTP 200 OK message containing an OAuth request token, a token "secret", and confirmation that Google handles a callback URL.

    A token request may be rejected by Google if the request is malformed or if Google has reason to believe the requestor is not acting in good faith. If the request is not successful, Google returns the following error:

    • HTTP 400 Bad Request: in the case of an unsupported or missing parameter, an unsupported oauth_signature_method, or other error in the request format or content.

    OAuth 1.0 sample response

    This example illustrates an OAuth request token returned in the response header. At this point, the request token cannot be used to request data from the Google service; it must be authorized by the Google Authorization service.

    oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=ZXhhbXBsZS5jb20&oauth_callback_confirmed=true

    OAuthAuthorizeToken

    Call the Google Authorization service at https://www.google.com/accounts/OAuthAuthorizeToken with the following query parameters:

    Parameter Description
    oauth_token (required) Request token obtained from Google.
    hd (optional) String value identifying a particular hosted domain account to be accessed (for example, 'mycollege.edu'). Use "default" to specify a regular Google account ('username@gmail.com'). This is a Google-specific parameter.
    hl (optional) An ISO 639 country code identifying what language the approval page should be translated in (for example, 'hl=en' for English). The default is the user's selected language. This is a Google-specific parameter.
    btmpl (optional) Forces a mobile version of the approval page. The only accepted value is "mobile". This is a Google-specific parameter.

    OAuth 1.0 sample request

    This example shows a request for authorization:

    GET https://www.google.com/accounts/OAuthAuthorizeToken?oauth_token=ab3cd9j4ks73hf7g&hd=mycollege.edu&hl=en&btmpl=mobile
    

    OAuth 1.0 request authorization response

    If Google accepts the request, the user is redirected to a Google login page, where:

    1. The user is asked to verify access to their Google account. Because it's possible for someone to have more than one Google-affiliated account (a regular Google account and one or more hosted accounts), in some cases the user also must specify which account to grant access to. There are two possible paths your users may experience:
      • If you've used the hd parameter to specify an account domain, the user is asked to log in to that account, if they aren't already logged in. For more information on the hd parameter, see Handling users with multiple accounts.
      • If you don't use the hd parameter, the user is put into a "universal login" path, which walks the user through selecting and logging into any type of Google account. Because the universal login process is still in beta, we recommend you use the hd parameter whenever possible. We're continuing to improve the user experience in this area.
    2. Once the user has selected an account and verified access, the Authorization service displays the Google Access Request page (see example). This page:
      • Identifies the third-party application requesting access. By default, Google uses the value of xoauth_displayname in the initial OAuthGetRequestToken request and displays a message indicating that the application's identity cannot be verified. If no display name is specified and the application is registered with Google, Google uses the name specified during registration. If the application is not registered, Google uses the oauth_callback URL, if set; if it is not set, Google uses the string anonymous.
      • Informs the user that a third party wants access to their Google service.
      • Identifies the Google service(s) to be accessed.
      • Prompts the user to confirm that it's OK to give the third party access to their Google service.
    3. If the user grants access, the referenced request token is authorized.
    4. If a callback URL is provided, Google redirects the user to the URL specified in the web application registration, and the request token and verification number are included as query parameters. If no callback URL is provided, Google displays a message to the user with a verification code (see example).

    Note: The return of a verification code does not indicate that a request token has been authorized. If a request token has not been authorized, then requests to exchange it for an access token will fail.

    OAuth 1.0 sample response

    This example illustrates the format of a Google redirect back to the web application with a request token and verification code. The token is a text string, up to 256 bytes.

    http://www.example.com/showcalendar.html?oauth_token=CKF50YzIHxCT85KMAg&oauth_verifier=fERNOO3NfWph90CPCeIutmFA

    Google redirects with token and verifier regardless of whether the token has been authorized.

    OAuthGetAccessToken

    Contact Google to exchange an authorized request token for an access token. The access token received in response to this request is used to request data from a Google service.

    Send an HTTP request to: https://www.google.com/accounts/OAuthGetAccessToken with the following query parameters:

    Parameter Description
    oauth_consumer_key (required) Domain identifying the third-party web application. This is the domain used when registering the application with Google. This value must be the same as the one provided in OAuthGetRequestToken.
    oauth_token (required) Authorized request token.
    oauth_verifier (required) Verification code issued by Google in response to a successful call to OAuthAuthorizeToken. The verification code is either returned as a query parameter in the redirect URL or is displayed in a web page shown to the user once access has been granted, which the user must supply to the application in some way.
    oauth_signature_method (required) Signature algorithm. The legal values for this parameter "RSA-SHA1" or "HMAC-SHA1". Google does not support "PLAINTEXT".
    oauth_signature (required) String generated using the referenced signature method. See Signing requests.
    oauth_timestamp (required) Integer representing the time the request is sent. The timestamp should be expressed in number of seconds after January 1, 1970 00:00:00 GMT.
    oauth_nonce (required) Random 64-bit, unsigned number encoded as an ASCII string in decimal format. The nonce/timestamp pair should always be unique to prevent replay attacks.
    oauth_version (optional) The OAuth version used by the requesting web application. This value must be "1.0"; if not provided, Google assumes version 1.0 is in use.

    Depending on the type of request sent, these parameters can be placed in:

    • Authorization header of a GET or POST request. Use "Authorization: OAuth".
    • Body of a POST request. The content type must be "Content-Type: application/x-www-form-urlencoded".
    • URL query part of a GET request.

    For more details, see the OAuth specification, Section 5.2.

    OAuth 1.0 sample request

    This example illustrates a web application requesting an access token.

    POST /accounts/OAuthGetAccessToken HTTP/1.1
    Host: www.google.com
    Content-Type: application/x-www-form-urlencoded
    Authorization: OAuth
    oauth_consumer_key="example.com",
    oauth_token="CKF50YzIHxCT85KMAg",
    oauth_verifier="fERNOO3NfWph90CPCeIutmFA",
    oauth_signature_method="RSA-SHA1",
    oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
    oauth_timestamp="137131200",
    oauth_nonce="4572616e48616d6d65724c61686176",
    oauth_version="1.0"

    Note: The Authorization should be contained on a single line. Newlines have been inserted for clarity.

    OAuth 1.0 access token response

    If the request for an access token is successful, Google responds with an HTTP 200 OK message containing an OAuth access token and a token "secret".

    A token request may be rejected by Google if the request is malformed or if Google has reason to believe the requestor is not acting in good faith. If the request is not successful, Google returns the following error:

    • HTTP 400 Bad Request:in the case of an unsupported or missing parameter, an unsupported signature method, or other error in the request format or content. This error is also returned if the referenced request token has not been authorized.

    OAuth 1.0 sample response

    This example illustrates an OAuth access token returned in the response header.

    oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=ZXhhbXBsZS5jb20

    Signing OAuth 1.0 requests (deprecated)

    All calls requesting or using an OAuth token must be signed, regardless of whether your application is registered with Google or not. This includes calls to OAuthGetRequestToken, OAuthGetAccessToken, and all requests made to Google services. This section describes how to generate a signature for the requests. For more detailed information on this process, see the OAuth specification, Section 9.

    Each request must specify the signature method in use (oauth_signature_method). Unregistered applications should use HMAC-SHA1. Registered applications can use either RSA-SHA1 and HMAC-SHA1.

    1. Construct a signature "base string", which consists of a concatenation of three request elements:
      • The HTTP request method.
      • The base URL the request is being sent to. This URL should not include any query parameters. When signing calls to Google services, refer to the OAuth specification, Section 9.1.2, for relevant instructions.
      • A normalized string of the parameters in the request (excluding the oauth_signature parameter). This includes parameters sent in the request header or body, as well as query parameters added to the request URL. To normalize the string, sort the parameters using lexicographical byte value ordering. For more details on normalizing this string, see Section 9.1.1 of the OAuth specification.
    2. Generate an oauth_signature using one of the following sequences:
      • If your application is not registered, select HMAC-SHA1 and use the following key and secret:
        consumer key: anonymous
        consumer secret: anonymous
      • If your application is registered and you're using RSA-SHA1, use the private key corresponding to the certificate uploaded to Google during registration.
      • If your application is registered and you're using HMAC-SHA1, use the OAuth "consumer secret" value generated during registration; this value is displayed on your domain's registration page.

    OAuth 1.0 example requests

    This example shows a registered application using the Google Calendar API to retrieve a user's list of calendars at http://www.google.com/calendar/feeds/default/allcalendars/full?orderby=starttime. The example assumes you have a valid OAuth access token.

    Signature base string:

    GET&http%3A%2F%2Fwww.google.com%2Fcalendar%2Ffeeds%2Fdefault%2Fallcalendars%2Ffull&oauth_consumer_key%3Dexample.com%26oauth_nonce%3D4572616e48616d6d65724c61686176%26oauth_signature_method%3DRSA-SHA1%26oauth_timestamp%3D137131200%26oauth_token%3D1%252Fab3cd9j4ks73hf7g%26oauth_version%3D1.0%26orderby%3Dstarttime
      

    Notice the orderby=starttime query parameter is ordered along with the rest of the oauth_* parameters in the base string.

    HTTP Request:

    GET /calendar/feeds/default/allcalendars/full?orderby=starttime HTTP/1.1
    Host: www.google.com
    Content-Type: application/atom+xml
    Authorization: OAuth
    oauth_token="1%2Fab3cd9j4ks73hf7g",
    oauth_signature_method="RSA-SHA1",
    oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
    oauth_consumer_key="example.com",
    oauth_timestamp="137131200",
    oauth_nonce="4572616e48616d6d65724c61686176",
    oauth_version="1.0"  

    Note: The Authorization should be contained on a single line. Newlines have been inserted for clarity only. The ordering of the oauth_* parameters does not matter in the Authorization header.

    Handling users with multiple accounts (deprecated)

    In most cases, the process of getting access confirmation from an end user is a simple matter of the user logging into their account and choosing whether or not to grant access. For users who have more than one Google Account, however, (a regular Google account and/or one or more hosted accounts), users may need to follow additional "universal login" steps to identify which account they wish to grant access to.

    In certain circumstances, using the hd parameter with OauthAuthorizeToken can help streamline your users' experience. If your application is designed for one particular managed domain, you can eliminate the extra login steps by using this parameter to specify the only domain that's valid for your application. You can also use the hd parameter if your application accesses services that are not available to hosted accounts; setting the value to 'default' will limit authorization to regular accounts only. Using this parameter helps limit the account choices for the user, preventing them from making invalid choices.

    Testing and debugging OAuth 1.0 requests (deprecated)

    Google's OAuth Playground tool helps to debug problems, check your own implementation, and experiment with the Google Data APIs.

    • Illustrates the OAuth authorization flow:
      • Fetches a request token
      • Authorizes a request token
      • Upgrades the token to an access token.
    • Helps with debugging OAuth requests:
      • Displays the correct signature base string for each request.
      • Displays the correct Authorization header for each request.
      • Demonstrates how to use an oauth_token to interact with an authorized Google Data feed.
      • Tests your own oauth_consumer_key (your registered domain), RSA private key, and HMAC consumer secret.
    • Lets you experiment with the Google Data APIs:
      • Uses GET, PUT/POST, or DELETE to manipulate data.
      • Allows you to view an authorized feed directly in your browser.
      • Identifies what Data feeds are available to your oauth_token.

    More debugging tips are available in Using OAuth with the Google Data APIs.

    Revoking an OAuth 1.0 access token (deprecated)

    OAuth access tokens can be revoked either manually or programmatically.

    To manually revoke an OAuth 1.0 token (for Google account holders):

    1. Users can make changes to their Google Accounts settings at https://www.google.com/accounts/. For Google Apps (hosted) domain accounts, go to https://www.google.com/a/yourdomain.com/ManageAccount.
    2. Click the link "Change authorized websites".
    3. In the list of authorized domains displayed, locate the domain to be revoked. Click the "Revoke Access" link next to the domain name.

    Access to the user account for that domain will no longer be allowed. Users must explicitly approve subsequent access requests, using the same process as they originally granted access.

    To programmatically revoke an OAuth 1.0 token (for third-party applications), send a request to AuthSub's AuthSubRevokeToken endpoint (deprecated) with the necessary signed OAuth request.

    Authentication required

    You need to be signed in with Google+ to do that.

    Signing you in...

    Google Developers needs your permission to do that.