Errors may happen in different layers. You may get notified in different ways
dependent on where the error happens.
Missing Required OAuth Parameters
If you forget to set the required OAuth parameters, such as the client_id or
scope, you’ll see an error message like below in your browser’s JavaScript
Console.
Fix OAuth Configuration Errors
Changes in the Google APIs console
may be required to resolve some errors.
- Creates a client ID
if not yet. - For popup UX, add all domains that may trigger the current flow to
Authorized JavaScript origins
. - For redirect UX, add all URLs that may receive authorization responses to
Authorized redirect URIs
. - Properly configure your OAuth Consent screen.
- Submit your app for verification
if needed. - You might need to take additional steps to comply with Google’s OAuth 2.0 Policies.
Invalid OAuth Parameter Values
If you set the invalid values to OAuth parameters, such as the invalid client id
, scope identifiers, or response type values, you’ll see the OAuth error page.
OAuth Error Responses
OAuth may return an error response, in which case your
callback
function will be triggered with the error response as the parameter.
The following is an example OAuth error response.
{ "error":"access_denied" }
Some examples are listed as below.
- The user denies the OAuth request.
- For an OAuth request with
prompt=none
parameter, the user is not already authenticated and has not pre-configured
consent for the requested scopes.
The example below shows how to handle the success and error OAuth responses.
function myCallback(response) {
if (response.error) {
// Handle error response
... ...
} else if (response.code) {
// Handle success code response
... ...
}
}
Non-OAuth Errors
OAuth doesn’t define the behaviors when:
- the popup window fails to open.
- the popup window is closed before an OAuth response is returned.
This library captures these errors, and triggers the
error_callback
if set. Be sure to check the error type like below. Otherwise, your code logic
may be affected when this library support new error types later.
function myErrorCallback(err) {
if (err.type == 'popup_failed_to_open') {
// The popup window is failed to open
... ...
} else if (err.type == 'popup_closed') {
// The popup window is closed before an OAuth response is returned
... ...
}
}
const client = google.accounts.oauth2.initCodeClient({
client_id: 'YOUR_GOOGLE_CLIENT_ID',
scope: 'https://www.googleapis.com/auth/calendar.readonly',
ux_mode: 'popup',
callback: myCallback,
error_callback: myErrorCallback
});
During the authorization process, Google OAuth may return an error. Use this
guide to troubleshoot the most common errors during this process.
Troubleshooting
To learn more about Google OAuth, see Using OAuth 2.0 to Access Google
APIs.
Access denied
If you’ve set up your OAuth consent screen in GCP and
the User type is External, you will get an «Access denied» error if you
attempt to account link with a Google account that is not listed as a test user
for your app. Make sure to add the Google account to the Test users section
in your OAuth consent screen.
Partner Connections Manager (PCM) error
For help with any errors encountered when accessing
PCM, see
Partner Connections Manager (PCM)
Error Reference.
Google hasn’t verified this app
The SDM API uses a restricted scope, which means that any
apps that use this scope during authorization will be «unverified» unless
OAuth API Verification is completed. When using Device Access for
personal use, OAuth API Verification is not required.
You may see a «Google hasn’t verified this app» screen during the authorization
process, which appears if the sdm.service
scope is not configured on
your OAuth consent screen in GCP. This screen can be
bypassed by clicking the Advanced option and then clicking Go to Project
Name (unsafe).
See Unverified app
screen
for more information.
Invalid client
When attempting to get an access or refresh token, you will get an «Invalid
client» error if you provide an incorrect OAuth 2.0 Client Secret. Make sure the
client_secret
value you’re using in access and refresh token calls is the one
for the OAuth 2.0 Client ID being used, as found in your
GCP
Credentials
page.
Invalid request, missing required scope
After granting permissions in PCM, you might run into a
«Invalid request» error of «Missing required parameter: scope». Make sure the
scope
value you’re using in authorization calls is the same as the one you set for the OAuth 2.0 Client,
as found in your GCP
Credentials
page.
Redirect uri mismatch
When going through authorization, you might run into a «Redirect uri mismatch»
error. Make sure the redirect_uri
value you’re using in authorization calls is
the same as the one you set for the OAuth 2.0 Client, as found in your
GCP
Credentials
page.
Quick reference
Use this reference to quickly implement the steps to authorize a
user and link their Google account
.
To use this quick reference, edit each placeholder variable in the code samples
with the values for your specific integration, and copy and paste as needed:
1 PCM
Direct the user to the PCM link in your
app, replacing:
- project-id with your Device Access Project ID
- oauth2-client-id with the OAuth2 Client ID from your
Google Cloud Platform (GCP)
Credentials - redirect-uri with a Redirect URI specified for the
OAuth2 Client ID you are using - scope with one of your available
scopes
https://nestservices.google.com/partnerconnections/project-id/auth?redirect_uri=redirect-uri&access_type=offline&prompt=consent&client_id=oauth2-client-id&response_type=code&scope=https://www.googleapis.com/auth/scope
2 Auth Code
After granting permissions through PCM for
your selected scope, the user should be redirected to your specified Redirect
URI. The Authorization Code is returned as the code
parameter in the URL,
which should be in this format:
redirect-uri?code=authorization-code&scope=https://www.googleapis.com/auth/scope
3 Access Token
Use the authorization code to retrieve an access token, that
you can use to call the SDM API on
behalf of the user.
Make a POST call to Google’s OAuth
endpoint, replacing:
- oauth2-client-id and oauth2-client-secret
with the OAuth2 Client ID and Client Secret from your
GCP
Credentials - authorization-code with the code you received in the previous step
- redirect-uri with a Redirect URI specified for the
OAuth2 Client ID you are using
Google OAuth returns two tokens, an access token and a
refresh token.
Request
curl -L -X POST 'https://www.googleapis.com/oauth2/v4/token?client_id=oauth2-client-id&client_secret=oauth2-client-secret&code=authorization-code&grant_type=authorization_code&redirect_uri=redirect-uri'
Response
{"access_token": "access-token",
"expires_in": 3599,
"refresh_token": "refresh-token",
"scope": "https://www.googleapis.com/auth/scope",
"token_type": "Bearer" }
4 API Call
Authorization is not complete until you make
an API call with the user’s access token. This
initial call finishes the authorization process and enables events.
You must use one of the
API calls listed for the specified scope to complete authorization.
sdm.service
devices
See the
devices.list
API reference for more information.
curl -X GET 'https://smartdevicemanagement.googleapis.com/v1/enterprises/project-id/devices'
-H 'Content-Type: application/json'
-H 'Authorization: Bearer access-token'
5 Refresh Token
Access tokens for the SDM API are only
valid for 1 hour, as noted in the expires_in
parameter returned by Google OAuth. If
your access token expires, use the refresh token to get a new one.
Make a POST call to Google’s OAuth
endpoint, replacing:
- oauth2-client-id and oauth2-client-secret
with the OAuth2 Client ID and Client Secret from your
GCP
Credentials - refresh-token with the code you received when initially getting the access
token.
Google OAuth returns a new access token.
Request
curl -L -X POST 'https://www.googleapis.com/oauth2/v4/token?client_id=oauth2-client-id&client_secret=oauth2-client-secret&refresh_token=refresh-token&grant_type=refresh_token'
Response
{"access_token": "new-access-token",
"expires_in": 3599,
"scope": "https://www.googleapis.com/auth/scope",
"token_type": "Bearer" }
This document explains how web server applications use Google API Client Libraries or Google
OAuth 2.0 endpoints to implement OAuth 2.0 authorization to access
Google APIs.
OAuth 2.0 allows users to share specific data with an application while keeping their
usernames, passwords, and other information private.
For example, an application can use OAuth 2.0 to obtain permission from
users to store files in their Google Drives.
This OAuth 2.0 flow is specifically for user authorization. It is designed for applications
that can store confidential information and maintain state. A properly authorized web server
application can access an API while the user interacts with the application or after the user
has left the application.
Web server applications frequently also use
service accounts to authorize API requests, particularly when calling Cloud APIs to access
project-based data rather than user-specific data. Web server applications can use service
accounts in conjunction with user authorization.
Client libraries
The language-specific examples on this page use
Google API Client Libraries to implement
OAuth 2.0 authorization. To run the code samples, you must first install the
client library for your language.
When you use a Google API Client Library to handle your application’s OAuth 2.0 flow, the client
library performs many actions that the application would otherwise need to handle on its own. For
example, it determines when the application can use or refresh stored access tokens as well as
when the application must reacquire consent. The client library also generates correct redirect
URLs and helps to implement redirect handlers that exchange authorization codes for access tokens.
Google API Client Libraries for server-side applications are available for the following languages:
- Go
- Java
- .NET
- Node.js
- PHP
- Python
- Ruby
Prerequisites
Enable APIs for your project
Any application that calls Google APIs needs to enable those APIs in the
API Console.
To enable an API for your project:
- Open the API Library in the
Google API Console. - If prompted, select a project, or create a new one.
- The API Library lists all available APIs, grouped by product
family and popularity. If the API you want to enable isn’t visible in the list, use search to
find it, or click View All in the product family it belongs to. - Select the API you want to enable, then click the Enable button.
- If prompted, enable billing.
- If prompted, read and accept the API’s Terms of Service.
Create authorization credentials
Any application that uses OAuth 2.0 to access Google APIs must have authorization credentials
that identify the application to Google’s OAuth 2.0 server. 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.
- Go to the Credentials page.
- Click Create credentials > OAuth client ID.
- Select the Web application application type.
- Fill in the form and click Create. Applications that use languages and frameworks
like PHP, Java, Python, Ruby, and .NET must specify authorized redirect URIs. The
redirect URIs are the endpoints to which the OAuth 2.0 server can send responses. These
endpoints must adhere to Google’s validation rules.For testing, you can specify URIs that refer to the local machine, such as
http://localhost:8080
. With that in mind, please note that all of the
examples in this document usehttp://localhost:8080
as the redirect URI.We recommend that you design your app’s auth endpoints so
that your application does not expose authorization codes to other resources on the
page.
After creating your credentials, download the client_secret.json file from the
API Console. Securely store the file in a location that only
your application can access.
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.0 authorization, we recommend that you identify the scopes
that your app will need permission to access.
We also recommend that your application request access to authorization scopes via an
incremental authorization process, in which your application
requests access to user data in context. This best practice helps users to more easily understand
why your application needs the access it is requesting.
The OAuth 2.0 API Scopes document contains a full
list of scopes that you might use to access Google APIs.
Language-specific requirements
To run any of the code samples in this document, you’ll need a Google account, access to the
Internet, and a web browser. If you are using one of the API client libraries, also see the
language-specific requirements below.
PHP
To run the PHP code samples in this document, you’ll need:
- PHP 5.6 or greater with the command-line interface (CLI) and JSON extension installed.
- The Composer dependency management tool.
-
The Google APIs Client Library for PHP:
composer require google/apiclient:^2.10
Python
To run the Python code samples in this document, you’ll need:
- Python 2.6 or greater
- The pip package management tool.
- The Google APIs Client Library for Python:
pip install --upgrade google-api-python-client
- The
google-auth
,google-auth-oauthlib
, and
google-auth-httplib2
for user authorization.pip install --upgrade google-auth google-auth-oauthlib google-auth-httplib2
- The Flask Python web application framework.
pip install --upgrade flask
- The
requests
HTTP library.pip install --upgrade requests
Ruby
To run the Ruby code samples in this document, you’ll need:
- Ruby 2.2.2 or greater
-
The Google APIs Client Library for Ruby:
gem install google-api-client
-
The Sinatra Ruby web application framework.
gem install sinatra
Node.js
To run the Node.js code samples in this document, you’ll need:
- The maintenance LTS, active LTS, or current release of Node.js.
-
The Google APIs Node.js Client:
npm install googleapis
HTTP/REST
You do not need to install any libraries to be able to directly call the OAuth 2.0
endpoints.
Obtaining OAuth 2.0 access tokens
The following steps show how your application interacts with Google’s OAuth 2.0 server to obtain
a user’s consent to perform an API request on the user’s behalf. Your application must have that
consent before it can execute a Google API request that requires user authorization.
The list below quickly summarizes these steps:
- Your application identifies the permissions it needs.
- Your application redirects the user to Google along with the list of requested
permissions. - The user decides whether to grant the permissions to your application.
- Your application finds out what the user decided.
- If the user granted the requested permissions, your application retrieves tokens needed to
make API requests on the user’s behalf.
Step 1: Set authorization parameters
Your first step is to create the authorization request. That request sets parameters that
identify your application and define the permissions that the user will be asked to grant to
your application.
- If you use a Google client library for OAuth 2.0 authentication and authorization, you
create and configure an object that defines these parameters. - If you call the Google OAuth 2.0 endpoint directly, you’ll generate a URL and set the
parameters on that URL.
The tabs below define the supported authorization parameters for web server applications. The
language-specific examples also show how to use a client library or authorization library to
configure an object that sets those parameters.
PHP
The code snippet below creates a GoogleClient()
object, which defines the
parameters in the authorization request.
That object uses information from your client_secret.json file to identify your
application. (See creating authorization credentials for more about
that file.) The object also identifies the scopes that your application is requesting permission
to access and the URL to your application’s auth endpoint, which will handle the response from
Google’s OAuth 2.0 server. Finally, the code sets the optional access_type
and
include_granted_scopes
parameters.
For example, this code requests read-only, offline access to a user’s
Google Drive:
$client = new GoogleClient(); $client->setAuthConfig('client_secret.json'); $client->addScope(GoogleServiceDrive::DRIVE_METADATA_READONLY); $client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php'); // offline access will give you both an access and refresh token so that // your app can refresh the access token without user interaction. $client->setAccessType('offline'); // Using "consent" ensures that your application always receives a refresh token. // If you are not using offline access, you can omit this. $client->setApprovalPrompt('consent'); $client->setIncludeGrantedScopes(true); // incremental auth
The request specifies the following information:
Parameters | |||||||
---|---|---|---|---|---|---|---|
client_id |
Required
The client ID for your application. You can find this value in the In PHP, call the $client = new GoogleClient(); $client->setAuthConfig('client_secret.json'); |
||||||
redirect_uri |
Required
Determines where the API server redirects the user after the user completes the Note that the To set this value in PHP, call the $client->setRedirectUri('https://oauth2.example.com/code'); |
||||||
scope |
Required
A Scopes enable your application to only request access to the resources that it needs To set this value in PHP, call the $client->addScope(GoogleServiceDrive::DRIVE_METADATA_READONLY); We recommend that your application request access to authorization scopes in context |
||||||
access_type |
Recommended
Indicates whether your application can refresh access tokens when the user is not present Set the value to To set this value in PHP, call the $client->setAccessType('offline'); |
||||||
state |
Recommended
Specifies any string value that your application uses to maintain state between your You can use this parameter for several purposes, such as directing the user to the To set this value in PHP, call the $client->setState($sample_passthrough_value); |
||||||
include_granted_scopes |
Optional
Enables applications to use incremental authorization to request access to additional To set this value in PHP, call the $client->setIncludeGrantedScopes(true); |
||||||
login_hint |
Optional
If your application knows which user is trying to authenticate, it can use this parameter Set the parameter value to an email address or To set this value in PHP, call the $client->setLoginHint('None'); |
||||||
prompt |
Optional
A space-delimited, case-sensitive list of prompts to present the user. If you don’t To set this value in PHP, call the $client->setApprovalPrompt('consent'); Possible values are:
|
Python
The following code snippet uses the google-auth-oauthlib.flow
module to construct
the authorization request.
The code constructs a Flow
object, which identifies your application using
information from the client_secret.json file that you downloaded after
creating authorization credentials. That object also identifies the
scopes that your application is requesting permission to access and the URL to your application’s
auth endpoint, which will handle the response from Google’s OAuth 2.0 server. Finally, the code
sets the optional access_type
and include_granted_scopes
parameters.
For example, this code requests read-only, offline access to a user’s
Google Drive:
import google.oauth2.credentials import google_auth_oauthlib.flow # Use the client_secret.json file to identify the application requesting # authorization. The client ID (from that file) and access scopes are required. flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( 'client_secret.json', scopes=['https://www.googleapis.com/auth/drive.metadata.readonly']) # Indicate where the API server will redirect the user after the user completes # the authorization flow. The redirect URI is required. The value must exactly # match one of the authorized redirect URIs for the OAuth 2.0 client, which you # configured in the API Console. If this value doesn't match an authorized URI, # you will get a 'redirect_uri_mismatch' error. flow.redirect_uri = 'https://www.example.com/oauth2callback' # Generate URL for request to Google's OAuth 2.0 server. # Use kwargs to set optional request parameters. authorization_url, state = flow.authorization_url( # Enable offline access so that you can refresh an access token without # re-prompting the user for permission. Recommended for web server apps. access_type='offline', # Enable incremental authorization. Recommended as a best practice. include_granted_scopes='true')
The request specifies the following information:
Parameters | |||||||
---|---|---|---|---|---|---|---|
client_id |
Required
The client ID for your application. You can find this value in the In Python, call the flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( 'client_secret.json', scopes=['https://www.googleapis.com/auth/drive.metadata.readonly']) |
||||||
redirect_uri |
Required
Determines where the API server redirects the user after the user completes the Note that the To set this value in Python, set the flow.redirect_uri = 'https://oauth2.example.com/code' |
||||||
scope |
Required
A list of scopes that identify the resources that your application could access on the Scopes enable your application to only request access to the resources that it needs In Python, use the same method you use to set the flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( 'client_secret.json', scopes=['https://www.googleapis.com/auth/drive.metadata.readonly']) We recommend that your application request access to authorization scopes in context |
||||||
access_type |
Recommended
Indicates whether your application can refresh access tokens when the user is not present Set the value to In Python, set the authorization_url, state = flow.authorization_url( access_type='offline', include_granted_scopes='true') |
||||||
state |
Recommended
Specifies any string value that your application uses to maintain state between your You can use this parameter for several purposes, such as directing the user to the In Python, set the authorization_url, state = flow.authorization_url( access_type='offline', state=sample_passthrough_value, include_granted_scopes='true') |
||||||
include_granted_scopes |
Optional
Enables applications to use incremental authorization to request access to additional In Python, set the authorization_url, state = flow.authorization_url( access_type='offline', include_granted_scopes='true') |
||||||
login_hint |
Optional
If your application knows which user is trying to authenticate, it can use this parameter Set the parameter value to an email address or In Python, set the authorization_url, state = flow.authorization_url( access_type='offline', login_hint='None', include_granted_scopes='true') |
||||||
prompt |
Optional
A space-delimited, case-sensitive list of prompts to present the user. If you don’t In Python, set the authorization_url, state = flow.authorization_url( access_type='offline', prompt='consent', include_granted_scopes='true') Possible values are:
|
Ruby
Use the client_secrets.json file that you created to configure a client object in your
application. When you configure a client object, you specify the scopes your application needs to
access, along with the URL to your application’s auth endpoint, which will handle the response
from the OAuth 2.0 server.
For example, this code requests read-only, offline access to a user’s
Google Drive:
require 'google/apis/drive_v2' require 'google/api_client/client_secrets' client_secrets = Google::APIClient::ClientSecrets.load auth_client = client_secrets.to_authorization auth_client.update!( :scope => 'https://www.googleapis.com/auth/drive.metadata.readonly', :redirect_uri => 'http://www.example.com/oauth2callback', :additional_parameters => { "access_type" => "offline", # offline access "include_granted_scopes" => "true" # incremental auth } )
Your application uses the client object to perform OAuth 2.0 operations, such as generating
authorization request URLs and applying access tokens to HTTP requests.
Node.js
The code snippet below creates a google.auth.OAuth2
object, which defines the
parameters in the authorization request.
That object uses information from your client_secret.json file to identify your application.
To ask for permissions from a user to retrieve an access token, you redirect them to a consent page.
To create a consent page URL:
const {google} = require('googleapis'); /** * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI * from the client_secret.json file. To get these credentials for your application, visit * https://console.cloud.google.com/apis/credentials. */ const oauth2Client = new google.auth.OAuth2( YOUR_CLIENT_ID, YOUR_CLIENT_SECRET, YOUR_REDIRECT_URL ); // Access scopes for read-only Drive activity. const scopes = [ 'https://www.googleapis.com/auth/drive.metadata.readonly' ]; // Generate a url that asks permissions for the Drive activity scope const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', /** Pass in the scopes array defined above. * Alternatively, if only one scope is needed, you can pass a scope URL as a string */ scope: scopes, // Enable incremental authorization. Recommended as a best practice. include_granted_scopes: true });
Important Note — The refresh_token
is only returned on the first
authorization. More details
here.
HTTP/REST
Google’s OAuth 2.0 endpoint is at https://accounts.google.com/o/oauth2/v2/auth
. This
endpoint is accessible only over HTTPS. Plain HTTP connections are refused.
The Google authorization server supports the following query string parameters for web
server applications:
Parameters | |||||||
---|---|---|---|---|---|---|---|
client_id |
Required
The client ID for your application. You can find this value in the |
||||||
redirect_uri |
Required
Determines where the API server redirects the user after the user completes the Note that the |
||||||
response_type |
Required
Determines whether the Google OAuth 2.0 endpoint returns an authorization code. Set the parameter value to |
||||||
scope |
Required
A Scopes enable your application to only request access to the resources that it needs We recommend that your application request access to authorization scopes in context |
||||||
access_type |
Recommended
Indicates whether your application can refresh access tokens when the user is not present Set the value to |
||||||
state |
Recommended
Specifies any string value that your application uses to maintain state between your You can use this parameter for several purposes, such as directing the user to the |
||||||
include_granted_scopes |
Optional
Enables applications to use incremental authorization to request access to additional |
||||||
login_hint |
Optional
If your application knows which user is trying to authenticate, it can use this parameter Set the parameter value to an email address or |
||||||
prompt |
Optional
A space-delimited, case-sensitive list of prompts to present the user. If you don’t Possible values are:
|
Step 2: Redirect to Google’s OAuth 2.0 server
Redirect the user to Google’s OAuth 2.0 server to initiate the authentication and
authorization process. Typically, this occurs when your application first needs to access the
user’s data. In the case of incremental authorization, this
step also occurs when your application first needs to access additional resources that it does
not yet have permission to access.
PHP
- Generate a URL to request access from Google’s OAuth 2.0 server:
$auth_url = $client->createAuthUrl();
- Redirect the user to
$auth_url
:header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));
Python
This example shows how to redirect the user to the authorization URL using the Flask web
application framework:
return flask.redirect(authorization_url)
Ruby
- Generate a URL to request access from Google’s OAuth 2.0 server:
auth_uri = auth_client.authorization_uri.to_s
- Redirect the user to
auth_uri
.
Node.js
-
Use the generated URL
authorizationUrl
from Step 1
generateAuthUrl
method to request access from Google’s OAuth 2.0 server. -
Redirect the user to
authorizationUrl
.res.writeHead(301, { "Location": authorizationUrl });
HTTP/REST
An example URL is shown below, with line breaks and spaces for readability.
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& access_type=offline& include_granted_scopes=true& response_type=code& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
After you create the request URL, redirect the user to it.
Google’s OAuth 2.0 server authenticates the user and obtains consent from the user for your
application to access the requested scopes. The response is sent back to your application
using the redirect URL you specified.
Step 3: 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 and
a summary of the scopes of access to be granted. The
user can then consent to grant access to one or more scopes requested by your application or
refuse the request.
Your application doesn’t need to do anything at this stage as it waits for the response from
Google’s OAuth 2.0 server indicating whether any access was granted. That response is explained in
the following step.
Errors
Requests to Google’s OAuth 2.0 authorization endpoint may display user-facing error messages
instead of the expected authentication and authorization flows. Common error codes and suggested
resolutions are listed below.
admin_policy_enforced
The Google Account is unable to authorize one or more scopes requested due to the policies of
their Google Workspace administrator. See the Google Workspace Admin help article
Control which third-party & internal apps access Google Workspace data
for more information about how an administrator may restrict access to all scopes or sensitive and
restricted scopes until access is explicitly granted to your OAuth client ID.
disallowed_useragent
The authorization endpoint is displayed inside an embedded user-agent disallowed by Google’s
OAuth 2.0 Policies.
Android
Android developers may encounter this error message when opening authorization requests in
android.webkit.WebView
.
Developers should instead use Android libraries such as
Google Sign-In for Android or OpenID Foundation’s
AppAuth for Android.
Web developers may encounter this error when an Android app opens a general web link in an
embedded user-agent and a user navigates to Google’s OAuth 2.0 authorization endpoint from
your site. Developers should allow general links to open in the default link handler of the
operating system, which includes both
Android App Links
handlers or the default browser app. The
Android Custom Tabs
library is also a supported option.
iOS
iOS and macOS developers may encounter this error when opening authorization requests in
WKWebView
.
Developers should instead use iOS libraries such as
Google Sign-In for iOS or OpenID Foundation’s
AppAuth for iOS.
Web developers may encounter this error when an iOS or macOS app opens a general web link in
an embedded user-agent and a user navigates to Google’s OAuth 2.0 authorization endpoint from
your site. Developers should allow general links to open in the default link handler of the
operating system, which includes both
Universal Links
handlers or the default browser app. The
SFSafariViewController
library is also a supported option.
org_internal
The OAuth client ID in the request is part of a project limiting access to Google Accounts in a
specific
Google Cloud Organization.
For more information about this configuration option see the
User type
section in the Setting up your OAuth consent screen help article.
redirect_uri_mismatch
The redirect_uri
passed in the authorization request does not match an authorized
redirect URI for the OAuth client ID. Review authorized redirect URIs in the
Google API Console Credentials page.
Step 4: Handle the OAuth 2.0 server response
The OAuth 2.0 server responds to your application’s access request by using the URL specified
in the request.
If the user approves the access request, then the response contains an authorization code. If
the user does not approve the request, the response contains an error message. The
authorization code or error message that is returned to the web server appears on the query
string, as shown below:
An error response:
https://oauth2.example.com/auth?error=access_denied
An authorization code response:
https://oauth2.example.com/auth?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7
Sample OAuth 2.0 server response
You can test this flow by clicking on the following sample URL, which requests
read-only access to view metadata for files in your Google Drive:
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& access_type=offline& include_granted_scopes=true& response_type=code& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
After completing the OAuth 2.0 flow, you should be redirected to
http://localhost/oauth2callback
, which will likely yield a
404 NOT FOUND
error unless your local machine serves a file at that address. The
next step provides more detail about the information returned in the URI when the user is
redirected back to your application.
Step 5: Exchange authorization code for refresh and access
tokens
After the web server receives the authorization code, it can exchange the authorization code
for an access token.
PHP
To exchange an authorization code for an access token, use the authenticate
method:
$client->authenticate($_GET['code']);
You can retrieve the access token with the getAccessToken
method:
$access_token = $client->getAccessToken();
Python
On your callback page, use the google-auth
library to verify the authorization
server response. Then, use the flow.fetch_token
method to exchange the authorization
code in that response for an access token:
state = flask.session['state'] flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( 'client_secret.json', scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'], state=state) flow.redirect_uri = flask.url_for('oauth2callback', _external=True) authorization_response = flask.request.url flow.fetch_token(authorization_response=authorization_response) # Store the credentials in the session. # ACTION ITEM for developers: # Store user's access and refresh tokens in your data store if # incorporating this code into your real app. credentials = flow.credentials flask.session['credentials'] = { 'token': credentials.token, 'refresh_token': credentials.refresh_token, 'token_uri': credentials.token_uri, 'client_id': credentials.client_id, 'client_secret': credentials.client_secret, 'scopes': credentials.scopes}
Ruby
To exchange an authorization code for an access token, use the fetch_access_token!
method:
auth_client.code = auth_code auth_client.fetch_access_token!
Node.js
To exchange an authorization code for an access token, use the getToken
method:
const url = require('url'); // Receive the callback from Google's OAuth 2.0 server. if (req.url.startsWith('/oauth2callback')) { // Handle the OAuth 2.0 server response let q = url.parse(req.url, true).query; // Get access and refresh tokens (if access_type is offline) let { tokens } = await oauth2Client.getToken(q.code); oauth2Client.setCredentials(tokens); }
HTTP/REST
To exchange an authorization code for an access token, call the
https://oauth2.googleapis.com/token
endpoint and set the following parameters:
Fields | |
---|---|
client_id |
The client ID obtained from the API Console Credentials page. |
client_secret |
The client secret obtained from the API Console Credentials page. |
code |
The authorization code returned from the initial request. |
grant_type |
As defined in the OAuth 2.0 specification, this field’s value must be set to authorization_code . |
redirect_uri |
One of the redirect URIs listed for your project in the API Console Credentials page for the given client_id . |
The following snippet shows a sample request:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7& client_id=your_client_id& client_secret=your_client_secret& redirect_uri=https%3A//oauth2.example.com/code& grant_type=authorization_code
Google responds to this request by returning a JSON object that contains a short-lived access
token and a refresh token.
Note that the refresh token is only returned if your application set the access_type
parameter to offline
in the initial request to Google’s
authorization server.
The response contains the following fields:
Fields | |
---|---|
access_token |
The token that your application sends to authorize a Google API request. |
expires_in |
The remaining lifetime of the access token in seconds. |
refresh_token |
A token that you can use to obtain a new access token. Refresh tokens are valid until the user revokes access. Again, this field is only present in this response if you set the |
scope |
The scopes of access granted by the access_token expressed as a list ofspace-delimited, case-sensitive strings. |
token_type |
The type of token returned. At this time, this field’s value is always set toBearer . |
The following snippet shows a sample response:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/drive.metadata.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
Calling Google APIs
PHP
Use the access token to call Google APIs by completing the following steps:
- If you need to apply an access token to a new
GoogleClient
object — for
example, if you stored the access token in a user session — use the
setAccessToken
method:$client->setAccessToken($access_token);
- Build a service object for the API that you want to call. You build a service object by
providing an authorizedGoogleClient
object to the constructor for the API you
want to call.
For example, to call the Drive API:$drive = new GoogleServiceDrive($client);
- Make requests to the API service using the
interface provided by the service object.For example, to list the files in the authenticated user’s Google Drive:
$files = $drive->files->listFiles(array())->getItems();
Python
After obtaining an access token, your application can use that token to authorize API requests on
behalf of a given user account or service account. Use the user-specific authorization credentials
to build a service object for the API that you want to call, and then use that object to make
authorized API requests.
- Build a service object for the API that you want to call. You build a service object by
calling thegoogleapiclient.discovery
library’sbuild
method with the
name and version of the API and the user credentials:For example, to call version 2 of the Drive API:
from googleapiclient.discovery import build drive = build('drive', 'v2', credentials=credentials)
- Make requests to the API service using the
interface provided by the service object.For example, to list the files in the authenticated user’s Google Drive:
files = drive.files().list().execute()
Ruby
Use the auth_client
object to call Google APIs by completing the following
steps:
- Build a service object for the API that you want to call.
For example, to call version 2 of the Drive API:
drive = Google::Apis::DriveV2::DriveService.new
- Set the credentials on the service:
drive.authorization = auth_client
- Make requests to the API service using the
interface
provided by the service object.For example, to list the files in the authenticated user’s Google Drive:
files = drive.list_files
Alternately, authorization can be provided on a per-method basis by supplying the
options
parameter to a method:
files = drive.list_files(options: { authorization: auth_client })
Node.js
After obtaining an access token and setting it to the OAuth2
object, use the object
to call Google APIs. Your application can use that token to authorize API requests on behalf of
a given user account or service account. Build a service object for the API that you want to call.
const { google } = require('googleapis'); // Example of using Google Drive API to list filenames in user's Drive. const drive = google.drive('v3'); drive.files.list({ auth: oauth2Client, pageSize: 10, fields: 'nextPageToken, files(id, name)', }, (err1, res1) => { if (err1) return console.log('The API returned an error: ' + err1); const files = res1.data.files; if (files.length) { console.log('Files:'); files.map((file) => { console.log(`${file.name} (${file.id})`); }); } else { console.log('No files found.'); } });
HTTP/REST
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 if the scope(s) of access required by the API have been granted. To do this, include
the access token in a request to the API by including either an access_token
query
parameter or an Authorization
HTTP header Bearer
value. 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 Files API).
You can try out all the Google APIs and view their scopes at the
OAuth 2.0 Playground.
HTTP GET examples
A call to the
drive.files
endpoint (the Drive Files API) using the Authorization: Bearer
HTTP
header might look like the following. Note that you need to specify your own access token:
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Here is a call to the same API for the authenticated user using the access_token
query string parameter:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl
examples
You can test these commands with the curl
command-line application. Here’s an
example that uses the HTTP header option (preferred):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Or, alternatively, the query string parameter option:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
Complete example
The following example prints a JSON-formatted list of files in a user’s Google Drive after the
user authenticates and gives consent for the application to access the user’s Drive metadata.
PHP
To run this example:
- In the API Console, add the URL of the local machine to the
list of redirect URLs. For example, addhttp://localhost:8080
. - Create a new directory and change to it. For example:
mkdir ~/php-oauth2-example cd ~/php-oauth2-example
- Install the Google API Client
Library for PHP using Composer:composer require google/apiclient:^2.10
- Create the files
index.php
andoauth2callback.php
with the content
below. - Run the example with a web server configured to serve PHP. If you use PHP 5.6 or newer, you
can use PHP’s built-in test web server:php -S localhost:8080 ~/php-oauth2-example
index.php
<?php require_once __DIR__.'/vendor/autoload.php'; session_start(); $client = new GoogleClient(); $client->setAuthConfig('client_secrets.json'); $client->addScope(GoogleServiceDrive::DRIVE_METADATA_READONLY); if (isset($_SESSION['access_token']) && $_SESSION['access_token']) { $client->setAccessToken($_SESSION['access_token']); $drive = new GoogleServiceDrive($client); $files = $drive->files->listFiles(array())->getItems(); echo json_encode($files); } else { $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php'; header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL)); }
oauth2callback.php
<?php require_once __DIR__.'/vendor/autoload.php'; session_start(); $client = new GoogleClient(); $client->setAuthConfigFile('client_secrets.json'); $client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php'); $client->addScope(GoogleServiceDrive::DRIVE_METADATA_READONLY); if (! isset($_GET['code'])) { $auth_url = $client->createAuthUrl(); header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL)); } else { $client->authenticate($_GET['code']); $_SESSION['access_token'] = $client->getAccessToken(); $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/'; header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL)); }
Python
This example uses the Flask framework. It
runs a web application at http://localhost:8080
that lets you test the OAuth 2.0
flow. If you go to that URL, you should see four links:
- Test an API request: This link points to a page that tries to execute a sample API
request. If necessary, it starts the authorization flow. If successful, the page displays the
API response. - Test the auth flow directly: This link points to a page that tries to send the user
through the authorization flow. The app requests permission to
submit authorized API requests on the user’s behalf. - Revoke current credentials: This link points to a page that
revokes permissions that the user has already granted to the application. - Clear Flask session credentials: This link clears authorization credentials that are
stored in the Flask session. This lets you see what would happen if a user who had already
granted permission to your app tried to execute an API request in a new session. It also lets
you see the API response your app would get if a user had revoked permissions granted to your
app, and your app still tried to authorize a request with a revoked access token.
# -*- coding: utf-8 -*- import os import flask import requests import google.oauth2.credentials import google_auth_oauthlib.flow import googleapiclient.discovery # This variable specifies the name of a file that contains the OAuth 2.0 # information for this application, including its client_id and client_secret. CLIENT_SECRETS_FILE = "client_secret.json" # This OAuth 2.0 access scope allows for full read/write access to the # authenticated user's account and requires requests to use an SSL connection. SCOPES = ['https://www.googleapis.com/auth/drive.metadata.readonly'] API_SERVICE_NAME = 'drive' API_VERSION = 'v2' app = flask.Flask(__name__) # Note: A secret key is included in the sample so that it works. # If you use this code in your application, replace this with a truly secret # key. See https://flask.palletsprojects.com/quickstart/#sessions. app.secret_key = 'REPLACE ME - this value is here as a placeholder.' @app.route('/') def index(): return print_index_table() @app.route('/test') def test_api_request(): if 'credentials' not in flask.session: return flask.redirect('authorize') # Load credentials from the session. credentials = google.oauth2.credentials.Credentials( **flask.session['credentials']) drive = googleapiclient.discovery.build( API_SERVICE_NAME, API_VERSION, credentials=credentials) files = drive.files().list().execute() # Save credentials back to session in case access token was refreshed. # ACTION ITEM: In a production app, you likely want to save these # credentials in a persistent database instead. flask.session['credentials'] = credentials_to_dict(credentials) return flask.jsonify(**files) @app.route('/authorize') def authorize(): # Create flow instance to manage the OAuth 2.0 Authorization Grant Flow steps. flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( CLIENT_SECRETS_FILE, scopes=SCOPES) # The URI created here must exactly match one of the authorized redirect URIs # for the OAuth 2.0 client, which you configured in the API Console. If this # value doesn't match an authorized URI, you will get a 'redirect_uri_mismatch' # error. flow.redirect_uri = flask.url_for('oauth2callback', _external=True) authorization_url, state = flow.authorization_url( # Enable offline access so that you can refresh an access token without # re-prompting the user for permission. Recommended for web server apps. access_type='offline', # Enable incremental authorization. Recommended as a best practice. include_granted_scopes='true') # Store the state so the callback can verify the auth server response. flask.session['state'] = state return flask.redirect(authorization_url) @app.route('/oauth2callback') def oauth2callback(): # Specify the state when creating the flow in the callback so that it can # verified in the authorization server response. state = flask.session['state'] flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( CLIENT_SECRETS_FILE, scopes=SCOPES, state=state) flow.redirect_uri = flask.url_for('oauth2callback', _external=True) # Use the authorization server's response to fetch the OAuth 2.0 tokens. authorization_response = flask.request.url flow.fetch_token(authorization_response=authorization_response) # Store credentials in the session. # ACTION ITEM: In a production app, you likely want to save these # credentials in a persistent database instead. credentials = flow.credentials flask.session['credentials'] = credentials_to_dict(credentials) return flask.redirect(flask.url_for('test_api_request')) @app.route('/revoke') def revoke(): if 'credentials' not in flask.session: return ('You need to <a href="/authorize">authorize</a> before ' + 'testing the code to revoke credentials.') credentials = google.oauth2.credentials.Credentials( **flask.session['credentials']) revoke = requests.post('https://oauth2.googleapis.com/revoke', params={'token': credentials.token}, headers = {'content-type': 'application/x-www-form-urlencoded'}) status_code = getattr(revoke, 'status_code') if status_code == 200: return('Credentials successfully revoked.' + print_index_table()) else: return('An error occurred.' + print_index_table()) @app.route('/clear') def clear_credentials(): if 'credentials' in flask.session: del flask.session['credentials'] return ('Credentials have been cleared.<br><br>' + print_index_table()) def credentials_to_dict(credentials): return {'token': credentials.token, 'refresh_token': credentials.refresh_token, 'token_uri': credentials.token_uri, 'client_id': credentials.client_id, 'client_secret': credentials.client_secret, 'scopes': credentials.scopes} def print_index_table(): return ('<table>' + '<tr><td><a href="/test">Test an API request</a></td>' + '<td>Submit an API request and see a formatted JSON response. ' + ' Go through the authorization flow if there are no stored ' + ' credentials for the user.</td></tr>' + '<tr><td><a href="/authorize">Test the auth flow directly</a></td>' + '<td>Go directly to the authorization flow. If there are stored ' + ' credentials, you still might not be prompted to reauthorize ' + ' the application.</td></tr>' + '<tr><td><a href="/revoke">Revoke current credentials</a></td>' + '<td>Revoke the access token associated with the current user ' + ' session. After revoking credentials, if you go to the test ' + ' page, you should see an <code>invalid_grant</code> error.' + '</td></tr>' + '<tr><td><a href="/clear">Clear Flask session credentials</a></td>' + '<td>Clear the access token currently stored in the user session. ' + ' After clearing the token, if you <a href="/test">test the ' + ' API request</a> again, you should go back to the auth flow.' + '</td></tr></table>') if __name__ == '__main__': # When running locally, disable OAuthlib's HTTPs verification. # ACTION ITEM for developers: # When running in production *do not* leave this option enabled. os.environ['OAUTHLIB_INSECURE_TRANSPORT'] = '1' # Specify a hostname and port that are set as a valid redirect URI # for your API project in the Google API Console. app.run('localhost', 8080, debug=True)
Ruby
This example uses the Sinatra framework.
require 'google/apis/drive_v2' require 'google/api_client/client_secrets' require 'json' require 'sinatra' enable :sessions set :session_secret, 'setme' get '/' do unless session.has_key?(:credentials) redirect to('/oauth2callback') end client_opts = JSON.parse(session[:credentials]) auth_client = Signet::OAuth2::Client.new(client_opts) drive = Google::Apis::DriveV2::DriveService.new files = drive.list_files(options: { authorization: auth_client }) "<pre>#{JSON.pretty_generate(files.to_h)}</pre>" end get '/oauth2callback' do client_secrets = Google::APIClient::ClientSecrets.load auth_client = client_secrets.to_authorization auth_client.update!( :scope => 'https://www.googleapis.com/auth/drive.metadata.readonly', :redirect_uri => url('/oauth2callback')) if request['code'] == nil auth_uri = auth_client.authorization_uri.to_s redirect to(auth_uri) else auth_client.code = request['code'] auth_client.fetch_access_token! auth_client.client_secret = nil session[:credentials] = auth_client.to_json redirect to('/') end end
Node.js
To run this example:
-
In the API Console, add the URL of the
local machine to the list of redirect URLs. For example, add
http://localhost
. -
Make sure you have maintenance LTS, active LTS, or current release of
Node.js installed. -
Create a new directory and change to it. For example:
mkdir ~/nodejs-oauth2-example cd ~/nodejs-oauth2-example
-
Install the
Google API Client
Library
for Node.js using npm:npm install googleapis
-
Create the files
main.js
with the content below. -
Run the example:
node .main.js
main.js
const http = require('http'); const https = require('https'); const url = require('url'); const { google } = require('googleapis'); /** * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI. * To get these credentials for your application, visit * https://console.cloud.google.com/apis/credentials. */ const oauth2Client = new google.auth.OAuth2( YOUR_CLIENT_ID, YOUR_CLIENT_SECRET, YOUR_REDIRECT_URL ); // Access scopes for read-only Drive activity. const scopes = [ 'https://www.googleapis.com/auth/drive.metadata.readonly' ]; // Generate a url that asks permissions for the Drive activity scope const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', /** Pass in the scopes array defined above. * Alternatively, if only one scope is needed, you can pass a scope URL as a string */ scope: scopes, // Enable incremental authorization. Recommended as a best practice. include_granted_scopes: true }); /* Global variable that stores user credential in this code example. * ACTION ITEM for developers: * Store user's refresh token in your data store if * incorporating this code into your real app. * For more information on handling refresh tokens, * see https://github.com/googleapis/google-api-nodejs-client#handling-refresh-tokens */ let userCredential = null; async function main() { const server = http.createServer(async function (req, res) { // Example on redirecting user to Google's OAuth 2.0 server. if (req.url == '/') { res.writeHead(301, { "Location": authorizationUrl }); } // Receive the callback from Google's OAuth 2.0 server. if (req.url.startsWith('/oauth2callback')) { // Handle the OAuth 2.0 server response let q = url.parse(req.url, true).query; if (q.error) { // An error response e.g. error=access_denied console.log('Error:' + q.error); } else { // Get access and refresh tokens (if access_type is offline) let { tokens } = await oauth2Client.getToken(q.code); oauth2Client.setCredentials(tokens); /** Save credential to the global variable in case access token was refreshed. * ACTION ITEM: In a production app, you likely want to save the refresh token * in a secure persistent database instead. */ userCredential = tokens; // Example of using Google Drive API to list filenames in user's Drive. const drive = google.drive('v3'); drive.files.list({ auth: oauth2Client, pageSize: 10, fields: 'nextPageToken, files(id, name)', }, (err1, res1) => { if (err1) return console.log('The API returned an error: ' + err1); const files = res1.data.files; if (files.length) { console.log('Files:'); files.map((file) => { console.log(`${file.name} (${file.id})`); }); } else { console.log('No files found.'); } }); } } // Example on revoking a token if (req.url == '/revoke') { // Build the string for the POST request let postData = "token=" + userCredential.access_token; // Options for POST request to Google's OAuth 2.0 server to revoke a token let postOptions = { host: 'oauth2.googleapis.com', port: '443', path: '/revoke', method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', 'Content-Length': Buffer.byteLength(postData) } }; // Set up the request const postReq = https.request(postOptions, function (res) { res.setEncoding('utf8'); res.on('data', d => { console.log('Response: ' + d); }); }); postReq.on('error', error => { console.log(error) }); // Post the request with data postReq.write(postData); postReq.end(); } res.end(); }).listen(80); } main().catch(console.error);
HTTP/REST
This Python example uses the Flask framework
and the Requests library to demonstrate the OAuth
2.0 web flow. We recommend using the Google API Client Library for Python for this flow. (The
example in the Python tab does use the client library.)
import json import flask import requests app = flask.Flask(__name__) CLIENT_ID = '123456789.apps.googleusercontent.com' CLIENT_SECRET = 'abc123' # Read from a file or environmental variable in a real app SCOPE = 'https://www.googleapis.com/auth/drive.metadata.readonly' REDIRECT_URI = 'http://example.com/oauth2callback' @app.route('/') def index(): if 'credentials' not in flask.session: return flask.redirect(flask.url_for('oauth2callback')) credentials = json.loads(flask.session['credentials']) if credentials['expires_in'] <= 0: return flask.redirect(flask.url_for('oauth2callback')) else: headers = {'Authorization': 'Bearer {}'.format(credentials['access_token'])} req_uri = 'https://www.googleapis.com/drive/v2/files' r = requests.get(req_uri, headers=headers) return r.text @app.route('/oauth2callback') def oauth2callback(): if 'code' not in flask.request.args: auth_uri = ('https://accounts.google.com/o/oauth2/v2/auth?response_type=code' '&client_id={}&redirect_uri={}&scope={}').format(CLIENT_ID, REDIRECT_URI, SCOPE) return flask.redirect(auth_uri) else: auth_code = flask.request.args.get('code') data = {'code': auth_code, 'client_id': CLIENT_ID, 'client_secret': CLIENT_SECRET, 'redirect_uri': REDIRECT_URI, 'grant_type': 'authorization_code'} r = requests.post('https://oauth2.googleapis.com/token', data=data) flask.session['credentials'] = r.text return flask.redirect(flask.url_for('index')) if __name__ == '__main__': import uuid app.secret_key = str(uuid.uuid4()) app.debug = False app.run()
Redirect URI validation rules
Google applies the following validation rules to redirect URIs in order to help developers
keep their applications secure. Your redirect URIs must adhere to these rules. See
RFC 3986 section 3 for the
definition of domain, host, path, query, scheme and userinfo, mentioned below.
Validation rules | |
---|---|
Scheme |
Redirect URIs must use the HTTPS scheme, not plain HTTP. Localhost URIs (including |
Host |
Hosts cannot be raw IP addresses. Localhost IP addresses are exempted from this rule. |
Domain |
(Top Level Domains) must belong to the public suffix list. “googleusercontent.com” .goo.gl ) unlessthe app owns the domain. Furthermore, if an app that owns a shortener domain chooses to redirect to that domain, that redirect URI must either contain “/google-callback/” in its path or end with“/google-callback” . |
Userinfo |
Redirect URIs cannot contain the userinfo subcomponent. |
Path |
Redirect URIs cannot contain a path traversal (also called directory backtracking), |
Query |
Redirect URIs cannot contain |
Fragment |
Redirect URIs cannot contain the fragment component. |
Characters |
Redirect URIs cannot contain certain characters including:
|
Incremental authorization
In the OAuth 2.0 protocol, your app requests authorization to access resources, which are
identified by scopes. It is considered a best user-experience practice to request authorization
for resources at the time you need them. To enable that practice, Google’s authorization server
supports incremental authorization. This feature lets you request scopes as they are needed and,
if the user grants permission for the new scope, returns an authorization code that may be
exchanged for a token containing all scopes the user has granted the project.
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 openid
and
profile
scopes to perform basic sign-in, and then later request the
https://www.googleapis.com/auth/drive.file
scope at the time of the first request to save a
mix.
To implement incremental authorization, you complete the normal flow for requesting an access
token but make sure that the authorization request includes previously granted scopes. This
approach allows your app to avoid having to manage multiple access tokens.
The following rules apply to an access token obtained from an incremental authorization:
- The token can be used to access resources corresponding to any of the scopes rolled into the
new, combined authorization. - When you use the refresh token for the combined authorization to obtain an access token, the
access token represents the combined authorization and can be used for any of the
scope
values included in the response. - The combined authorization includes all scopes that the user granted to the API project even
if the grants were requested from different clients. For example, if a user granted access to
one scope using an application’s desktop client and then granted another scope to the same
application via a mobile client, the combined authorization would include both scopes. - If you revoke a token that represents a combined authorization, access to all of that
authorization’s scopes on behalf of the associated user are revoked simultaneously.
The language-specific code samples in Step 1: Set authorization
parameters and the sample HTTP/REST redirect URL in Step 2:
Redirect to Google’s OAuth 2.0 server all use incremental authorization. The code samples
below also show the code that you need to add to use incremental authorization.
PHP
$client->setIncludeGrantedScopes(true);
Python
In Python, set the include_granted_scopes
keyword argument to true
to
ensure that an authorization request includes previously granted scopes. It is very possible that
include_granted_scopes
will not be the only keyword argument that you set, as
shown in the example below.
authorization_url, state = flow.authorization_url( # Enable offline access so that you can refresh an access token without # re-prompting the user for permission. Recommended for web server apps. access_type='offline', # Enable incremental authorization. Recommended as a best practice. include_granted_scopes='true')
Ruby
auth_client.update!( :additional_parameters => {"include_granted_scopes" => "true"} )
Node.js
const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', /** Pass in the scopes array defined above. * Alternatively, if only one scope is needed, you can pass a scope URL as a string */ scope: scopes, // Enable incremental authorization. Recommended as a best practice. include_granted_scopes: true });
HTTP/REST
GET https://accounts.google.com/o/oauth2/v2/auth? client_id=your_client_id& response_type=code& state=state_parameter_passthrough_value& scope=https%3A//www.googleapis.com/auth/drive.file& redirect_uri=https%3A//oauth2.example.com/code& prompt=consent& include_granted_scopes=true
Refreshing an access token (offline access)
Access tokens periodically expire and become invalid credentials for a related API request. You
can refresh an access token without prompting the user for permission (including when the user is
not present) if you requested offline access to the scopes associated with the token.
-
If you use a Google API Client Library, the client object refreshes
the access token as needed as long as you configure that object for offline access. - If you are not using a client library, you need to set the
access_type
HTTP
query parameter tooffline
when redirecting the user to
Google’s OAuth 2.0 server. In that case, Google’s authorization server returns a
refresh token when you exchange an authorization
code for an access token. Then, if the access token expires (or at any other time), you
can use a refresh token to obtain a new access token.
Requesting offline access is a requirement for any application that needs to access a Google
API when the user is not present. For example, an app that performs backup services or
executes actions at predetermined times needs to be able to refresh its access token when the
user is not present. The default style of access is called online
.
Server-side web applications, installed applications, and devices all obtain refresh tokens
during the authorization process. Refresh tokens are not typically used in client-side
(JavaScript) web applications.
PHP
If your application needs offline access to a Google API, set the API client’s access type to
offline
:
$client->setAccessType("offline");
After a user grants offline access to the requested scopes, you can continue to use the API
client to access Google APIs on the user’s behalf when the user is offline. The client object
will refresh the access token as needed.
Python
In Python, set the access_type
keyword argument to offline
to ensure
that you will be able to refresh the access token without having to re-prompt the user for
permission. It is very possible that access_type
will not be the only keyword
argument that you set, as shown in the example below.
authorization_url, state = flow.authorization_url( # Enable offline access so that you can refresh an access token without # re-prompting the user for permission. Recommended for web server apps. access_type='offline', # Enable incremental authorization. Recommended as a best practice. include_granted_scopes='true')
After a user grants offline access to the requested scopes, you can continue to use the API
client to access Google APIs on the user’s behalf when the user is offline. The client object
will refresh the access token as needed.
Ruby
If your application needs offline access to a Google API, set the API client’s access type to
offline
:
auth_client.update!( :additional_parameters => {"access_type" => "offline"} )
After a user grants offline access to the requested scopes, you can continue to use the API
client to access Google APIs on the user’s behalf when the user is offline. The client object
will refresh the access token as needed.
Node.js
If your application needs offline access to a Google API, set the API client’s access type to
offline
:
const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', /** Pass in the scopes array defined above. * Alternatively, if only one scope is needed, you can pass a scope URL as a string */ scope: scopes, // Enable incremental authorization. Recommended as a best practice. include_granted_scopes: true });
After a user grants offline access to the requested scopes, you can continue to use the API
client to access Google APIs on the user’s behalf when the user is offline. The client object
will refresh the access token as needed.
Access tokens expire. This library will automatically use a refresh token to obtain a new access
token if it is about to expire. An easy way to make sure you always store the most recent tokens
is to use the tokens event:
oauth2Client.on('tokens', (tokens) => { if (tokens.refresh_token) { // store the refresh_token in your secure persistent database console.log(tokens.refresh_token); } console.log(tokens.access_token); });
This tokens event only occurs in the first authorization, and you need to have set your
access_type
to offline
when calling the generateAuthUrl
method to receive the refresh token. If you have already given your app the requisiste permissions
without setting the appropriate constraints for receiving a refresh token, you will need to
re-authorize the application to receive a fresh refresh token.
To set the refresh_token
at a later time, you can use the setCredentials
method:
oauth2Client.setCredentials({ refresh_token: `STORED_REFRESH_TOKEN` });
Once the client has a refresh token, access tokens will be acquired and refreshed automatically
in the next call to the API.
HTTP/REST
To refresh an access token, your application sends an HTTPS POST
request to Google’s authorization server (https://oauth2.googleapis.com/token
) that
includes the following parameters:
Fields | |
---|---|
client_id |
The client ID obtained from the API Console. |
client_secret |
The client secret obtained from the API Console. |
grant_type |
As defined in the OAuth 2.0 specification, this field’s value must be set to refresh_token . |
refresh_token |
The refresh token returned from the authorization code exchange. |
The following snippet shows a sample request:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=your_client_id& client_secret=your_client_secret& refresh_token=refresh_token& grant_type=refresh_token
As long as the user has not revoked the access granted to the application, the token server
returns a JSON object that contains a new access token. The following snippet shows a sample
response:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "scope": "https://www.googleapis.com/auth/drive.metadata.readonly", "token_type": "Bearer" }
Note that there are limits on the number of refresh tokens that will be issued; one limit per
client/user combination, and another per user across all clients. You should save refresh tokens
in long-term storage and continue to use them as long as they remain valid. If your application
requests too many refresh tokens, it may run into these limits, in which case older refresh tokens
will stop working.
Revoking a token
In some cases a user may wish to revoke access given to an application. A user can revoke access
by visiting
Account Settings. See the
Remove
site or app access section of the Third-party sites & apps with access to your account
support document for more information.
It is also possible for an application to programmatically revoke the access given to it.
Programmatic revocation is important in instances where a user unsubscribes, removes an
application, or the API resources required by an app have significantly changed. In other words,
part of the removal process can include an API request to ensure the permissions previously
granted to the application are removed.
PHP
To programmatically revoke a token, call revokeToken()
:
$client->revokeToken();
Python
To programmatically revoke a token, make a request to
https://oauth2.googleapis.com/revoke
that includes the token as a parameter and sets the
Content-Type
header:
requests.post('https://oauth2.googleapis.com/revoke', params={'token': credentials.token}, headers = {'content-type': 'application/x-www-form-urlencoded'})
Ruby
To programmatically revoke a token, make an HTTP request to the oauth2.revoke
endpoint:
uri = URI('https://oauth2.googleapis.com/revoke') response = Net::HTTP.post_form(uri, 'token' => auth_client.access_token)
The token can be an access token or a refresh token. If the token is an access token and it has
a corresponding refresh token, the refresh token will also be revoked.
If the revocation is successfully processed, then the status code of the response is
200
. For error conditions, a status code 400
is returned along with an
error code.
Node.js
To programmatically revoke a token, make an HTTPS POST request to /revoke
endpoint:
const https = require('https'); // Build the string for the POST request let postData = "token=" + userCredential.access_token; // Options for POST request to Google's OAuth 2.0 server to revoke a token let postOptions = { host: 'oauth2.googleapis.com', port: '443', path: '/revoke', method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', 'Content-Length': Buffer.byteLength(postData) } }; // Set up the request const postReq = https.request(postOptions, function (res) { res.setEncoding('utf8'); res.on('data', d => { console.log('Response: ' + d); }); }); postReq.on('error', error => { console.log(error) }); // Post the request with data postReq.write(postData); postReq.end();
The token parameter can be an access token or a refresh token. If the token is an access token and it has
a corresponding refresh token, the refresh token will also be revoked.
If the revocation is successfully processed, then the status code of the response is
200
. For error conditions, a status code 400
is returned along with an
error code.
HTTP/REST
To programmatically revoke a token, your application makes a request to
https://oauth2.googleapis.com/revoke
and includes the token as a parameter:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" https://oauth2.googleapis.com/revoke?token={token}
The token can be an access token or a refresh token. If the token is an access token and it has a
corresponding refresh token, the refresh token will also be revoked.
If the revocation is successfully processed, then the HTTP status code of the response is
200
. For error conditions, an HTTP status code 400
is returned along
with an error code.
This guide can help you troubleshoot issues you encounter while you use Sign in with Google to sign in to third-party apps or services. A third party is a company or developer that isn’t Google.
Some issues that cause an error message may be outside of Google’s control. For example, the app or service you want to use could be set up in an unsafe way that Google doesn’t allow. Error codes help you understand why you can’t sign in, so you can resolve the problem or contact the developer directly for a solution.
Tip: Sign in with Google offers many benefits, such as increased account security. Learn more about how Sign in with Google can improve your experiences online.
Sign in to your Google Account
- To use Sign in with Google, you must sign in to your Google Account.
- If you have trouble, go to Can’t sign in to your Google Account.
Troubleshoot account login issues
Important: Sign in with Google helps you sign in to a third-party app or service, but your Google Account and third-party account remain separate.
If you have an issue with Sign in with Google, find out whether the problem comes from your Google Account or the third-party account.
Account suspended or disabled
When you try to use Sign in with Google, you could get a message that your account is disabled or suspended. To fix the problem, first find out if your Google Account is disabled. If it’s not, the third party may have disabled your account on their site only.
- To find out whether your Google Account is disabled:
- Try to sign in to your Google Account. If your Google Account is disabled, when you try to sign in, you’ll get a message that says «Account disabled.»
- Check your logins to Google services. For example, if you can log in to the Gmail address of your Google Account, then your Google Account isn’t disabled.
- If you saved another email address in your Google Account, check there for an email that says your Google Account has been disabled.
- If your Google Account is disabled:
- Try to sign in to the app or service in another way.
- Ask the third party if you can use an email and password or another sign-in method.
- Learn how to restore your account.
- Try to sign in to the app or service in another way.
- If the third party suspends your account: To get help, contact the developer directly.
Account deleted
When a Google Account is deleted:
- Your Sign in with Google data is also deleted. That means you can no longer use the Sign in with Google button to sign in with the deleted account.
- Even if your Google Account is deleted, you may still be able to access your separate third-party account in another way. Try to sign in to the app or service with a username and password, or contact the developer directly.
When a third-party account is deleted:
- The third party doesn’t notify Google even if you used Sign in with Google to create that account. Your Google Account might still show the app or service is linked to your account.
- To understand how the third party handles your data, review their Terms of Service.
- Some third parties simply disable your account.
- Others delete your data from their service.
- If your data is deleted, you’ll need to create a new account on the app or service. You can still use Sign in with Google to do this, but you may need to use a different Google Account.
Can’t use Sign in with Google with a current third-party account
If you already have an account on an app or service and try to use Sign in with Google, you might get an error message.
Third-party services use Sign in with Google in different ways. Some services don’t support different sign-in methods for the same account. If you run into this issue, contact the developer directly.
Understand & fix error codes
If you’re signed in to your Google Account but still can’t use Sign in with Google, you might get an error code and message. You can use your code to find out what’s wrong and how to fix the problem.
Error code | Error message |
---|---|
400 invalid_request | Access blocked: App sent an invalid request. |
401 invalid_client | No registered origin. |
401 deleted_client | The OAuth client was deleted. |
403 invalid_account | Error message varies |
403 access_denied | Error message varies |
403 disallowed_useragent |
You can’t sign in from this screen because this app doesn’t comply with Google’s embedded webview policy. If this app has a website, you can open a web browser and try signing in from there. |
403 org_internal |
This client is restricted to users within its organization. |
403 restricted_client |
This app is not yet configured to make OAuth requests. To do that, set up the app’s OAuth consent screen in the Google Cloud Console. |
400 admin_policy_enforced | |
400 policy_enforced |
Advanced Protection prevented your Google Account from signing in. This security feature stops most non-Google apps and services from accessing your data to keep your account protected. |
400 origin_mismatch 400 redirect_uri_mismatch |
You can’t sign in to this app because it doesn’t comply with Google’s OAuth 2.0 policy. |
400 invalid_request
If you get an error that says “400 invalid_request” or “Access blocked: App sent an invalid request,” it means the app uses an authorization method that Google doesn’t allow.
Google has safe ways for you to sign in and share your Google Account data with third-party apps and sites. To help protect your account, Sign in with Google blocks apps that could put your account at risk.
Tip: Learn how Sign in with Google shares your data safely.
What can you do about this error?
Only the third-party developer can fix this issue. Contact the developer directly to tell them about the error.
401 errors
If you get an error that starts with “401,” that usually means the developer didn’t properly register their app with Google.
To help protect your account, before a third-party developer can use Sign in with Google, Google asks them to register their apps. We don’t share your info with the developer until they register with us. Some of the error messages you might get include:
- 401 invalid_client: Either the app doesn’t match the info on its registration or the developers haven’t given Google all the required info.
- 401 deleted_client: The app or service isn’t registered with Google anymore.
What can you do about this error?
Only the third-party developer can fix this issue. Contact the developer directly to tell them about the error.
403 invalid_account
If you get an error that says “403 invalid_account,” it may mean your Google Account is disabled.
What can you do about this error?
Check if your Google Account has been disabled.
If you find out your account is disabled, learn how to restore your account.
403 access_denied
If you get an error that says “403 access_denied,” either your Google Account can’t use the app or service or it can’t use Sign in with Google. Some reasons for this include:
- The app is in test mode and the developer hasn’t added you as a test user.
- The type of Google Account you’re signed in to doesn’t let you use Sign in with Google.
- For example, a child’s account can’t use Sign in with Google without a parent or guardian’s permission.
What can you do about this error?
- Use a different type of account to sign in to the app.
- If you believe your account should have access, contact the developer directly.
403 disallowed_useragent
If you get an error that says “403 disallowed_useragent,” the app uses embedded WebViews. Some developers use WebViews to help display web content in an app. Embedded WebViews puts your security at risk because they could let third parties access and change communications between you and Google.
To keep your account secure, Google no longer allows embedded WebViews as of September 30, 2021.
What can you do about this error?
Only the third-party developer can fix this issue on the app. Contact the developer directly to tell them about the error.
If the app has a website, you can try to sign in from your browser.
403 org_internal
If you get an error that says “403 org_internal,” it means that only members of a specific company or organization can use the app. For example, an organization might only allow email addresses that end in @example.com to access the app or service.
What can you do about this error?
If you’re a member of the organization, switch to your member account.
403 restricted_client
If you get an error that says “403 restricted_client,” it means the third-party app isn’t set up correctly to work with Sign in with Google. To help protect your account, Google asks third-party developers to follow certain security requirements.
What can you do about this error?
Only the third-party developer can fix this issue. Contact the developer directly to tell them about the error.
400 admin_policy_enforced
If you get an error that says “400 admin_policy_enforced” it means the administrator of your account doesn’t allow Sign in with Google. This can happen when you use an account from work or another organization. Sometimes only specific apps are blocked.
What can you do about this error?
If you believe you should have access to the app, reach out to your organization’s Google Workspace administrator.
400 policy_enforced
If you get an error that says “400 policy_enforced,” your Google Account may be part of the Advanced Protection Program. To help protect your account, this security feature doesn’t let most third-party apps or services access your Google Account data.
What can you do about this error?
To fix this error, you must opt out of the Advanced Protection Program. This means you’ll lose the program’s security benefits.
400 origin_mismatch or 400 redirect_uri_mismatch
If you get an error that says “400 origin_mismatch” or “400 redirect_uri_mismatch,” it may mean either:
- The app or service’s developer hasn’t set up their app correctly
- The app has tried to access your data in a way that doesn’t follow our policies
To help protect your account, before third parties can use Sign in with Google, we require them to register their app with us. They must also follow our security standards and policies. If an app doesn’t follow these policies, we won’t let it use Sign in with Google until the app developer fixes the problem.
What can you do about this error?
Only the third-party developer can fix this issue. Contact the developer directly to tell them about the error.
Fix other problems on a third-party app or service
Sometimes you can sign in to a third-party site with Google but you still can’t use the app or service. Google doesn’t fulfill the services offered by the third party, so most of the reasons this happens are outside Google’s control. We only help the app or site identify who you are.
Some examples of problems with an app or service might include:
- You bought a movie on a third-party service but can’t watch it.
- You can’t buy something on a third-party site.
- You can’t renew your subscription on a third party site.
If you have problems like these, contact the developer directly.
Contact a third-party app developer
To find contact info for a third-party developer:
- Go to the app or service.
- Select Sign in with Google.
- To get the Sign in with Google screen, you might need to sign out of the app or service.
- To get the developer’s email, at the top of the next screen, select the app or website name. In some cases, the developer’s email may not be available.
Secure a hacked or compromised account
- If you think someone has hacked into your Google Account: Follow the steps to secure a compromised Google Account.
- If your Google Account is hacked, someone else might be able to use your account to sign in to a third-party app or service. To strengthen your account security, turn on 2-Step Verification.
- Google helps keep your linked accounts safe with Cross-Account Protection. This program detects suspicious events and shares security notifications with compatible third-party apps and services connected to your Google Account.
- If you think someone hacked into your third-party account: Contact the developer directly.
Was this helpful?
How can we improve it?
You’re
viewing Apigee X documentation.
View Apigee Edge documentation.
This topic provides HTTP status codes and their related reason phrases you may encounter when
an OAuth policy throws errors in Apigee.
For guidance on handling errors, see Handling faults.
For policy-specific error codes, see
OAuth v2
policy error reference.
Invalid Redirect URI
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Invalid redirection uri http://www.invalid_example.com"}
No Redirect URI
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Redirection URI is required"}
Invalid Key
HTTP/1.1 401 Unauthorized {"ErrorCode" : "invalid_request", "Error" :"Invalid client id : AVD7ztXReEYyjpLFkkPiZpLEjeF2aYAz. ClientId is Invalid"}
Missing Key
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"The request is missing a required parameter : client_id"}
Invalid Response Type
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Response type must be code"}
Missing Response Type
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"The request is missing a required parameter : response_type"}
Generate AccessToken
Invalid Auth Code
HTTP status: 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Invalid Authorization Code"}
No Redirect URI
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Required param : redirect_uri"}
Invalid Redirect URI
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Invalid redirect_uri : oob"}
Invalid Client ID when
GenerateResponse is false
This error is returned when the <GenerateResponse>
property is set to
false and the client credentials are invalid.
{ "fault": { "faultstring": "Invalid client identifier {0}", "detail": { "errorcode": "oauth.v2.InvalidClientIdentifier" } } }
Invalid Client ID when
GenerateResponse is true
This error is returned when the <GenerateResponse>
property is set to
true and the client credentials are invalid.
{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}
Invalid GrantType
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Unsupported grant type : client_credentials_invalid"}
No Username
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Required param : username"}
No Password
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Required param : password"}
No GrantType (Custom Policy)
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Required param : grant_type"}
No AuthCode
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Required param : code"}
Implicit
Invalid Client ID
HTTP/1.1 401 Unauthorized {"ErrorCode" : "invalid_request", "Error" :"Invalid client id : AVD7ztXReEYyjpLFkkPiZpLEjeF2aYAz. ClientId is Invalid"}
No Client ID
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"The request is missing a required parameter : client_id"}
Invalid Response Type
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Response type must be token"}
No Response Type
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"The request is missing a required parameter : response_type"}
Invalid Redirect URI
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Invalid redirection uri http://www.invalid_example.com"}
No Redirect URI
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Redirection URI is required"}
Refresh Token
Invalid RefreshToken
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Invalid Refresh Token"}
Expired RefreshToken
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Refresh Token expired"}
Invalid Scope
HTTP/1.1 400 Bad Request {"ErrorCode" : "invalid_request", "Error" :"Invalid Scope"}
Invalid Client ID when
GenerateResponse is false
This error is returned when the GenerateResponse property is set to false and
the client credentials are invalid.
{ "fault": { "faultstring": "Invalid client identifier {0}", "detail": { "errorcode": "oauth.v2.InvalidClientIdentifier" } } }
Invalid Client ID when
GenerateResponse is true
This error is returned when the GenerateResponse property is set to true and
the client credentials are invalid.
{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}
Verify AccessToken
Invalid AccessToken
HTTP/1.1 401 Unauthorized {"fault":{"faultstring":"Invalid Access Token","detail":{"errorcode":"keymanagement.service.invalid_access_token"}}}
Invalid Resource
HTTP/1.1 401 Unauthorized {"fault":{"faultstring":"APIResource /facebook/acer does not exist","detail":{"errorcode":"keymanagement.service.apiresource_doesnot_exist"}}}
Invalid Scope
HTTP/1.1 403 Forbidden {"fault":{"faultstring":"Required scope(s) : VerifyAccessToken.scopeSet","detail":{"errorcode":"steps.oauth.v2.InsufficientScope"}}}
HTTP/1.1 401 Unauthorized {"fault":{"faultstring":"Invalid access token","detail":{"errorcode":"oauth.v2.InvalidAccessToken"}}}
No match for ApiProduct
(With Env & Proxy Configured)
HTTP/1.1 401 Unauthorized {"fault":{"faultstring":"Invalid API call as no apiproduct match found","detail":{"errorcode":"keymanagement.service.InvalidAPICallAsNoApiProductMatchFound"}}}
Access token expired
HTTP/1.1 401 Unauthorized {"fault":{"faultstring":"Access Token expired","detail":{"errorcode":"keymanagement.service.access_token_expired"}}}
Access token revoked
HTTP/1.1 401 Unauthorized {"fault":{"faultstring":"Access Token not approved","detail":{"errorcode":"keymanagement.service.access_token_not_approved"}}}
Get OAuth V2 Info
Invalid Refresh Token
HTTP/1.1 404 Not Found {"fault::{"detail":{"errorcode":"keymanagement.service.invalid_refresh_token"},"faultstring":"Invalid Refresh Token"}}
Invalid Access Token
HTTP/1.1 404 Not Found { "fault": { "faultstring": "Invalid Access Token", "detail": { "errorcode": "keymanagement.service.invalid_access_token" } } }
Expired Access Token
HTTP/1.1 500 Not Found { "fault": { "faultstring": "Access Token expired", "detail": { "errorcode": "keymanagement.service.access_token_expired" } } }
Expired Refresh Token
HTTP/1.1 500 Not Found { "fault": { "faultstring": "Refresh Token expired", "detail": { "errorcode": "keymanagement.service.refresh_token_expired" } } }
Invalid Client ID
HTTP/1.1 404 Not Found { "fault": { "faultstring": "Invalid Client Id", "detail": { "errorcode": "keymanagement.service.invalid_client-invalid_client_id" } } }
Invalid Authorization Code
HTTP/1.1 404 Not Found { "fault": { "faultstring": "Invalid Authorization Code", "detail": { "errorcode": "keymanagement.service.invalid_request-authorization_code_invalid" } } }
Expired Authorization Code
HTTP/1.1 500 Not Found { "fault": { "faultstring": "Authorization Code expired", "detail": { "errorcode": "keymanagement.service.authorization_code_expired" } } }
Set OAuth V2 Info
Invalid Access Token
HTTP/1.1 404 Not Found { "fault": { "faultstring": "Invalid Access Token", "detail": { "errorcode": "keymanagement.service.invalid_access_token" } } }
Expired Access Token
HTTP/1.1 500 Not Found { "fault": { "faultstring": "Access Token expired", "detail": { "errorcode": "keymanagement.service.access_token_expired" } } }
Delete OAuth V2 Info
On success, the policy returns a 200 status.
On failure, the policy returns 404 and output similar to the following (depending on whether
you are deleting an access token or an auth code):
HTTP/1.1 404 Not Found Content-Type: application/json Content-Length: 144 Connection: keep-alive {"fault":{"faultstring":"Invalid Authorization Code","detail":{"errorcode":"keymanagement.service.invalid_request-authorization_code_invalid"}}}
Вы создали проект в Google Cloud Platform. Создали Consent Screen для OAuth2.0 Client ID. Создали приложение, которое должно, используя SDK (допустим google-api-php-client ) запрашивать у пользователя разрешения. Однако пользователь видит вот такое сообщение.
Что это значит и что с этим делать.
Что значит Ошибка 403: access_denied для Google API
Дело в том, что проект в Google Cloud Platform по умолчанию находится в режиме тестирования. И чтобы пользоваться функционалом разных API Google требующего OAuth авторизации нужно либо пройти модерацию проекта в Google, либо добавить тестовых пользователей (аккаунты google этих пользователей) в специальный список тестеров для OAuth2.0 Client ID в раздел OAuth consent screen. Если этого не сделать или запрашивать разрешения у пользователя не из этого списка то как раз и будет появляться ошибка Ошибка 403: access_denied.
Как добавить тестового пользователя в OAuth2.0 Client ID
Открой раздел OAuth consent screen (ссылка вида
https://console.cloud.google.com/apis/credentials/consent?project=<твой проект> ) и найди кнопку Test Users
Добавь тестового юзера используя его емейл на домене gmail.com вида
some—user@gmail.com , чтобы получилось так:
Тогда этот пользователь при запросе разрешений из твоего разрешения перестанет получать ошибку Ошибка 403: access_denied. А вместо него будет вот такое окошко:
Оно как раз рассказывает пользователю, которого вы добавили в список тестеров, что приложение которое запрашивает у пользователя разрешения к его ресурсам не было проверено в Google и может быть не безопасно. То есть продакшен на широкую публику такого приложения вызывает большие сомнения.
Но если пользователь согласится, то:
Затем выбери нужные права
И все заработает. Только не забудь, что для каждого проекта есть лимит в 100 пользователей которые могут стать тестерами. И, самое главное, тестеров нельзя удалить из списка!
А ещё, если у вас на один аккаунт выданы разрешения на управление другими аккаунтами (например для YouTube), то достаточно добавить в тестеры такой метааккаунт чтобы получить доступ ко всем аккаунтам (каналам Youtube например) к которым имеет доступ такой аккаунт.