Web サーバー アプリケーションでの OAuth 2.0 の使用

このドキュメントでは、ウェブ サーバー アプリケーションが Google API クライアント ライブラリまたは Google OAuth 2.0 エンドポイントを使用して、Google API にアクセスするための OAuth 2.0 認証を実装する方法について説明します。

OAuth 2.0 を使用すると、ユーザーは、ユーザー名、パスワード、およびその他の情報を非公開にしたまま、特定のデータをアプリケーションと共有できます。たとえば、アプリケーションは OAuth 2.0 を使用して、ユーザーから Google ドライブにファイルを保存する許可を取得できます。

この OAuth 2.0 フローは、特にユーザー認証用です。これは、機密情報を保存して状態を維持できるアプリケーション向けに設計されています。適切に承認された Web サーバー アプリケーションは、ユーザーがアプリケーションと対話している間、またはユーザーがアプリケーションを離れた後に API にアクセスできます。

Web サーバー アプリケーションは、サービス アカウントを使用して API リクエストを承認することもよくあります。特に、ユーザー固有のデータではなく、プロジェクト ベースのデータにアクセスするために Cloud API を呼び出す場合などです。 Web サーバー アプリケーションは、ユーザー認証と組み合わせてサービス アカウントを使用できます。

クライアント ライブラリ

このページの言語固有の例では、 Google API クライアント ライブラリを使用して OAuth 2.0 認証を実装しています。コード サンプルを実行するには、まず言語のクライアント ライブラリをインストールする必要があります。

Google API クライアント ライブラリを使用してアプリケーションの OAuth 2.0 フローを処理する場合、クライアント ライブラリは、アプリケーションが独自に処理する必要のある多くのアクションを実行します。たとえば、アプリケーションが保存されたアクセス トークンをいつ使用または更新できるか、またアプリケーションが同意を再取得する必要があるタイミングを決定します。また、クライアント ライブラリは正しいリダイレクト URL を生成し、アクセス トークンの認証コードを交換するリダイレクト ハンドラーの実装に役立ちます。

クライアント ライブラリは、次の言語で利用できます。

前提条件

プロジェクトで API を有効にする

Google API を呼び出すアプリケーションは、API Console でこれらの API を有効にする必要があります。

プロジェクトで API を有効にするには:

  1. Google API Console の Open the API Library
  2. If prompted, select a project, or create a new one.
  3. API Library には、使用可能なすべての API が製品ファミリと人気によってグループ化されてリストされています。有効にする API がリストに表示されない場合は、検索を使用して見つけるか、その API が属する製品ファミリで[すべて表示] をクリックします
  4. 有効にする API を選択し、[有効にする] ボタンをクリックします。
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

認証資格情報を作成する

OAuth 2.0 を使用して Google API にアクセスするアプリケーションには、Google の OAuth 2.0 サーバーに対してアプリケーションを識別する認証資格情報が必要です。次の手順では、プロジェクトの資格情報を作成する方法について説明します。その後、アプリケーションは資格情報を使用して、そのプロジェクトに対して有効にした API にアクセスできます。

  1. Go to the Credentials page.
  2. [クレデンシャルの作成] > [OAuth クライアント ID] をクリックします
  3. Web アプリケーションのアプリケーションの種類を選択します
  4. フォームに入力し、 [作成] をクリックします。 PHP、Java、Python、Ruby、.NET などの言語とフレームワークを使用するアプリケーションでは、承認済みのリダイレクト URI を指定する必要があります。リダイレクト URI は、OAuth 2.0 サーバーが応答を送信できるエンドポイントです。これらのエンドポイントは、 Google の検証ルールに準拠している必要があります

    テスト用に、 http://localhost:8080などのローカル マシンを参照する URI を指定できます。このことを念頭に置いて、このドキュメントのすべての例では、リダイレクト URI としてhttp://localhost:8080を使用していることに注意してください。

    アプリケーションがページ上の他のリソースに認証コードを公開しないように、アプリの認証エンドポイント設計することをお勧めします。

資格情報を作成したら、 API Consoleからclient_secret.jsonファイルをダウンロードします。アプリケーションだけがアクセスできる場所にファイルを安全に保存します。

アクセス スコープを特定する

スコープを使用すると、アプリケーションは必要なリソースへのアクセスのみを要求でき、ユーザーはアプリケーションに付与するアクセスの量を制御できます。したがって、要求されたスコープの数とユーザーの同意を得る可能性の間には逆の関係がある可能性があります。

OAuth 2.0 認証の実装を開始する前に、アプリがアクセスするためのアクセス許可が必要なスコープを特定することをお勧めします。

また、アプリケーションがコンテキストでユーザー データへのアクセスを要求する段階的な承認プロセスを介して、アプリケーションが承認スコープへのアクセスを要求することをお勧めします。このベスト プラクティスにより、ユーザーは、アプリケーションが要求しているアクセスを必要とする理由をより簡単に理解できます。

OAuth 2.0 API スコープドキュメントには、Google API へのアクセスに使用できるスコープの完全なリストが含まれています。

言語固有の要件

このドキュメントのコード サンプルを実行するには、Google アカウント、インターネットへのアクセス、および Web ブラウザーが必要です。 API クライアント ライブラリのいずれかを使用している場合は、以下の言語固有の要件も参照してください。

PHP

このドキュメントの PHP コード サンプルを実行するには、次のものが必要です。

  • コマンドライン インターフェイス (CLI) と JSON 拡張機能がインストールされた PHP 5.4 以降。
  • Composer依存関係管理ツール。
  • PHP 用の Google API クライアント ライブラリ:

    php composer.phar require google/apiclient:^2.0

パイソン

このドキュメントの Python コード サンプルを実行するには、次のものが必要です。

  • Python 2.6 以降
  • pipパッケージ管理ツール。
  • Python 用の Google API クライアント ライブラリ:
    pip install --upgrade google-api-python-client
  • ユーザー認証用のgoogle-authgoogle-auth-oauthlib 、およびgoogle-auth-httplib2
    pip install --upgrade google-auth google-auth-oauthlib google-auth-httplib2
  • Flask Python Web アプリケーション フレームワーク。
    pip install --upgrade flask
  • requests HTTP ライブラリ。
    pip install --upgrade requests

ルビー

このドキュメントの Ruby コード サンプルを実行するには、次のものが必要です。

  • Ruby 2.2.2 以降
  • Ruby 用の Google API クライアント ライブラリ:

    gem install google-api-client
  • Sinatra Ruby Web アプリケーション フレームワーク。

    gem install sinatra

HTTP/レスト

OAuth 2.0 エンドポイントを直接呼び出すことができるようにするために、ライブラリをインストールする必要はありません。

OAuth 2.0 アクセス トークンの取得

次の手順は、アプリケーションが Google の OAuth 2.0 サーバーとやり取りして、ユーザーに代わって API リクエストを実行することに対するユーザーの同意を取得する方法を示しています。アプリケーションは、ユーザー認証を必要とする Google API リクエストを実行する前に、その同意を得る必要があります。

以下のリストは、これらの手順を簡単にまとめたものです。

  1. アプリケーションは、必要なアクセス許可を識別します。
  2. アプリケーションは、要求された権限のリストとともにユーザーを Google にリダイレクトします。
  3. ユーザーは、アプリケーションにアクセス許可を付与するかどうかを決定します。
  4. アプリケーションは、ユーザーが何を決定したかを調べます。
  5. ユーザーが要求されたアクセス許可を付与した場合、アプリケーションはユーザーに代わって API 要求を行うために必要なトークンを取得します。

ステップ 1: 認証パラメータを設定する

最初のステップは、承認リクエストを作成することです。このリクエストは、アプリケーションを識別し、ユーザーがアプリケーションに付与するよう求められるアクセス許可を定義するパラメーターを設定します。

  • OAuth 2.0 の認証と承認に Google クライアント ライブラリを使用する場合は、これらのパラメータを定義するオブジェクトを作成して設定します。
  • Google OAuth 2.0 エンドポイントを直接呼び出す場合は、URL を生成し、その URL にパラメーターを設定します。

以下のタブは、Web サーバー アプリケーションでサポートされている認証パラメータを定義します。言語固有の例では、クライアント ライブラリまたは認証ライブラリを使用して、それらのパラメーターを設定するオブジェクトを構成する方法も示しています。

PHP

以下のコード スニペットは、認証リクエストのパラメータを定義するGoogle_Client()オブジェクトを作成します。

このオブジェクトは、 client_secret.jsonファイルの情報を使用してアプリケーションを識別します。 (そのファイルの詳細については、認証資格情報の作成を参照してください。) オブジェクトは、アプリケーションがアクセス許可を要求しているスコープと、Google の OAuth 2.0 サーバーからの応答を処理するアプリケーションの認証エンドポイントへの URL も識別します。最後に、コードはオプションのaccess_typeおよびinclude_granted_scopesパラメータを設定します。

たとえば、次のコードは、ユーザーの Google ドライブへの読み取り専用のオフライン アクセスをリクエストします。

$client = new Google_Client();
$client->setAuthConfig('client_secret.json');
$client->addScope(Google_Service_Drive::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

リクエストは次の情報を指定します。

パラメーター
client_id必須

アプリケーションのクライアント ID。この値は API Console Credentials page にあります。

PHP では、 setAuthConfig関数を呼び出して、 client_secret.jsonファイルから認証資格情報をロードします。

$client = new Google_Client();
$client->setAuthConfig('client_secret.json');
redirect_uri必須

ユーザーが認証フローを完了した後、API サーバーがユーザーをリダイレクトする場所を決定します。この値は、クライアントの API Console Credentials page で構成した OAuth 2.0 クライアントの承認済みリダイレクト URI の 1 つに正確に一致する必要があります。この値が、提供されたclient_id許可されたリダイレクト URI と一致しない場合、 redirect_uri_mismatchエラーが発生します。

httpまたはhttpsスキーム、大文字と小文字、および末尾のスラッシュ (' / ') はすべて一致する必要があることに注意してください。

この値を PHP で設定するには、 setRedirectUri関数を呼び出します。提供されたclient_idに対して有効なリダイレクト URI を指定する必要があることに注意してください。

$client->setRedirectUri('https://oauth2.example.com/code');
scope必須

アプリケーションがユーザーの代わりにアクセスできるリソースを識別する、スペースで区切られたスコープのリスト。これらの値は、Google がユーザーに表示する同意画面に通知します。

スコープを使用すると、アプリケーションは必要なリソースへのアクセスのみを要求でき、ユーザーはアプリケーションに付与するアクセスの量を制御できます。したがって、要求されたスコープの数とユーザーの同意を得る可能性の間には反比例の関係があります。

PHP でこの値を設定するには、 addScope関数を呼び出します。

$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);

アプリケーションは、可能な限りコンテキスト内で承認スコープへのアクセスを要求することをお勧めします。段階的な承認を介して、コンテキスト内でユーザー データへのアクセスをリクエストすることで、アプリケーションがリクエストしているアクセスを必要とする理由をユーザーが簡単に理解できるようになります。

access_typeおすすめ

ユーザーがブラウザーにいないときに、アプリケーションがアクセス トークンを更新できるかどうかを示します。有効なパラメーター値は、デフォルト値であるonlineofflineです。

ユーザーがブラウザーにいないときにアプリケーションでアクセス トークンを更新する必要がある場合は、値をoffline設定します。これは、このドキュメントで後述するアクセス トークンを更新する方法です。この値は、アプリケーションがトークンの認証コードを初めて交換するときに、更新トークンアクセス トークンを返すように Google 認証サーバーに指示します。

PHP でこの値を設定するには、 setAccessType関数を呼び出します。

$client->setAccessType('offline');
stateおすすめ

認可リクエストと認可サーバーのレスポンスの間の状態を維持するためにアプリケーションが使用する文字列値を指定します。サーバーは、ユーザーがアプリケーションのアクセス要求に同意または拒否した後、 redirect_uriの URL クエリ コンポーネント ( ? ) でname=valueペアとして送信した正確な値を返します。

このパラメーターは、アプリケーション内の正しいリソースへのユーザーの誘導、ナンスの送信、クロスサイト リクエスト フォージェリの軽減など、いくつかの目的に使用できます。 redirect_uriは推測できるため、 state値を使用すると、着信接続が認証要求の結果であるという保証を高めることができます。ランダムな文字列を生成するか、Cookie のハッシュまたはクライアントの状態をキャプチャする別の値をエンコードする場合、応答を検証して、要求と応答が同じブラウザーから発信されたことをさらに確認し、クロスサイト攻撃などの攻撃から保護できます。リクエスト偽造。 stateトークンを作成して確認する方法の例については、 OpenID Connect のドキュメントを参照してください。

この値を PHP で設定するには、 setState関数を呼び出します。

$client->setState($sample_passthrough_value);
include_granted_scopesオプション

アプリケーションが増分承認を使用して、コンテキスト内の追加のスコープへのアクセスを要求できるようにします。このパラメーターの値をtrueし、承認要求が許可された場合、新しいアクセス トークンは、ユーザーが以前にアプリケーション アクセスを許可したスコープもカバーします。例については、増分承認のセクションを参照してください。

PHP でこの値を設定するには、 setIncludeGrantedScopes関数を呼び出します。

$client->setIncludeGrantedScopes(true);
login_hintオプション

アプリケーションが認証を試みているユーザーを認識している場合、このパラメータを使用して Google 認証サーバーにヒントを提供できます。サーバーはヒントを使用して、サインイン フォームの電子メール フィールドに事前入力するか、適切なマルチログイン セッションを選択することにより、ログイン フローを簡素化します。

パラメータ値を、ユーザーの Google ID に相当するメール アドレスまたはsub識別子に設定します。

この値を PHP で設定するには、 setLoginHint関数を呼び出します。

$client->setLoginHint('None');
promptオプション

ユーザーに提示するプロンプトのスペース区切りの大文字と小文字の区別のあるリスト。このパラメーターを指定しない場合、プロジェクトが最初にアクセスを要求したときにのみユーザーにプロンプ​​トが表示されます。詳細については、再同意のプロンプトを参照してください。

この値を PHP で設定するには、 setApprovalPrompt関数を呼び出します。

$client->setApprovalPrompt('consent');

可能な値は次のとおりです。

none認証画面や同意画面を表示しないでください。他の値と一緒に指定してはなりません。
consentユーザーに同意を求めます。
select_accountユーザーにアカウントを選択するように促します。

パイソン

次のコード スニペットでは、 google-auth-oauthlib.flowモジュールを使用して承認リクエストを作成しています。

このコードはFlowオブジェクトを構築します。このオブジェクトは、認証クレデンシャルの作成後にダウンロードしたclient_secret.jsonファイルの情報を使用してアプリケーションを識別します。このオブジェクトは、アプリケーションがアクセス許可を要求しているスコープと、Google の OAuth 2.0 サーバーからの応答を処理するアプリケーションの認証エンドポイントへの URL も識別します。最後に、コードはオプションのaccess_typeおよびinclude_granted_scopesパラメータを設定します。

たとえば、次のコードは、ユーザーの Google ドライブへの読み取り専用のオフライン アクセスをリクエストします。

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')

リクエストは次の情報を指定します。

パラメーター
client_id必須

アプリケーションのクライアント ID。この値は API Console Credentials page にあります。

Python では、 from_client_secrets_fileメソッドを呼び出して、 client_secret.jsonファイルからクライアント ID を取得します。 ( from_client_configメソッドを使用することもできます。 from_client_configメソッドは、クライアント シークレット ファイルに最初に表示されていたクライアント構成を渡しますが、ファイル自体にはアクセスしません。)

flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])
redirect_uri必須

ユーザーが認証フローを完了した後、API サーバーがユーザーをリダイレクトする場所を決定します。この値は、クライアントの API Console Credentials page で構成した OAuth 2.0 クライアントの承認済みリダイレクト URI の 1 つに正確に一致する必要があります。この値が、提供されたclient_id許可されたリダイレクト URI と一致しない場合、 redirect_uri_mismatchエラーが発生します。

httpまたはhttpsスキーム、大文字と小文字、および末尾のスラッシュ (' / ') がすべて一致する必要があることに注意してください。

Python でこの値を設定するには、 flowオブジェクトのredirect_uriプロパティを設定します。

flow.redirect_uri = 'https://oauth2.example.com/code'
scope必須

アプリケーションがユーザーの代わりにアクセスできるリソースを識別するスコープのリスト。これらの値は、Google がユーザーに表示する同意画面に通知します。

スコープを使用すると、アプリケーションは必要なリソースへのアクセスのみを要求でき、ユーザーはアプリケーションに付与するアクセスの量を制御できます。したがって、要求されたスコープの数とユーザーの同意が得られる可能性の間には反比例の関係があります。

Python では、スコープのリストを指定するためにclient_idを設定するのに使用するのと同じ方法を使用します。

flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])

アプリケーションは、可能な限りコンテキスト内で承認スコープへのアクセスを要求することをお勧めします。段階的な承認を介して、コンテキスト内でユーザー データへのアクセスをリクエストすることで、アプリケーションがリクエストしているアクセスを必要とする理由をユーザーが簡単に理解できるようになります。

access_typeおすすめ

ユーザーがブラウザーにいないときに、アプリケーションがアクセス トークンを更新できるかどうかを示します。有効なパラメーター値は、デフォルト値であるonlineofflineです。

ユーザーがブラウザーにいないときにアプリケーションでアクセス トークンを更新する必要がある場合は、値をoffline設定します。これは、このドキュメントで後述するアクセス トークンを更新する方法です。この値は、アプリケーションがトークンの認証コードを初めて交換するときに、更新トークンアクセス トークンを返すように Google 認証サーバーに指示します。

Pythonでは、設定access_type指定することで、パラメータをaccess_type呼び出すときにキーワード引数としてflow.authorization_url方法:

authorization_url, state = flow.authorization_url(
    access_type='offline',
    include_granted_scopes='true')
stateおすすめ

認可リクエストと認可サーバーのレスポンスの間の状態を維持するためにアプリケーションが使用する文字列値を指定します。サーバーは、ユーザーがアプリケーションのアクセス要求に同意または拒否した後、 redirect_uriの URL クエリ コンポーネント ( ? ) でname=valueペアとして送信した正確な値を返します。

このパラメーターは、アプリケーション内の正しいリソースへのユーザーの誘導、ナンスの送信、クロスサイト リクエスト フォージェリの軽減など、いくつかの目的に使用できます。 redirect_uriは推測できるため、 state値を使用すると、着信接続が認証要求の結果であるという保証を高めることができます。ランダムな文字列を生成するか、Cookie のハッシュまたはクライアントの状態をキャプチャする別の値をエンコードする場合、応答を検証して、要求と応答が同じブラウザーから発信されたことをさらに確認し、クロスサイト攻撃などの攻撃から保護できます。リクエスト偽造。 stateトークンを作成して確認する方法の例については、 OpenID Connect のドキュメントを参照してください。

Python では、 flow.authorization_urlメソッドを呼び出すときに、 stateをキーワード引数として指定して、 stateパラメーターを設定します。

authorization_url, state = flow.authorization_url(
    access_type='offline',
    state=sample_passthrough_value,
    include_granted_scopes='true')
include_granted_scopesオプション

アプリケーションが増分承認を使用して、コンテキスト内の追加のスコープへのアクセスを要求できるようにします。このパラメーターの値をtrueし、承認要求が許可された場合、新しいアクセス トークンは、ユーザーが以前にアプリケーション アクセスを許可したスコープもカバーします。例については、増分承認のセクションを参照してください。

Python では、 flow.authorization_urlメソッドを呼び出すときに、 include_granted_scopesをキーワード引数として指定して、 include_granted_scopesパラメーターを設定しinclude_granted_scopes

authorization_url, state = flow.authorization_url(
    access_type='offline',
    include_granted_scopes='true')
login_hintオプション

アプリケーションが認証を試みているユーザーを認識している場合、このパラメータを使用して Google 認証サーバーにヒントを提供できます。サーバーはヒントを使用して、サインイン フォームの電子メール フィールドに事前入力するか、適切なマルチログイン セッションを選択することにより、ログイン フローを簡素化します。

パラメータ値を、ユーザーの Google ID に相当するメール アドレスまたはsub識別子に設定します。

Pythonでは、設定login_hint指定することで、パラメータをlogin_hint呼び出すときにキーワード引数としてflow.authorization_url方法:

authorization_url, state = flow.authorization_url(
    access_type='offline',
    login_hint='None',
    include_granted_scopes='true')
promptオプション

ユーザーに提示するプロンプトのスペース区切りの大文字と小文字の区別のあるリスト。このパラメーターを指定しない場合、プロジェクトが最初にアクセスを要求したときにのみユーザーにプロンプ​​トが表示されます。詳細については、再同意のプロンプトを参照してください。

Python では、 flow.authorization_urlメソッドを呼び出すときに、 promptをキーワード引数として指定して、 promptパラメーターを設定しprompt

authorization_url, state = flow.authorization_url(
      access_type='offline',
      prompt='consent',
      include_granted_scopes='true')

可能な値は次のとおりです。

none認証画面や同意画面を表示しないでください。他の値と一緒に指定してはなりません。
consentユーザーに同意を求めます。
select_accountユーザーにアカウントを選択するように促します。

ルビー

作成した client_secrets.json ファイルを使用して、アプリケーションでクライアント オブジェクトを構成します。クライアント オブジェクトを構成するときは、アプリケーションがアクセスする必要のあるスコープを、OAuth 2.0 サーバーからの応答を処理するアプリケーションの認証エンドポイントへの URL とともに指定します。

たとえば、次のコードは、ユーザーの Google ドライブへの読み取り専用のオフライン アクセスをリクエストします。

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
  }
)

アプリケーションはクライアント オブジェクトを使用して、認証要求 URL の生成や HTTP 要求へのアクセス トークンの適用などの OAuth 2.0 操作を実行します。

HTTP/レスト

Google の OAuth 2.0 エンドポイントはhttps://accounts.google.com/o/oauth2/v2/auth 。このエンドポイントには、HTTPS 経由でのみアクセスできます。プレーンな HTTP 接続は拒否されます。

