This document explains how web server applications use the Google API
Client Library for Python 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.
Prerequisites
Enable APIs for your project
Any application that calls Google APIs needs to enable those APIs in the
API Console. To enable the appropriate APIs for your project:
- Open the Library page in the
API Console.
- Select the project associated with your application. Create a project if
you do not have one already.
- Use the Library page to find each API that your application will
use. Click on each API and enable it for your project.
Create authorization credentials
Any application that uses OAuth 2.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.
- Open the Credentials page in the API Console.
- Click Create credentials > OAuth client ID.
- Complete the form. Set the application type to
Web
application. 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.
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 use
http://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.
Important: Do not store the
client_secret.json
file in a publicly-accessible location. In addition, if you share the source
code to your application—for example, on GitHub—store the
client_secret.json file outside of your source tree to avoid
inadvertently sharing your client credentials.
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.
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
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.
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',
scope=['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.
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 API Console.
In Python, call the <code><span>from_client_secrets_file</span></code> method to
retrieve the client ID from a <b>client_secret.json</b> file. (You can
also use the <code><span>from_client_config</span></code> method, which passes the
client configuration as it originally appeared in a client secrets file
but doesn't access the file itself.)
<pre class="prettyprint"><div class="devsite-code-button-wrapper"><div class="devsite-code-button gc-analytics-event material-icons devsite-dark-code-button" data-category="Site-Wide Custom Events" data-label="Dark Code Toggle" track-type="exampleCode" track-name="darkCodeToggle" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Dark code theme" aria-label="Dark code theme" data-title="Dark code theme"></div><div class="devsite-code-button gc-analytics-event material-icons devsite-click-to-copy-button" data-category="Site-Wide Custom Events" data-label="Click To Copy" track-type="exampleCode" track-name="clickToCopy" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Click to copy" aria-label="Click to copy" data-title="Click to copy"></div></div><span class="pln">flow </span><span class="pun">=</span><span class="pln"> google_auth_oauthlib</span><span class="pun">.</span><span class="pln">flow</span><span class="pun">.</span><span class="typ">Flow</span><span class="pun">.</span><span class="pln">from_client_secrets_file</span><span class="pun">(</span><span class="pln"><br> </span><b><span class="str">'client_secret.json'</span></b><span class="pun">,</span><span class="pln"><br> scope</span><span class="pun">=[</span><span class="str">'https://www.googleapis.com/auth/drive.metadata.readonly'</span><span class="pun">])</span></pre>
|
redirect_uri |
Required.
Determines where the API server redirects the user after the user
completes the authorization flow. The value must exactly match one of the
<code><span>redirect_uri</span></code> values listed for your project in the
<a href="https://console.developers.google.com/">API Console</a>. Note that the <code><span>http</span></code> or
<code><span>https</span></code> scheme, case, and trailing slash ('<code><span>/</span></code>')
must all match.
<br><br>
To set this value in Python, set the <code><span>flow</span></code> object's
<code><span>redirect_uri</span></code> property:
<pre class="prettyprint"><div class="devsite-code-button-wrapper"><div class="devsite-code-button gc-analytics-event material-icons devsite-dark-code-button" data-category="Site-Wide Custom Events" data-label="Dark Code Toggle" track-type="exampleCode" track-name="darkCodeToggle" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Dark code theme" aria-label="Dark code theme" data-title="Dark code theme"></div><div class="devsite-code-button gc-analytics-event material-icons devsite-click-to-copy-button" data-category="Site-Wide Custom Events" data-label="Click To Copy" track-type="exampleCode" track-name="clickToCopy" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Click to copy" aria-label="Click to copy" data-title="Click to copy"></div></div><span class="pln">flow</span><span class="pun">.</span><span class="pln">redirect_uri </span><span class="pun">=</span><span class="pln"> </span><span class="str">'https://www.example.com/oauth2callback'</span></pre>
</td>
|
scope |
Required. A
list of scopes that identify the
resources that your application could access on the user's behalf. These
values inform the consent screen that Google displays to the user.<br><br>
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 is an inverse
relationship between the number of scopes requested and the likelihood
of obtaining user consent.
In Python, use the same method you use to set the
<code><a href="#client_id"><span>client_id</span></a></code> to specify the list
of scopes.
<pre class="prettyprint"><div class="devsite-code-button-wrapper"><div class="devsite-code-button gc-analytics-event material-icons devsite-dark-code-button" data-category="Site-Wide Custom Events" data-label="Dark Code Toggle" track-type="exampleCode" track-name="darkCodeToggle" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Dark code theme" aria-label="Dark code theme" data-title="Dark code theme"></div><div class="devsite-code-button gc-analytics-event material-icons devsite-click-to-copy-button" data-category="Site-Wide Custom Events" data-label="Click To Copy" track-type="exampleCode" track-name="clickToCopy" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Click to copy" aria-label="Click to copy" data-title="Click to copy"></div></div><span class="pln">flow </span><span class="pun">=</span><span class="pln"> google_auth_oauthlib</span><span class="pun">.</span><span class="pln">flow</span><span class="pun">.</span><span class="typ">Flow</span><span class="pun">.</span><span class="pln">from_client_secrets_file</span><span class="pun">(</span><span class="pln"><br> </span><span class="str">'client_secret.json'</span><span class="pun">,</span><span class="pln"><br> </span><b><span class="pln">scope</span><span class="pun">=[</span><span class="str">'https://www.googleapis.com/auth/drive.metadata.readonly'</span><span class="pun">]</span></b><span class="pun">)</span></pre>
The <a href="https://developers.google.com/identity/protocols/googlescopes">OAuth 2.0 API Scopes</a>
document provides a full list of scopes that you might use to access
Google APIs.
<br><br>
We recommend that your application request access to authorization scopes
in context whenever possible. By requesting access to user data in context,
via <a href="#incrementalAuth">incremental authorization</a>,
you help users to more easily understand why your application needs the
access it is requesting.
|
access_type |
Recommended. Indicates whether your application can refresh
access tokens when the user is not present at the browser. Valid parameter
values are online, which is the default value, and
offline.
Set the value to offline if your application needs to refresh
access tokens when the user is not present at the browser. This is the
method of refreshing access tokens described later in this document. This
value instructs the Google authorization server to return a refresh token
and an access token the first time that your application exchanges
an authorization code for tokens.
<br><br>
In Python, set the <code><span>access_type</span></code> parameter by specifying
<code><span>access_type</span></code> as a keyword argument when calling the
<code><span>flow.<wbr>authorization_url</span></code> method:
<pre class="prettyprint"><div class="devsite-code-button-wrapper"><div class="devsite-code-button gc-analytics-event material-icons devsite-dark-code-button" data-category="Site-Wide Custom Events" data-label="Dark Code Toggle" track-type="exampleCode" track-name="darkCodeToggle" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Dark code theme" aria-label="Dark code theme" data-title="Dark code theme"></div><div class="devsite-code-button gc-analytics-event material-icons devsite-click-to-copy-button" data-category="Site-Wide Custom Events" data-label="Click To Copy" track-type="exampleCode" track-name="clickToCopy" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Click to copy" aria-label="Click to copy" data-title="Click to copy"></div></div><span class="pln">authorization_url</span><span class="pun">,</span><span class="pln"> state </span><span class="pun">=</span><span class="pln"> flow</span><span class="pun">.</span><span class="pln">authorization_url</span><span class="pun">(</span><span class="pln"><br> </span><b><span class="pln">access_type</span><span class="pun">=</span><span class="str">'offline'</span></b><span class="pun">,</span><span class="pln"><br> include_granted_scopes</span><span class="pun">=</span><span class="str">'true'</span><span class="pun">)</span></pre>
</td>
|
state |
Recommended. Specifies any string value that your application
uses to maintain state between your authorization request and the
authorization server's response. The server returns the exact value that
you send as a name=value pair in the hash
(#) fragment of the
redirect_uri after the user consents
to or denies your application's access request.
You can use this parameter for several purposes, such as directing the
user to the correct resource in your application, sending nonces, and
mitigating cross-site request forgery. Since your redirect_uri
can be guessed, using a state value can increase your
assurance that an incoming connection is the result of an authentication
request. If you generate a random string or encode the hash of a cookie or
another value that captures the client's state, you can validate the
response to additionally ensure that the request and response originated
in the same browser, providing protection against attacks such as
cross-site request forgery. See the OpenID Connect
documentation for an example of how to create and confirm a
state token.
<br><br>
In Python, set the <code><span>state</span></code> parameter by specifying
<code><span>state</span></code> as a keyword argument when calling the
<code><span>flow.<wbr>authorization_url</span></code> method:
<pre class="prettyprint"><div class="devsite-code-button-wrapper"><div class="devsite-code-button gc-analytics-event material-icons devsite-dark-code-button" data-category="Site-Wide Custom Events" data-label="Dark Code Toggle" track-type="exampleCode" track-name="darkCodeToggle" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Dark code theme" aria-label="Dark code theme" data-title="Dark code theme"></div><div class="devsite-code-button gc-analytics-event material-icons devsite-click-to-copy-button" data-category="Site-Wide Custom Events" data-label="Click To Copy" track-type="exampleCode" track-name="clickToCopy" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Click to copy" aria-label="Click to copy" data-title="Click to copy"></div></div><span class="pln">authorization_url</span><span class="pun">,</span><span class="pln"> state </span><span class="pun">=</span><span class="pln"> flow</span><span class="pun">.</span><span class="pln">authorization_url</span><span class="pun">(</span><span class="pln"><br> access_type</span><span class="pun">=</span><span class="str">'offline'</span><span class="pun">,</span><span class="pln"><br> </span><b><span class="pln">state</span><span class="pun">=</span><span class="pln">sample_passthrough_value</span></b><span class="pun">,</span><span class="pln"><br> include_granted_scopes</span><span class="pun">=</span><span class="str">'true'</span><span class="pun">)</span></pre>
</td>
|
include_granted_scopes |
Optional. Enables applications to use incremental authorization
to request access to additional scopes in context. If you set this
parameter's value to true and the authorization request is
granted, then the new access token will also cover any scopes to which the
user previously granted the application access. See the
incremental authorization section
for examples.
<br><br>
In Python, set the <code><span>include_granted_scopes</span></code> parameter by
specifying <code><span>include_granted_scopes</span></code> as a keyword argument
when calling the <code><span>flow.<wbr>authorization_url</span></code> method:
<pre class="prettyprint"><div class="devsite-code-button-wrapper"><div class="devsite-code-button gc-analytics-event material-icons devsite-dark-code-button" data-category="Site-Wide Custom Events" data-label="Dark Code Toggle" track-type="exampleCode" track-name="darkCodeToggle" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Dark code theme" aria-label="Dark code theme" data-title="Dark code theme"></div><div class="devsite-code-button gc-analytics-event material-icons devsite-click-to-copy-button" data-category="Site-Wide Custom Events" data-label="Click To Copy" track-type="exampleCode" track-name="clickToCopy" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Click to copy" aria-label="Click to copy" data-title="Click to copy"></div></div><span class="pln">authorization_url</span><span class="pun">,</span><span class="pln"> state </span><span class="pun">=</span><span class="pln"> flow</span><span class="pun">.</span><span class="pln">authorization_url</span><span class="pun">(</span><span class="pln"><br> access_type</span><span class="pun">=</span><span class="str">'offline'</span><span class="pun">,</span><span class="pln"><br> </span><b><span class="pln">include_granted_scopes</span><span class="pun">=</span><span class="str">'true'</span></b><span class="pun">)</span></pre>
</td>
|
login_hint |
Optional. If your application knows which user is trying to
authenticate, it can use this parameter to provide a hint to the Google
Authentication Server. The server uses the hint to simplify the login
flow either by prefilling the email field in the sign-in form or by
selecting the appropriate multi-login session.
Set the parameter value to an email address or sub
identifier, which is equivalent to the user's Google ID.
<br><br>
In Python, set the <code><span>login_hint</span></code> parameter by specifying
<code><span>login_hint</span></code> as a keyword argument when calling the
<code><span>flow.<wbr>authorization_url</span></code> method:
<pre class="prettyprint"><div class="devsite-code-button-wrapper"><div class="devsite-code-button gc-analytics-event material-icons devsite-dark-code-button" data-category="Site-Wide Custom Events" data-label="Dark Code Toggle" track-type="exampleCode" track-name="darkCodeToggle" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Dark code theme" aria-label="Dark code theme" data-title="Dark code theme"></div><div class="devsite-code-button gc-analytics-event material-icons devsite-click-to-copy-button" data-category="Site-Wide Custom Events" data-label="Click To Copy" track-type="exampleCode" track-name="clickToCopy" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Click to copy" aria-label="Click to copy" data-title="Click to copy"></div></div><span class="pln">authorization_url</span><span class="pun">,</span><span class="pln"> state </span><span class="pun">=</span><span class="pln"> flow</span><span class="pun">.</span><span class="pln">authorization_url</span><span class="pun">(</span><span class="pln"><br> access_type</span><span class="pun">=</span><span class="str">'offline'</span><span class="pun">,</span><span class="pln"><br> </span><b><span class="pln">login_hint</span><span class="pun">=</span><span class="str">'timmerman@google.com'</span></b><span class="pun">,</span><span class="pln"><br> include_granted_scopes</span><span class="pun">=</span><span class="str">'true'</span><span class="pun">)</span></pre>
</td>
|
prompt |
Optional. A space-delimited, case-sensitive list of prompts to
present the user. If you don't specify this parameter, the user will be
prompted only the first time your app requests access.
<br><br>
In Python, set the <code><span>prompt</span></code> parameter by specifying
<code><span>prompt</span></code> as a keyword argument when calling the
<code><span>flow.<wbr>authorization_url</span></code> method:
<pre class="prettyprint"><div class="devsite-code-button-wrapper"><div class="devsite-code-button gc-analytics-event material-icons devsite-dark-code-button" data-category="Site-Wide Custom Events" data-label="Dark Code Toggle" track-type="exampleCode" track-name="darkCodeToggle" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Dark code theme" aria-label="Dark code theme" data-title="Dark code theme"></div><div class="devsite-code-button gc-analytics-event material-icons devsite-click-to-copy-button" data-category="Site-Wide Custom Events" data-label="Click To Copy" track-type="exampleCode" track-name="clickToCopy" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Click to copy" aria-label="Click to copy" data-title="Click to copy"></div></div><span class="pln">authorization_url</span><span class="pun">,</span><span class="pln"> state </span><span class="pun">=</span><span class="pln"> flow</span><span class="pun">.</span><span class="pln">authorization_url</span><span class="pun">(</span><span class="pln"><br> access_type</span><span class="pun">=</span><span class="str">'offline'</span><span class="pun">,</span><span class="pln"><br> </span><b><span class="pln">prompt</span><span class="pun">=</span><span class="str">'consent'</span></b><span class="pun">,</span><span class="pln"><br> include_granted_scopes</span><span class="pun">=</span><span class="str">'true'</span><span class="pun">)</span></pre>
Possible values are:
<div class="devsite-table-wrapper"><table class="responsive">
<tbody><tr>
<td><code><span>none</span></code></td>
<td>Do not display any authentication or consent screens. Must not be
specified with other values.</td>
</tr>
<tr>
<td><code><span>consent</span></code></td>
<td>Prompt the user for consent.</td>
</tr>
<tr>
<td><code><span>select_account</span></code></td>
<td>Prompt the user to select an account.</td>
</tr>
</tbody></table></div>
</td>
|
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.
<p>This example shows how to redirect the user to the authorization URL
using the Flask web application framework:
return flask.redirect(authorization_url)
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. The user can
then consent or refuse to grant access to your application.
Your application doesn't need to do anything at this stage as it waits for
the response from Google's OAuth 2.0 server indicating whether the access was
granted. That response is explained in the following step.
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
Important: If your
response endpoint renders an HTML page, any resources on that page will be
able to see the authorization code in the URL. Scripts can read the URL
directly, and the URL in the Referer HTTP header may be sent
to any or all resources on the page.
Carefully consider whether you want to send authorization credentials to all
resources on that page (especially third-party scripts such as social plugins
and analytics). To avoid this issue, we recommend that the server first handle
the request, then redirect to another URL that doesn't include the response
parameters.
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%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly&
access_type=offline&
include_granted_scopes=true&
state=state_parameter_passthrough_value&
redirect_uri=http%3A%2F%2Foauth2.example.com%2Fcallback&
response_type=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.
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/youtube.force-ssl'],
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}
Calling Google APIs
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 the
googleapiclient.discovery
library's build method with the name and version of the API
and the user credentials:
For example, to call version 2 of the Drive API:
<pre class="prettyprint"><div class="devsite-code-button-wrapper"><div class="devsite-code-button gc-analytics-event material-icons devsite-dark-code-button" data-category="Site-Wide Custom Events" data-label="Dark Code Toggle" track-type="exampleCode" track-name="darkCodeToggle" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Dark code theme" aria-label="Dark code theme" data-title="Dark code theme"></div><div class="devsite-code-button gc-analytics-event material-icons devsite-click-to-copy-button" data-category="Site-Wide Custom Events" data-label="Click To Copy" track-type="exampleCode" track-name="clickToCopy" tabindex="0" role="button" data-tooltip-align="b,c" data-tooltip="Click to copy" aria-label="Click to copy" data-title="Click to copy"></div></div><span class="kwd">from</span><span class="pln"> googleapiclient</span><span class="pun">.</span><span class="pln">discovery </span><span class="kwd">import</span><span class="pln"> build<br><br>drive </span><span class="pun">=</span><span class="pln"> build</span><span class="pun">(</span><span class="str">'drive'</span><span class="pun">,</span><span class="pln"> </span><span class="str">'v2'</span><span class="pun">,</span><span class="pln"> credentials</span><span class="pun">=</span><span class="pln">credentials</span><span class="pun">)</span></pre></li>
- 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()
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 files.
<p>This example uses the <a href="http://flask.pocoo.org/">Flask</a>
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
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.
Note: To run this code locally, you must have followed the
directions in the prerequisites section,
including setting http://localhost:8080 as a valid redirect URI
for your credentials and downloading the client_secret.json file
for those credentials to your working directory.
# -*- 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 http://flask.pocoo.org/docs/0.12/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)
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://accounts.google.com/o/oauth2/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)
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, add those scopes to your existing
access token for that user.
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 profile
scope 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 its scopes.
- 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 example for setting authorization
parameters demonstrates how to ensure authorization requests follow
this best practice. The code snippet below also shows the code that you
need to add to use incremental authorization.
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')
Refreshing an access token (offline access)
Access tokens periodically expire. 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.
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.
<p>In Python, set the <code>access_type</code> 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.
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.
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 or removes an application. In other words, part of the removal
process can include an API request to ensure the permissions granted to the
application are removed.
To programmatically revoke a token, make a request to
https://accounts.google.com/o/oauth2/revoke that includes
the token as a parameter and sets the Content-Type header:
requests.post('https://accounts.google.com/o/oauth2/revoke',
params={'token': credentials.token},
headers = {'content-type': 'application/x-www-form-urlencoded'})
Note: Following a successful revocation response, it
might take some time before the revocation has full effect.
Notice: This DevSite page will soon be deleted per b/133171590. Please add this sample to GitHub if it is relevant still:
https://developers.google.com/api-client-library/python/auth/web-app
Using OAuth 2.0 for Web Server Applications
This document explains how web server applications use the Google API
Client Library for Python 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.
Prerequisites
Enable APIs for your project
Any application that calls Google APIs needs to enable those APIs in the API Console. To enable the appropriate APIs for your project:
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.
Web application. 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.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:8080as 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.
Important: Do not store the client_secret.json file in a publicly-accessible location. In addition, if you share the source code to your application—for example, on GitHub—store the client_secret.json file outside of your source tree to avoid inadvertently sharing your client credentials.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.
To run the Python code samples in this document, you'll need:
The Google APIs Client Library for Python:
The
google-auth,google-auth-oauthlib, andgoogle-auth-httplib2for user authorization.The Flask Python web application framework.
The
requestsHTTP library.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:
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.
The following code snippet uses the
google-auth-oauthlib.flowmodule to construct the authorization request.The code constructs a
Flowobject, 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 optionalaccess_typeandinclude_granted_scopesparameters.For example, this code requests read-only, offline access to a user's Google Drive:
The request specifies the following information:
client_idredirect_uriscopeaccess_typeonline, which is the default value, andoffline.Set the value to
offlineif your application needs to refresh access tokens when the user is not present at the browser. This is the method of refreshing access tokens described later in this document. This value instructs the Google authorization server to return a refresh token and an access token the first time that your application exchanges an authorization code for tokens.statename=valuepair in the hash (#) fragment of theredirect_uriafter the user consents to or denies your application's access request.You can use this parameter for several purposes, such as directing the user to the correct resource in your application, sending nonces, and mitigating cross-site request forgery. Since your
redirect_urican be guessed, using astatevalue can increase your assurance that an incoming connection is the result of an authentication request. If you generate a random string or encode the hash of a cookie or another value that captures the client's state, you can validate the response to additionally ensure that the request and response originated in the same browser, providing protection against attacks such as cross-site request forgery. See the OpenID Connect documentation for an example of how to create and confirm astatetoken.include_granted_scopestrueand the authorization request is granted, then the new access token will also cover any scopes to which the user previously granted the application access. See the incremental authorization section for examples.login_hintSet the parameter value to an email address or
subidentifier, which is equivalent to the user's Google ID.promptStep 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.
using the Flask web application framework:
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. The user can then consent or refuse to grant access to your application.
Your application doesn't need to do anything at this stage as it waits for the response from Google's OAuth 2.0 server indicating whether the access was granted. That response is explained in the following step.
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:
An authorization code response:
Important: If your response endpoint renders an HTML page, any resources on that page will be able to see the authorization code in the URL. Scripts can read the URL directly, and the URL in the
RefererHTTP header may be sent to any or all resources on the page.Carefully consider whether you want to send authorization credentials to all
resources on that page (especially third-party scripts such as social plugins
and analytics). To avoid this issue, we recommend that the server first handle
the request, then redirect to another URL that doesn't include the response
parameters.
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:
After completing the OAuth 2.0 flow, you should be redirected to
http://localhost/oauth2callback, which will likely yield a404 NOT FOUNDerror 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.
On your callback page, use the
google-authlibrary to verify the authorization server response. Then, use theflow.fetch_tokenmethod to exchange the authorization code in that response for an access token:Calling Google APIs
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.
googleapiclient.discoverylibrary'sbuildmethod with the name and version of the API and the user credentials:For example, to call version 2 of the Drive API:
For example, to list the files in the authenticated user's Google Drive:
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 files.
framework. It runs a web application at
http://localhost:8080that lets you test the OAuth 2.0 flow. If you go to that URL, you should
see four links:
Note: To run this code locally, you must have followed the directions in the prerequisites section, including setting
http://localhost:8080as a valid redirect URI for your credentials and downloading the client_secret.json file for those credentials to your working directory.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, add those scopes to your existing access token for that user.
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
profilescope to perform basic sign-in, and then later request thehttps://www.googleapis.com/auth/drive.filescope 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 example for setting authorization parameters demonstrates how to ensure authorization requests follow this best practice. The code snippet below also shows the code that you need to add to use incremental authorization.
In Python, set the
include_granted_scopeskeyword argument totrueto ensure that an authorization request includes previously granted scopes. It is very possible thatinclude_granted_scopeswill not be the only keyword argument that you set, as shown in the example below.Refreshing an access token (offline access)
Access tokens periodically expire. 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.
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.
offlineto ensure that you will be able to refresh theaccess token without having to re-prompt the user for permission.
It is very possible that
access_typewill not be theonly keyword argument that you set, as shown in the example below.
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.
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. 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 or removes an application. In other words, part of the removal process can include an API request to ensure the permissions granted to the application are removed.
To programmatically revoke a token, make a request to
Note: Following a successful revocation response, it might take some time before the revocation has full effect.https://accounts.google.com/o/oauth2/revokethat includes the token as a parameter and sets theContent-Typeheader: