このドキュメントでは、スマートフォン、タブレット、パソコンなどのデバイスにインストールされたアプリケーションが、Google の OAuth 2.0 エンドポイントを使用して Google API へのアクセスを承認する方法について説明します。
OAuth 2.0 を使用すると、ユーザー名やパスワードなどの情報を秘密にしたまま、ユーザーが特定のデータをアプリケーションと共有できます。 たとえば、アプリケーションは OAuth 2.0 を使用して、Google ドライブにファイルを保存する権限をユーザーから取得できます。
インストール済みのアプリは個々のデバイスに配布され、それらのアプリはシークレットを保持できないとみなされます。ユーザーがアプリを使用しているとき、またはアプリがバックグラウンドで実行されているときに、Google API にアクセスできます。
この承認フローは、ウェブサーバー アプリケーションで使用するものと似ています。主な違いは、インストール済みのアプリがシステム ブラウザを開き、Google の承認サーバーからのレスポンスを処理するためにローカル リダイレクト URI を指定する必要があることです。
代案
モバイルアプリの場合は、Android または iOS 向けの Google ログインを使用することをおすすめします。Google ログインのクライアント ライブラリは認証とユーザー承認を処理するので、ここで説明する低レベルのプロトコルよりも実装が容易です。
システム ブラウザをサポートしていないデバイス、または入力機能が制限されているデバイス（テレビ、ゲーム機、カメラ、プリンタなど）で実行されるアプリについては、テレビおよびデバイス用の OAuth 2.0 またはテレビや入力が限られているデバイスでのログインをご覧ください。
ライブラリとサンプル
このドキュメントで説明する OAuth 2.0 フローを実装するため、次のライブラリとサンプルを使用することをおすすめします。
Prerequisites
プロジェクトでAPI を有効にする
Google API を呼び出すすべてのアプリケーションは、 API Consoleでこれらの API を有効にする必要があります。
プロジェクトで API を有効にするには:
- Google API ConsoleのOpen the API Library 。
- If prompted, select a project, or create a new one.
- API Library には、利用可能なすべての API がプロダクト ファミリーと人気度別にグループ化されて一覧表示されます。有効にする API がリストに表示されない場合は、検索を使用して探すか、その API が属するプロダクト ファミリーの [すべて表示] をクリックします。
- 有効にする API を選択し、[有効にする] ボタンをクリックします。
- If prompted, enable billing.
- If prompted, read and accept the API's Terms of Service.
承認認証情報を作成する
OAuth 2.0 を使用して Google API にアクセスするアプリケーションには、Google の OAuth 2.0 サーバーでそのアプリケーションを識別するための認証情報が必要です。次の手順では、プロジェクトの認証情報を作成する方法について説明します。アプリケーションはこの認証情報を使用して、そのプロジェクトで有効にした API にアクセスできます。
- Go to the Credentials page.
- [認証情報を作成] > [OAuth クライアント ID] をクリックします。
- 以下のセクションでは、Google の承認サーバーがサポートするクライアント タイプとリダイレクト方法について説明します。アプリケーションに適したクライアント タイプを選択し、OAuth クライアントに名前を付け、フォームの他のフィールドを適宜設定します。
Android
- アプリケーションの種類として [Android] を選択します。
- OAuth クライアントの名前を入力します。この名前は、クライアントを識別するためにプロジェクトの Credentials page に表示されます。
- Android アプリのパッケージ名を入力します。この値は、アプリ マニフェスト ファイルの
<manifest>要素のpackage属性で定義されています。 - アプリ配信の SHA-1 署名証明書フィンガープリントを入力してください。
- アプリで Google Play アプリ署名を使用している場合は、Google Play Console のアプリ署名ページから SHA-1 フィンガープリントをコピーします。
- 独自のキーストアと署名鍵を管理する場合は、Java に含まれる keytool ユーティリティを使用して、人が読める形式で証明書情報を出力します。keytool 出力の
Certificate fingerprintsセクションにあるSHA1の値をコピーします。詳細については、Android 用 Google API ドキュメントのクライアントの認証をご覧ください。
- （省略可）Android アプリの所有権を確認します。
- [作成] をクリックします。
iOS
- アプリケーションの種類として [iOS] を選択します。
- OAuth クライアントの名前を入力します。この名前は、クライアントを識別するためにプロジェクトの Credentials page に表示されます。
- アプリのバンドル ID を入力します。バンドル ID は、アプリの情報プロパティ リストのリソース ファイル（info.plist）に含まれる CFBundleIdentifier キーの値です。この値は通常、Xcode プロジェクト エディタの [General] ペインまたは [Signing & Capabilities] ペインに表示されます。バンドル ID は Apple の App Store Connect サイトで、アプリの [アプリ情報] ページにある [全般情報] セクションにも表示されます。
- （省略可）
アプリが Apple の App Store で公開されている場合は、アプリの App Store ID を入力します。ストア ID は、すべての Apple App Store の URL に含まれる数字文字列です。
- iOS デバイスまたは iPadOS デバイスで Apple App Store アプリを開きます。
- 自分のアプリを探します。
- 共有ボタン（正方形と上矢印アイコン）を選択します。
- [リンクをコピー] を選択します。
- リンクをテキスト エディタに貼り付けます。App Store ID は URL の最後の部分です。
例:
https://apps.apple.com/app/google/id284815942
- （省略可）
チーム ID を入力します。詳細については、Apple Developer Account ドキュメントのチーム ID を確認するをご覧ください。
- [作成] をクリックします。
UWP
- アプリケーションの種類として [Universal Windows Platform] を選択します。
- OAuth クライアントの名前を入力します。この名前は、クライアントを識別するためにプロジェクトの Credentials page に表示されます。
- アプリの 12 文字の Microsoft Store ID を入力します。この値は、Microsoft パートナー センターの [アプリ管理] セクションの [アプリ ID] ページで確認できます。
- [作成] をクリックします。
UWP アプリの場合、カスタム URI スキームは 39 文字以下にする必要があります。
カスタム URI スキーム（Android、iOS、UWP）
カスタム URI スキームは、カスタム定義のスキームを使用してアプリを開くディープリンクの一種です。
Android でカスタム URI スキームを使用する別の方法Android 用 Google ログイン SDK を使用すると、OAuth 2.0 レスポンスがアプリに直接配信されるため、リダイレクト URI が不要になります。
Android 用 Google ログイン SDK に移行する方法
現在 Android で OAuth 統合にカスタム スキームを使用している場合、推奨される Android 用 Google ログイン SDK を使用するように完全に移行するには、以下の操作を完了する必要があります。
- Google ログイン SDK を使用するようにコードを更新します。
- Google API Console でカスタム スキームのサポートを無効にする。
Google ログイン Android SDK に移行する手順は次のとおりです。
-
Google ログイン Android SDK を使用するようにコードを更新します。
-
コードを調べて、Google の OAuth 2.0 サーバーにリクエストを送信している場所を特定します。カスタム スキームを使用している場合、リクエストは次のようになります。
https://accounts.google.com/o/oauth2/v2/auth? scope=<SCOPES>& response_type=code& &state=<STATE>& redirect_uri=com.example.app:/oauth2redirect& client_id=<CLIENT_ID>
com.example.app:/oauth2redirectは、上記の例でカスタム スキームのリダイレクト URI です。カスタム URI スキームの値の形式について詳しくは、redirect_uriパラメータの定義をご覧ください。 -
Google ログイン SDK の設定に必要な
scopeとclient_idのリクエスト パラメータをメモしておきます。 -
Android アプリへの Google ログインの統合を開始するの手順に沿って SDK をセットアップします。前の手順で取得した
client_idを再利用するため、バックエンド サーバーの OAuth 2.0 クライアント ID を取得する手順はスキップできます。 -
サーバーサイド API アクセスの有効化の手順を実施します。これには次の手順が含まれます。
-
getServerAuthCodeメソッドを使用して、権限をリクエストするスコープの認証コードを取得します。 - 認証コードをアプリのバックエンドに送信して、アクセス トークンおよび更新トークンと交換します。
- 取得したアクセス トークンを使用して、ユーザーに代わって Google API を呼び出します。
-
-
コードを調べて、Google の OAuth 2.0 サーバーにリクエストを送信している場所を特定します。カスタム スキームを使用している場合、リクエストは次のようになります。
-
Google API Console でカスタム スキームのサポートを無効にします。
- [OAuth 2.0 認証情報] リストに移動し、Android クライアントを選択します。
- [Advanced Settings] セクションに移動し、[Enable Custom URI Scheme] チェックボックスをオフにして、[Save] をクリックして、カスタム URI スキームのサポートを無効にします。
カスタム URI スキームの有効化
推奨される代替方法ではうまくいかない場合は、次の手順に沿って、Android クライアントのカスタム URI スキームを有効にできます。- [OAuth 2.0 認証情報] リストに移動し、Android クライアントを選択します。
- [Advanced Settings] セクションに移動し、[Enable Custom URI Scheme] チェックボックスをオンにして、[Save] をクリックして、カスタム URI スキームのサポートを有効にします。
OAuth 2.0 レスポンスをアプリに直接配信する Chrome Identity API を使用すると、リダイレクト URI が不要になります。
アプリの所有権を確認する（Android、Chrome）
アプリのなりすましのリスクを軽減するために、アプリの所有権を確認できます。
Android
Google Play デベロッパー アカウントをお持ちで、アプリが Google Play Console に登録されている場合は、確認プロセスを完了するために、そのアカウントを使用できます。検証を成功させるには、次の要件を満たす必要があります。
- 検証対象の Android OAuth クライアントと同じパッケージ名と SHA-1 署名証明書フィンガープリントが設定されたアプリが Google Play Console に登録されている必要があります。
- Google Play Console でアプリに対して管理者権限が必要です。 Google Play Console でのアクセス管理について詳しくは、こちらをご覧ください。
Android クライアントの [Verify App Ownership] セクションで、[Verify Ownership]（所有権を確認）ボタンをクリックして、確認プロセスを完了します。
検証に成功すると、検証プロセスの成功を通知する通知が表示されます。それ以外の場合は、エラー プロンプトが表示されます。
オーナー確認の失敗を解決するには、次の手順をお試しください。
- 検証するアプリが Google Play Console に登録されているアプリであることを確認します。
- Google Play Console で、アプリの管理者権限があることを確認します。
Chrome
確認プロセスを完了するには、Chrome ウェブストア デベロッパー アカウントを使用します。 適格性の確認を受けるには、次の要件を満たす必要があります。
- Chrome ウェブストア デベロッパー ダッシュボードに、確認対象の Chrome 拡張機能 OAuth クライアントと同じアイテム ID で登録されているアイテムが必要です。
- Chrome ウェブストアのアイテムのパブリッシャーである必要があります。 Chrome ウェブストア デベロッパー ダッシュボードでのアクセス管理の詳細をご覧ください。
Chrome 拡張機能クライアントの [Verify App Ownership]（アプリのオーナー権限を確認）セクションで、[Verify Ownership]（所有権を確認）ボタンをクリックして、確認プロセスを完了します。
注: アカウントにアクセス権を付与した後、数分待ってから確認プロセスを完了してください。
検証に成功すると、検証プロセスの成功を通知する通知が表示されます。それ以外の場合は、エラー プロンプトが表示されます。
オーナー確認の失敗を解決するには、次の手順をお試しください。
- 確認する Chrome 拡張機能の OAuth クライアントと同じアイテム ID のアイテムが Chrome ウェブストア デベロッパー ダッシュボードに登録されていることを確認します。
- アプリのパブリッシャーであること（アプリの個別のパブリッシャーか、アプリのグループ投稿者のメンバーであること）を確認します。Chrome ウェブストア デベロッパー ダッシュボードでのアクセス管理の詳細をご確認ください。
- グループ投稿者のリストを更新したばかりの場合は、Chrome ウェブストア デベロッパー ダッシュボードでグループ投稿者のメンバーリストが同期されていることを確認します。 パブリッシャー メンバーシップ リストの同期について詳しくは、こちらをご覧ください。
ループバック IP アドレス（macOS、Linux、Windows パソコン）
この URL を使用して認証コードを受信するには、アプリケーションがローカル ウェブサーバーをリッスンする必要があります。これは、すべてのプラットフォームで利用できるわけではありません。ただし、プラットフォームでサポートされている場合は、これが認証コードを取得するための推奨メカニズムです。
アプリが認可レスポンスを受け取った場合、ユーザビリティの観点から、ブラウザを閉じてアプリに戻るようユーザーに指示する HTML ページを表示することで応答する必要があります。
| 推奨される使用方法 | macOS、Linux、Windows のデスクトップ アプリ（Universal Windows Platform は除く） |
| フォームの値 | アプリケーションの種類を [デスクトップ アプリ] に設定します。 |
手動でのコピー/貼り付け
アクセス スコープを特定する
スコープを使用すると、アプリケーションは必要なリソースへのアクセスのみをリクエストできます。また、ユーザーはアプリケーションに付与するアクセス権の量を制御することもできます。そのため、リクエストするスコープの数とユーザーの同意を得る可能性の間には逆の関係がある場合があります。
OAuth 2.0 認証の実装を開始する前に、アプリがアクセス権限を必要とするスコープを特定することをおすすめします。
OAuth 2.0 API スコープのドキュメントには、Google API へのアクセスに使用できるスコープの一覧が記載されています。
OAuth 2.0 アクセス トークンの取得
以下の手順では、アプリケーションが Google の OAuth 2.0 サーバーとやり取りし、ユーザーの代わりに API リクエストを実行することについてユーザーの同意を得ます。ユーザーの承認が必要な Google API リクエストをアプリケーションで実行するには、この同意が必要です。
ステップ 1: コード検証とチャレンジを生成する
Google は、インストール済みのアプリフローのセキュリティを高めるため、Proof Key for Code Exchange（PKCE）プロトコルをサポートしています。認可リクエストごとに一意のコード検証ツールが作成され、変換された値（「code_challenge」と呼ばれる）が認可サーバーに送信されて認可コードを取得します。
コード検証ツールを作成する
code_verifier は、予約されていない文字 [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" を使用する高エントロピー暗号ランダム文字列で、最小文字数は 43 文字、最大文字数は 128 文字です。
コード検証ツールには、値の推測が実用的にならないように、十分なエントロピーが必要です。
コード作成チャレンジ
コード チャレンジを作成する 2 つの方法がサポートされています。
| コード チャレンジ生成メソッド | |
|---|---|
| S256（推奨） | コード チャレンジは、Base64URL（パディングなし）でエンコードされたコード検証ツールの SHA256 ハッシュです。
|
| プレーン | コード チャレンジは、上記で生成されたコード検証ツールと同じ値です。
|
ステップ 2: Google の OAuth 2.0 サーバーにリクエストを送信する
ユーザー承認を取得するには、Google の承認サーバーに https://accounts.google.com/o/oauth2/v2/auth でリクエストを送信します。このエンドポイントは、アクティブ セッションの検索を処理し、ユーザーを認証して、ユーザーの同意を取得します。エンドポイントには SSL を介してのみアクセスでき、HTTP（非 SSL）接続は拒否されます。
認可サーバーは、インストール済みのアプリケーションについて、次のクエリ文字列パラメータをサポートしています。
| パラメータ | |||||||
|---|---|---|---|---|---|---|---|
client_id |
必須
アプリケーションのクライアント ID。この値は API Console Credentials pageで確認できます。 |
||||||
redirect_uri |
必須
Google の承認サーバーがレスポンスをアプリに送信する方法を指定します。インストール済みのアプリで使用できるリダイレクト オプションはいくつかあり、特定のリダイレクト方法を念頭に置いて認可認証情報をセットアップします。 この値は、OAuth 2.0 クライアントで承認されたリダイレクト URI のいずれかと完全に一致する必要があります。これは、クライアントの API Console
Credentials pageに構成したものです。この値が承認済みの URI と一致しない場合、 各メソッドの適切な
|
||||||
response_type |
必須
Google OAuth 2.0 エンドポイントが認可コードを返すかどうかを指定します。 インストール済みのアプリのパラメータ値を |
||||||
scope |
必須
ユーザーの代わりにアプリケーションがアクセスできるリソースを指定するスコープのスペース区切りリスト。これらの値は、Google がユーザーに表示する同意画面に反映されます。 スコープを使用すると、アプリケーションは必要なリソースへのアクセスのみをリクエストできます。また、ユーザーはアプリケーションに付与するアクセス権の量を制御することもできます。したがって、リクエストされるスコープの数とユーザーの同意を得る可能性には反比例します。 |
||||||
code_challenge |
推奨
認可コードの交換時にサーバーサイド チャレンジとして使用される、エンコード済みの |
||||||
code_challenge_method |
推奨
認可コードの交換時に使用される |
||||||
state |
推奨
アプリケーションが認可リクエストと認可サーバーのレスポンスの間で状態を維持するために使用する任意の文字列値を指定します。ユーザーがアプリケーションのアクセス リクエストに同意または拒否すると、サーバーは このパラメータは、アプリ内の適切なリソースにユーザーを誘導する、ノンスを送信する、クロスサイト リクエスト フォージェリを抑制するなど、さまざまな目的で使用できます。 |
||||||
login_hint |
省略可
認証しようとしているユーザーをアプリケーションが認識している場合は、このパラメータを使用して、Google 認証サーバーにヒントを提供できます。サーバーはこのヒントを使用して、ログイン フォームのメール フィールドに事前入力するか、適切なマルチログイン セッションを選択することで、ログインフローを簡素化します。 パラメータ値を、ユーザーの Google ID に相当するメールアドレスまたは |
||||||
認可 URL の例
以下のタブに、リダイレクト URI オプションごとの認証 URL のサンプルを示します。
redirect_uri パラメータの値を除き、URL は同じです。URL には、必須の response_type パラメータと client_id パラメータ、省略可能な state パラメータも含まれています。読みやすくするため、各 URL には改行とスペースが含まれています。
カスタム URI スキーム
https://accounts.google.com/o/oauth2/v2/auth? scope=email%20profile& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=com.example.app%3A/oauth2redirect& client_id=client_id
ループバック IP アドレス
https://accounts.google.com/o/oauth2/v2/auth? scope=email%20profile& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=http%3A//127.0.0.1%3A9004& client_id=client_id
ステップ 3: Google がユーザーに同意を求める
このステップでは、ユーザーは、リクエストされたアクセス権をアプリケーションに付与するかどうかを判断します。この段階では、アプリケーションの名前と、ユーザーの認証情報を使用してアクセス権限をリクエストしている Google API サービスの名前、付与するアクセス スコープの概要を示す同意ウィンドウが表示されます。ユーザーは、アプリケーションからリクエストされた 1 つ以上のスコープへのアクセスを許可することも、リクエストを拒否することもできます。
アプリケーションは、アクセスが許可されたことを示す Google の OAuth 2.0 サーバーからのレスポンスを待つため、この段階では何も行う必要はありません。このレスポンスについては、次の手順で説明します。
エラー
Google の OAuth 2.0 認可エンドポイントへのリクエストでは、想定される認証と認可のフローではなく、ユーザー向けのエラー メッセージが表示されることがあります。一般的なエラーコードと推奨の解決策を以下に示します。
admin_policy_enforced
Google アカウントは、Google Workspace 管理者のポリシーにより、リクエストされた 1 つ以上のスコープを承認できません。OAuth クライアント ID に明示的にアクセス権が付与されるまで、管理者がすべてのスコープまたは機密性の高いスコープおよび制限付きスコープへのアクセスを制限する方法については、Google Workspace 管理者のヘルプ記事の Google Workspace データにアクセスするサードパーティ製アプリと内部アプリを制御するをご覧ください。
disallowed_useragent
認可エンドポイントは、Google の OAuth 2.0 ポリシーで許可されていない埋め込みのユーザー エージェント内に表示されています。
Android
Android デベロッパーが android.webkit.WebView で承認リクエストを開く際に、このエラー メッセージが表示されることがあります。デベロッパーは、代わりに Android 用 Google ログインや OpenID Foundation の AppAuth for Android などの Android ライブラリを使用する必要があります。
Android アプリが埋め込みのユーザー エージェントで一般的なウェブリンクを開き、ユーザーがサイトから Google の OAuth 2.0 認可エンドポイントに移動すると、ウェブ デベロッパーがこのエラーが発生することがあります。デベロッパーは、オペレーティング システムのデフォルトのリンクハンドラで一般的なリンクを開くことを許可する必要があります。これには、Android アプリリンク ハンドラとデフォルトのブラウザアプリの両方が含まれます。Android カスタムタブ ライブラリもサポートされているオプションです。
iOS
iOS または macOS のデベロッパーは、WKWebView で認証リクエストを開く際にこのエラーが発生することがあります。デベロッパーは、代わりに iOS 用の Google ログインや OpenID Foundation の AppAuth for iOS などの iOS ライブラリを使用する必要があります。
iOS または macOS のアプリが埋め込みユーザー エージェントで一般的なウェブリンクを開き、ユーザーがサイトから Google の OAuth 2.0 認可エンドポイントに移動すると、ウェブ デベロッパーがこのエラーが発生することがあります。デベロッパーは、オペレーティング システムのデフォルトのリンクハンドラで一般的なリンクを開くことを許可する必要があります。これには、ユニバーサル リンク ハンドラとデフォルトのブラウザアプリの両方が含まれます。SFSafariViewController ライブラリもサポートされているオプションです。
org_internal
リクエスト内の OAuth クライアント ID は、特定の Google Cloud 組織内の Google アカウントへのアクセスを制限するプロジェクトの一部です。この構成オプションの詳細については、OAuth 同意画面の設定に関するヘルプ記事のユーザータイプのセクションをご覧ください。
invalid_grant
コード検証ツールとチャレンジを使用している場合は、code_callenge パラメータが無効であるか存在しません。code_challenge パラメータが正しく設定されていることを確認します。
アクセス トークンの更新時に、トークンが期限切れか無効になっている可能性があります。 ユーザーを再度認証し、新しいトークンの取得に関するユーザーの同意を求めます。このエラーが引き続き表示される場合は、アプリケーションが正しく構成されていること、リクエストで正しいトークンとパラメータを使用していることを確認してください。それ以外の場合は、ユーザー アカウントが削除または無効化されている可能性があります。
redirect_uri_mismatch
認可リクエストで渡された redirect_uri が、OAuth クライアント ID の承認済みのリダイレクト URI と一致しません。 Google API Console Credentials pageで承認済みのリダイレクト URI を確認します。
渡された redirect_uri は、このクライアント タイプに対して無効である可能性があります。
redirect_uri パラメータは、非推奨となり、サポートされなくなった OAuth 帯域外（OOB）フローを参照している可能性があります。統合を更新するには、移行ガイドをご覧ください。
invalid_request
リクエストした内容に問題がありました。これにはいくつかの理由が考えられます。
- リクエストの形式が正しくありません
- リクエストに必須パラメータがありません
- リクエストで、Google がサポートしていない認証方法が使用されています。OAuth 統合で推奨の統合方法が使用されていることを確認する
- リダイレクト URI にカスタム スキームが使用されている: 「Custom URI scheme is not supported on Chrome apps」または「Custom URI scheme is not enabled for your Android client」というエラー メッセージが表示される場合は、Chrome アプリでサポートされておらず、Android ではデフォルトで無効になっていますが、カスタム URI スキームが使用されていることを意味します。詳しくは、カスタム URI スキームの代替方法をご覧ください。
ステップ 4: OAuth 2.0 サーバーのレスポンスを処理する
アプリケーションが認可レスポンスを受け取る方法は、使用するリダイレクト URI スキームによって異なります。スキームに関係なく、レスポンスには認証コード（code）またはエラー（error）が含まれます。たとえば、error=access_denied はユーザーがリクエストを拒否したことを示します。
ユーザーがアプリケーションにアクセス権を付与した場合、次のステップで説明するように、認証コードをアクセス トークンと更新トークンと交換できます。
ステップ 5: 更新トークンとアクセス トークンの認証コードを交換する
認可コードをアクセス トークンと交換するには、https://oauth2.googleapis.com/token エンドポイントを呼び出して、次のパラメータを設定します。
| フィールド | |
|---|---|
client_id |
Credentials pageから取得した API Consoleクライアント ID。 |
client_secret |
Credentials pageから取得した API Consoleクライアント シークレット。 |
code |
最初のリクエストから返された認証コード。 |
code_verifier |
ステップ 1 で作成したコード検証ツール。 |
grant_type |
OAuth 2.0 仕様で定義されているように、このフィールドの値は authorization_code に設定する必要があります。 |
redirect_uri |
指定された client_id の API Console
Credentials page でプロジェクトに対して一覧表示されたリダイレクト URI のいずれか。 |
次のスニペットにサンプル リクエストを示します。
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=http://127.0.0.1:9004& grant_type=authorization_code
Google はこのリクエストに対して、有効期間の短いアクセス トークンと更新トークンを含む JSON オブジェクトを返します。
レスポンスには、次のフィールドが含まれます。
| フィールド | |
|---|---|
access_token |
Google API リクエストを認可するためにアプリケーションが送信するトークン。 |
expires_in |
アクセス トークンの残りの存続期間（秒）。 |
id_token |
注: このプロパティは、リクエストに ID スコープ（openid、profile、email など）が含まれていた場合にのみ返されます。値は、ユーザーに関するデジタル署名された ID 情報を含む JSON Web Token（JWT）です。 |
refresh_token |
新しいアクセス トークンの取得に使用できるトークン。更新トークンは、ユーザーがアクセスを取り消すまで有効です。 インストール済みのアプリケーションに対しては、更新トークンが常に返されます。 |
scope |
access_token によって付与されるアクセスの範囲。スペース区切りの文字列（大文字と小文字を区別）のリストとして表されます。 |
token_type |
返されたトークンのタイプ。この時点で、このフィールドの値は常に Bearer に設定されます。 |
次のスニペットにサンプル レスポンスを示します。
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"expires_in": 3920,
"token_type": "Bearer",
"scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
"refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}
Google API の呼び出し
アプリケーションがアクセス トークンを取得した後、API に必要なアクセスのスコープが付与されていれば、そのトークンを使用して、特定のユーザー アカウントに代わって Google API を呼び出すことができます。これを行うには、access_token クエリ パラメータまたは Authorization HTTP ヘッダーの Bearer 値のいずれかを含めて、API へのリクエストにアクセス トークンを含めます。クエリ文字列はサーバーログに表示される傾向があるため、可能であれば HTTP ヘッダーを使用することをおすすめします。ほとんどの場合、クライアント ライブラリを使用して Google API の呼び出しをセットアップできます（Drive Files API の呼び出しなど）。
OAuth 2.0 Playground では、すべての Google API とそのスコープを確認できます。
HTTP GET の例
Authorization: Bearer HTTP ヘッダーを使用した
drive.files エンドポイント（Drive Files API）の呼び出しは、次のようになります。独自のアクセス トークンを指定する必要があります。
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
access_token クエリ文字列パラメータを使用した、認証されたユーザーに対する同じ API の呼び出しの例を次に示します。
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl の例
これらのコマンドは、curl コマンドライン アプリケーションでテストできます。HTTP ヘッダー オプションを使用した例を次に示します（推奨）。
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
または、クエリ文字列パラメータ オプション:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
アクセス トークンをリフレッシュする
アクセス トークンは定期的に期限が切れ、関連する API リクエストに対して無効な認証情報になります。トークンに関連付けられたスコープへのオフライン アクセスをリクエストした場合、ユーザーに権限をリクエストしなくても（ユーザーが不在の場合を含めて）アクセス トークンを更新できます。
アクセス トークンを更新するには、アプリケーションが次のパラメータを含む HTTPS POST リクエストを Google の承認サーバー（https://oauth2.googleapis.com/token）に送信します。
| フィールド | |
|---|---|
client_id |
API Consoleから取得したクライアント ID。 |
client_secret |
API Consoleから取得したクライアント シークレット。（client_secret は、Android、iOS、Chrome アプリケーションとして登録されたクライアントからのリクエストには適用されません）。
|
grant_type |
OAuth 2.0 仕様で定義されているように、このフィールドの値は refresh_token に設定する必要があります。 |
refresh_token |
認可コード交換から返された更新トークン。 |
次のスニペットにサンプル リクエストを示します。
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
ユーザーがアプリケーションに付与されたアクセスを取り消さない限り、トークン サーバーは新しいアクセス トークンを含む JSON オブジェクトを返します。次のスニペットにサンプル レスポンスを示します。
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"expires_in": 3920,
"scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
"token_type": "Bearer"
}
発行される更新トークンの数には制限があります。クライアントとユーザーの組み合わせごとに 1 つ、すべてのクライアントでユーザーごとに 1 つの制限があります。更新トークンは長期間保存し、有効な間は継続して使用する必要があります。アプリケーションがリクエストする更新トークンが多すぎると、これらの制限に達することがあり、その場合は古い更新トークンが機能しなくなります。
トークンの取り消し
場合によっては、ユーザーがアプリケーションに与えられたアクセス権の取り消しを希望することがあります。ユーザーは アカウント設定にアクセスしてアクセス権を取り消すことができます。詳しくは、サポート ドキュメント「アカウントにアクセスできるサードパーティのサイトやアプリのサイトやアプリのアクセス権の削除」をご覧ください。
また、アプリケーションに付与されているアクセス権をプログラムで取り消すこともできます。プログラムによる取り消しは、ユーザーがアプリケーションの登録を解除した場合や、アプリケーションを削除した場合、またはアプリに必要な API リソースが大幅に変更された場合などに重要です。つまり、削除プロセスに、以前にアプリに付与された権限を確実に削除するための API リクエストを含めることができます。
プログラムでトークンを取り消すには、アプリケーションは https://oauth2.googleapis.com/revoke にリクエストを行い、トークンをパラメータとして含めます。
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/revoke?token={token}
トークンはアクセス トークンまたは更新トークンのいずれかです。トークンがアクセス トークンで、対応する更新トークンがある場合、更新トークンも取り消されます。
取り消しが正常に処理されると、レスポンスの HTTP ステータス コードは 200 になります。エラーが発生すると、HTTP ステータス コード 400 がエラーコードとともに返されます。
関連情報
ここで説明するベスト プラクティスの多くが、IETF の現在のベスト プラクティスである OAuth 2.0 for Native Apps で確立されています。