Google 認証サーバーは、Web サーバー アプリケーションの次のクエリ文字列パラメーターをサポートしています。

パラメーター
client_id必須

アプリケーションのクライアント ID。この値は API Console Credentials page にあります。

redirect_uri必須

ユーザーが認証フローを完了した後、API サーバーがユーザーをリダイレクトする場所を決定します。この値は、クライアントの API Console Credentials page で構成した OAuth 2.0 クライアントの承認済みリダイレクト URI の 1 つに正確に一致する必要があります。この値が、提供されたclient_id許可されたリダイレクト URI と一致しない場合、 redirect_uri_mismatchエラーが発生します。

httpまたはhttpsスキーム、大文字と小文字、および末尾のスラッシュ (' / ') がすべて一致する必要があることに注意してください。

response_type必須

Google OAuth 2.0 エンドポイントが認証コードを返すかどうかを決定します。

パラメータ値を Web サーバー アプリケーションのcode設定します。

scope必須

アプリケーションがユーザーの代わりにアクセスできるリソースを識別する、スペースで区切られたスコープのリスト。これらの値は、Google がユーザーに表示する同意画面に通知します。

スコープを使用すると、アプリケーションは必要なリソースへのアクセスのみを要求でき、ユーザーはアプリケーションに付与するアクセスの量を制御できます。したがって、要求されたスコープの数とユーザーの同意が得られる可能性の間には反比例の関係があります。

アプリケーションは、可能な限りコンテキスト内で承認スコープへのアクセスを要求することをお勧めします。段階的な承認を介して、コンテキスト内でユーザー データへのアクセスをリクエストすることで、アプリケーションがリクエストしているアクセスを必要とする理由をユーザーが簡単に理解できるようになります。

access_typeおすすめ

ユーザーがブラウザーにいないときに、アプリケーションがアクセス トークンを更新できるかどうかを示します。有効なパラメーター値は、デフォルト値であるonlineofflineです。

ユーザーがブラウザーにいないときにアプリケーションでアクセス トークンを更新する必要がある場合は、値をoffline設定します。これは、このドキュメントで後述するアクセス トークンを更新する方法です。この値は、アプリケーションがトークンの認証コードを初めて交換するときに、更新トークンアクセス トークンを返すように Google 認証サーバーに指示します。

stateおすすめ

認可リクエストと認可サーバーのレスポンスの間の状態を維持するためにアプリケーションが使用する文字列値を指定します。サーバーは、ユーザーがアプリケーションのアクセス要求に同意または拒否した後、 redirect_uriの URL クエリ コンポーネント ( ? ) でname=valueペアとして送信した正確な値を返します。

このパラメーターは、アプリケーション内の正しいリソースへのユーザーの誘導、ナンスの送信、クロスサイト リクエスト フォージェリの軽減など、いくつかの目的に使用できます。 redirect_uriは推測できるため、 state値を使用すると、着信接続が認証要求の結果であるという保証を高めることができます。ランダムな文字列を生成するか、Cookie のハッシュまたはクライアントの状態をキャプチャする別の値をエンコードする場合、応答を検証して、要求と応答が同じブラウザーから発信されたことをさらに確認し、クロスサイト攻撃などの攻撃から保護できます。リクエスト偽造。 stateトークンを作成して確認する方法の例については、 OpenID Connect のドキュメントを参照してください。

include_granted_scopesオプション

アプリケーションが増分承認を使用して、コンテキスト内の追加スコープへのアクセスを要求できるようにします。このパラメーターの値をtrueし、承認要求が許可された場合、新しいアクセス トークンは、ユーザーが以前にアプリケーション アクセスを許可したスコープもカバーします。例については、増分承認のセクションを参照してください。

login_hintオプション

アプリケーションが認証を試みているユーザーを認識している場合、このパラメータを使用して Google 認証サーバーにヒントを提供できます。サーバーはヒントを使用して、サインイン フォームの電子メール フィールドに事前入力するか、適切なマルチログイン セッションを選択することにより、ログイン フローを簡素化します。

パラメータ値を、ユーザーの Google ID に相当するメール アドレスまたはsub識別子に設定します。

promptオプション

ユーザーに提示するプロンプトのスペース区切りの大文字と小文字の区別のあるリスト。このパラメーターを指定しない場合、プロジェクトが最初にアクセスを要求したときにのみユーザーにプロンプ​​トが表示されます。詳細については、再同意のプロンプトを参照してください。

可能な値は次のとおりです。

none認証画面や同意画面を表示しないでください。他の値と一緒に指定してはなりません。
consentユーザーに同意を求めます。
select_accountユーザーにアカウントを選択するように促します。

ステップ 2: Google の OAuth 2.0 サーバーにリダイレクトする

ユーザーを Google の OAuth 2.0 サーバーにリダイレクトして、認証および承認プロセスを開始します。通常、これは、アプリケーションが最初にユーザーのデータにアクセスする必要があるときに発生します。増分承認の場合、このステップは、アプリケーションがまだアクセス許可を持っていない追加のリソースに最初にアクセスする必要がある場合にも発生します。

PHP

  1. Google の OAuth 2.0 サーバーからのアクセスをリクエストするための URL を生成します:
    $auth_url = $client->createAuthUrl();
  2. ユーザーを$auth_urlリダイレクトします :
    header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));

パイソン

この例は、Flask Web アプリケーション フレームワークを使用してユーザーを認証 URL にリダイレクトする方法を示しています。

return flask.redirect(authorization_url)

ルビー

  1. Google の OAuth 2.0 サーバーからのアクセスをリクエストするための URL を生成します:
    auth_uri = auth_client.authorization_uri.to_s
  2. ユーザーをauth_uriリダイレクトします。

HTTP/レスト

Google の認証サーバーへのサンプル リダイレクト

URL の例を以下に示します。読みやすいように改行とスペースを入れています。

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

リクエスト URL を作成したら、ユーザーをその URL にリダイレクトします。

Google の OAuth 2.0 サーバーはユーザーを認証し、アプリケーションが要求されたスコープにアクセスするための同意をユーザーから取得します。応答は、指定したリダイレクト URL を使用してアプリケーションに返送されます。

ステップ 3: Google がユーザーに同意を求める

このステップでは、ユーザーはアプリケーションに要求されたアクセスを許可するかどうかを決定します。この段階で、Google は、アプリケーションの名前と、ユーザーの認証資格情報を使用したアクセス許可を要求している Google API サービス、および許可されるアクセスの範囲の概要を示す同意ウィンドウを表示します。ユーザーは、アプリケーションによって要求された 1 つ以上のスコープへのアクセスを許可することに同意するか、要求を拒否することができます。

アプリケーションは、アクセスが許可されたかどうかを示す Google の OAuth 2.0 サーバーからの応答を待機するため、この段階では何​​もする必要はありません。その応答については、次の手順で説明します。

エラー

Google の OAuth 2.0 認証エンドポイントへのリクエストで、予期される認証および認証フローの代わりに、ユーザー向けのエラー メッセージが表示される場合があります。一般的なエラー コードと推奨される解決策を以下に示します。

admin_policy_enforced

Google Workspace 管理者のポリシーにより、Google アカウントはリクエストされた 1 つ以上のスコープを承認できません。 OAuth クライアント ID へのアクセスが明示的に許可されるまで、管理者がすべてのスコープまたは機密および制限付きスコープへのアクセスを制限する方法の詳細については、Google Workspace 管理者のヘルプ記事「 Google Workspace データにアクセスするサードパーティおよび内部アプリを制御する」を参照してください。

disallowed_useragent

認証エンドポイントは、Google のOAuth 2.0 ポリシーによって許可されていない組み込みユーザー エージェント内に表示されます。

アンドロイド

Android 開発者は、 android.webkit.WebView認証リクエストを開くときに、このエラー メッセージが表示される場合があります。代わりに、開発者は Android 用のGoogle サインインAndroid 用のOpenID Foundation のAppAuthなどの Android ライブラリを使用する必要があります。

Android アプリが埋め込みユーザー エージェントで一般的な Web リンクを開き、ユーザーがサイトから Google の OAuth 2.0 認証エンドポイントに移動すると、Web 開発者はこのエラーに遭遇する可能性があります。開発者は、一般的なリンクがオペレーティング システムのデフォルトのリンク ハンドラーで開くことを許可する必要があります。これには、Android アプリ リンクハンドラーまたはデフォルトのブラウザー アプリの両方が含まれます。 Android カスタム タブライブラリもサポートされているオプションです。

iOS

iOS および macOS の開発者は、 WKWebView承認要求を開くときにこのエラーが発生する可能性があります。代わりに、開発者は iOS 用のGoogle サインインiOS 用のOpenID Foundation のAppAuthなどの iOS ライブラリを使用する必要があります。

iOS または macOS アプリが埋め込みユーザー エージェントで一般的な Web リンクを開き、ユーザーがサイトから Google の OAuth 2.0 認証エンドポイントに移動すると、Web 開発者はこのエラーに遭遇する可能性があります。開発者は、ユニバーサル リンクハンドラーまたは既定のブラウザー アプリの両方を含む、オペレーティング システムの既定のリンク ハンドラーで一般リンクを開くことを許可する必要があります。 SFSafariViewControllerライブラリもサポートされているオプションです。

org_internal

リクエストの OAuth クライアント ID は、特定のGoogle Cloud 組織のGoogle アカウントへのアクセスを制限するプロジェクトの一部です。この構成オプションの詳細については、「OAuth 同意画面の設定」ヘルプ記事の「ユーザー タイプ」セクションを参照してください。

redirect_uri_mismatch

承認リクエストで渡されたredirect_uriが、OAuth クライアント ID の承認済みリダイレクト URI と一致しません。 Google API Console Credentials page の承認済みリダイレクト URI を確認してください。

ステップ 4: OAuth 2.0 サーバーの応答を処理する

OAuth 2.0 サーバーは、リクエストで指定された URL を使用して、アプリケーションのアクセス リクエストに応答します。

ユーザーがアクセス要求を承認した場合、応答には認証コードが含まれます。ユーザーがリクエストを承認しない場合、レスポンスにはエラー メッセージが含まれます。 Web サーバーに返される認証コードまたはエラー メッセージは、次に示すようにクエリ文字列に表示されます。

エラー応答:

https://oauth2.example.com/auth?error=access_denied

認証コードの応答:

https://oauth2.example.com/auth?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7

OAuth 2.0 サーバー応答のサンプル

このフローをテストするには、次のサンプル URL をクリックします。この URL は、Google ドライブ内のファイルのメタデータを表示するための読み取り専用アクセスを要求します。

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!

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 access_type parameter to offline in the initial request to Google's authorization server.
scope The scopes of access granted by the access_token expressed as a list of space-delimited, case-sensitive strings.
token_type The type of token returned. At this time, this field's value is always set to Bearer .

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:

  1. If you need to apply an access token to a new Google_Client object—for example, if you stored the access token in a user session—use the setAccessToken method:
    $client->setAccessToken($access_token);
  2. Build a service object for the API that you want to call. You build a service object by providing an authorized Google_Client object to the constructor for the API you want to call. For example, to call the Drive API:
    $drive = new Google_Service_Drive($client);
  3. 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.

  1. 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:
    from googleapiclient.discovery import build
    
    drive = build('drive', 'v2', credentials=credentials)
  2. 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:

  1. 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
  2. Set the credentials on the service:
    drive.authorization = auth_client
  3. 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 })

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:

  1. In the API Console, add the URL of the local machine to the list of redirect URLs. For example, add http://localhost:8080 .
  2. Create a new directory and change to it. For example:
    mkdir ~/php-oauth2-example
    cd ~/php-oauth2-example
  3. Install the Google API Client Library for PHP using Composer :
    composer require google/apiclient:^2.0
  4. Create the files index.php and oauth2callback.php with the content below.
  5. Run the example with a web server configured to serve PHP. If you use PHP 5.4 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 Google_Client();
$client->setAuthConfig('client_secrets.json');
$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);

if (isset($_SESSION['access_token']) && $_SESSION['access_token']) {
  $client->setAccessToken($_SESSION['access_token']);
  $drive = new Google_Service_Drive($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 Google_Client();
$client->setAuthConfigFile('client_secrets.json');
$client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php');
$client->addScope(Google_Service_Drive::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

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

URIs must use the HTTPS scheme, not plain HTTP. Localhost URIs (including localhost IP address URIs) are exempt from this rule.

Host

Hosts cannot be raw IP addresses. Localhost IP addresses are exempted from this rule.

Domain
  • Host TLDs ( Top Level Domains ) must belong to the public suffix list .
  • Host domains cannot be “googleusercontent.com” .
  • URIs cannot contain URL shortener domains (eg goo.gl ) unless the 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), which is represented by an “/..” or “\..” or their URL encoding.

    Query

    Redirect URIs cannot contain open redirects .

    Characters URIs cannot contain certain characters including:
    • Wildcard characters ( '*' )
    • Non-printable ASCII characters
    • Invalid percent encodings (any percent encoding that does not follow URL-encoding form of a percent sign followed by two hexadecimal digits)
    • Null characters (an encoded NULL character, eg, %00 , %C0%80 )

    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"}
    )

    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 to offline 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.

    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.

    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.