モバイルおよびデスクトップアプリ用のOAuth2.0

このドキュメントでは、電話、タブレット、コンピューターなどのデバイスにインストールされているアプリケーションが、GoogleのOAuth2.0エンドポイントを使用してGoogleAPIへのアクセスを承認する方法について説明します。

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

インストールされたアプリは個々のデバイスに配布され、これらのアプリは秘密を保持できないと想定されています。ユーザーがアプリを使用しているとき、またはアプリがバックグラウンドで実行されているときに、GoogleAPIにアクセスできます。

この承認フローがために使用されるものと類似しているWebサーバのアプリケーション。主な違いは、インストールされたアプリはシステムブラウザを開き、Googleの認証サーバーからの応答を処理するためにローカルリダイレクトURIを提供する必要があることです。

代替案

モバイルアプリのためには、Googleサインインのために使用することを好むかもしれアンドロイドiOSのを。 Googleログインクライアントライブラリは認証とユーザー認証を処理し、ここで説明する低レベルのプロトコルよりも実装が簡単な場合があります。

システムブラウザをサポートしていたりしていないデバイス上で動作しているアプリケーションの場合は、そのようなテレビ、ゲーム機、カメラ、またはプリンタなどの入力機能を、限られている、見るテレビ&デバイス用のOAuth 2.0のか、 Googleのサインインデバイス用

ライブラリとサンプル

このドキュメントで説明されているOAuth2.0フローの実装に役立つ、次のライブラリとサンプルをお勧めします。

前提条件

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

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

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

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

承認資格情報を作成する

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

  1. Go to the Credentials page.
  2. >のOAuthクライアントIDを認証情報を作成]をクリックします。
  3. 以下のセクションでは、Googleの認証サーバーがサポートするクライアントタイプとリダイレクト方法について説明します。アプリケーションに推奨されるクライアントタイプを選択し、OAuthクライアントに名前を付け、フォームの他のフィールドを適切に設定します。

カスタムURIスキーム(Android、iOS、UWP)

Androidアプリ、iOSアプリ、ユニバーサルWindowsプラットフォーム(UWP)アプリには、カスタムURIスキームをお勧めします。

アンドロイド
  1. Androidアプリケーションの種類を選択します。
  2. OAuthクライアントの名前を入力します。この名前は、プロジェクトの上に表示され Credentials page クライアントを識別するために。
  3. Androidアプリのパッケージ名を入力します。この値は、で定義されているpackageの属性<manifest>要素アプリのマニフェストファイルインチ
  4. アプリ配布のSHA-1署名証明書のフィンガープリントを入力します。
    • あなたのアプリが使用している場合は、Googleのプレイでアプリの署名を、プレイコンソールのアプリの署名ページからSHA-1フィンガープリントをコピーします。
    • 独自のキーストアと署名鍵を管理する場合は、人間が読める形式で証明書情報を印刷するには、Javaに付属のkeytoolユーティリティを使用します。コピーSHA1中で値をCertificate fingerprintsのkeytool出力のセクション。参照してくださいあなたのクライアントの認証の詳細は、AndroidのドキュメントをGoogleのAPIに。
  5. [作成]をクリックします。
iOS
  1. iOSアプリケーションの種類を選択します。
  2. OAuthクライアントの名前を入力します。この名前は、プロジェクトの上に表示され Credentials page クライアントを識別するために。
  3. アプリのバンドル識別子を入力します。バンドルIDは、の値であるCFBundleIdentifierの、アプリケーションの情報プロパティリストのリソースファイル(info.plistファイル)でキーを押します。この値は、最も一般的には、Xcodeプロジェクトエディタの[一般]ペインまたは[署名と機能]ペインに表示されます。バンドルIDは、また、上のアプリのためのアプリ情報ページの一般情報セクションに表示されているAppleのApp Store Connectサイト
  4. (オプション)

    アプリがAppleのAppStoreで公開されている場合は、アプリのApp StoreIDを入力します。ストアIDは、すべてのApple App StoreURLに含まれる数値文字列です。

    1. 開くAppleのApp Storeのアプリをお使いのiOSやiPadOSデバイス上で。
    2. アプリを検索します。
    3. [共有]ボタン(正方形と上向き矢印の記号)を選択します。
    4. リンクをコピー]選択します。
    5. リンクをテキストエディタに貼り付けます。 App StoreIDはURLの最後の部分です。

      例: https://apps.apple.com/app/google/id 284815942

  5. (オプション)

    チームIDを入力します。参照してくださいあなたのチームのIDを検索します詳しくは、Appleデベロッパアカウントのドキュメントで。

  6. [作成]をクリックします。
UWP
  1. ユニバーサルのWindowsプラットフォームアプリケーションの種類を選択します。
  2. OAuthクライアントの名前を入力します。この名前は、プロジェクトの上に表示され Credentials page クライアントを識別するために。
  3. アプリの12文字のMicrosoftストアIDを入力します。あなたには、この値を見つけることができますマイクロソフトパートナーセンターアプリケーションアイデンティティアプリケーション管理部のページ。
  4. [作成]をクリックします。

UWPアプリの場合、カスタムURIスキームは39文字を超えることはできません。

ループバックIPアドレス(macOS、Linux、Windowsデスクトップ)

このURLを使用して認証コードを受け取るには、アプリケーションがローカルWebサーバーでリッスンしている必要があります。これは、すべてではありませんが、多くのプラットフォームで可能です。ただし、プラットフォームでサポートされている場合は、これが認証コードを取得するための推奨メカニズムです。

アプリが承認応答を受信すると、使いやすさを最大限に高めるために、ユーザーにブラウザーを閉じてアプリに戻るように指示するHTMLページを表示して応答する必要があります。

推奨される使用法macOS、Linux、およびWindowsデスクトップ(ユニバーサルWindowsプラットフォームは除く)アプリ
フォーム値デスクトップアプリへのアプリケーションの種類を設定します。

手動コピー/貼り付け

アクセス範囲を特定する

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

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

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

OAuth2.0アクセストークンの取得

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

ステップ1:コードベリファイアを生成してチャレンジする

Googleがサポートしているコードの交換のための証明キーインストールアプリの流れをより安全にする(PKCE)プロトコルを。すべての認証リクエストに対して一意のコードベリファイアが作成され、「code_challenge」と呼ばれるその変換された値が認証サーバーに送信されて、認証コードが取得されます。

コードベリファイアを作成する

code_verifier " - " / [AZ] / [AZ] / [0-9] /非予約文字を使用して、高エントロピー暗号ランダムな文字列です"" / "_" / "〜"、最小長は43文字、最大長は128文字。

コードベリファイアは、値を推測するのが実用的でないように十分なエントロピーを持っている必要があります。

コードチャレンジを作成する

コードチャレンジを作成する2つの方法がサポートされています。

コードチャレンジ生成方法
S256(推奨)コードの課題は、コードベリファイアのBase64URL(パディングなし)でエンコードされたSHA256ハッシュです。
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
プレーンコードチャレンジは、上記で生成されたコードベリファイアと同じ値です。
code_challenge = code_verifier

ステップ2:GoogleのOAuth2.0サーバーにリクエストを送信する

ユーザーの許可を取得するには、Googleの承認サーバーに要求を送信https://accounts.google.com/o/oauth2/v2/auth 。このエンドポイントは、アクティブなセッションルックアップを処理し、ユーザーを認証して、ユーザーの同意を取得します。エンドポイントはSSL経由でのみアクセス可能であり、HTTP(非SSL)接続を拒否します。

許可サーバーは、インストールされているアプリケーションに対して次の照会文字列パラメーターをサポートします。

パラメーター
client_id必須

アプリケーションのクライアントID。あなたには、この値を見つけることができ API ConsoleCredentials page

redirect_uri必須

Googleの認証サーバーがアプリに応答を送信する方法を決定します。そこにインストールアプリのに利用可能ないくつかのリダイレクトオプションがあり、あなたの設定したでしょう、認証資格情報を念頭に置いて、特定のリダイレクト方法で。

値は正確にあなたのクライアントの中に構成されたOAuth 2.0のクライアントのための認可リダイレクトリダイレクトURIの1と一致しなければなりません API ConsoleCredentials page。この値は、許可URIに一致しない場合は、取得しますredirect_uri_mismatchエラーを。

下表適切redirect_uri各メソッドのパラメータ値:

redirect_uri
カスタムURIスキームcom.example.app : redirect_uri_path

また

com.googleusercontent.apps.123 : redirect_uri_path
  • com.example.appあなたのコントロール下でのドメインのDNS逆表記です。カスタムスキームには、有効である期間が含まれている必要があります。
  • com.googleusercontent.apps.123クライアントIDの逆DNS表記です。
  • redirect_uri_path例えば、オプションのパスコンポーネントである/oauth2redirect 。パスは、通常のHTTP URLとは異なり、単一のスラッシュで始まる必要があることに注意してください。
ループバックIPアドレスhttp://127.0.0.1: portまたはhttp://[::1]: port

プラットフォームに関連するループバックIPアドレスを照会し、ランダムに使用可能なポートでHTTPリスナーを開始します。代替port実際のポート番号とは、あなたのアプリがリッスンします。

手動コピー/貼り付けurn:ietf:wg:oauth:2.0:oob
プログラムによる抽出urn:ietf:wg:oauth:2.0:oob:auto
response_type必須

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

パラメータ値を設定しcodeインストールしたアプリケーションのために。

scope必須

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

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

code_challengeおすすめされた

エンコードを指定しcode_verifier認証コード交換中に、サーバー側の課題として使用されます。参照してくださいコードのチャレンジ作成詳細については、上記のセクションを。

code_challenge_methodおすすめされた

指定は、どのような方法でエンコードするために使用されたcode_verifier認証コード交換中に使用されます。このパラメータは、一緒に使用する必要がありますcode_challenge上記のパラメータ。値code_challenge_methodデフォルトplain含む要求に存在しない場合code_challenge 。このパラメータにのみサポートされている値はS256plain

stateおすすめされた

アプリケーションが承認要求と承認サーバーの応答の間の状態を維持するために使用する文字列値を指定します。サーバーは、あなたのように送ることを正確な値を返しますname=value URLのフラグメント識別子でペア( #の) redirect_uriするユーザーが同意した後、またはアプリケーションのアクセス要求を拒否します。

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

login_hintオプション

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

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

サンプル認証URL

以下のタブは、さまざまなリダイレクトURIオプションのサンプル認証URLを示しています。

URLはの値を除いて同一であるredirect_uriパラメータ。 URLはまた、必要含むresponse_typeclient_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

コピーペースト

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=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&
 client_id=client_id

プログラムによる抽出

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=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
 client_id=client_id

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

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

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

エラー

GoogleのOAuth2.0承認エンドポイントへのリクエストでは、予想される認証と承認のフローではなく、ユーザー向けのエラーメッセージが表示される場合があります。一般的なエラーコードと推奨される解決策を以下に示します。

admin_policy_enforced

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

disallowed_useragent

認可エンドポイントは、Googleのことで許可されていない組み込みユーザーエージェント内で表示されるOAuth 2.0のポリシー

アンドロイド

で承認リクエストを開くときにAndroidの開発者は、このエラーメッセージが発生することがありandroid.webkit.WebView 。開発者は、代わりのようなアンドロイドのライブラリを使用する必要があり、GoogleのAndroidのためのサインインまたはのOpenID FoundationのAndroid向けAppAuthを

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

iOS

で承認リクエストを開くときにiOSとMacOSの開発者は、このエラーが発生することがありWKWebView 。開発者は、代わりのようなiOSのライブラリを使用する必要がありますGoogleのiOS用のサインインやOpenIDの財団のiOS用AppAuth

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

org_internal

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

redirect_uri_mismatch

redirect_uri認可要求に渡されたのOAuthクライアントIDのために認可されたリダイレクトURIと一致していません。レビューはでリダイレクトURIを許可 Google API Console Credentials page

渡されたredirect_uriクライアントタイプのために無効になることがあります。

ステップ4:OAuth2.0サーバーの応答を処理する

アプリケーションが許可応答を受信する方法は、依存するリダイレクトURIスキームが使用すること。かかわらずスキームの、応答のいずれか認証コード(含まれていますcode )または誤り( error )。例えば、 error=access_deniedユーザが要求を拒否していることを示しています。

ユーザーがアプリケーションへのアクセスを許可した場合、次の手順で説明するように、認証コードをアクセストークンと更新トークンに交換できます。

ステップ5:更新トークンとアクセストークンの認証コードを交換する

アクセストークンの承認コードを交換するには、呼び出しhttps://oauth2.googleapis.com/tokenエンドポイントと次のパラメータを設定します。

田畑
client_id取得したクライアントID API ConsoleCredentials page
client_secret取得したクライアントシークレット API ConsoleCredentials page
code最初のリクエストから返された認証コード。
code_verifierあなたが作成した検証コードステップ1
grant_type OAuth 2.0の仕様で定義されているように、このフィールドの値に設定する必要がありますauthorization_code
redirect_uriあなたのプロジェクトのためにリストされたリダイレクトURIの一つ API ConsoleCredentials page 与えられたためclient_id

次のスニペットは、サンプルリクエストを示しています。

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=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
grant_type=authorization_code

Googleは、短期間のアクセストークンと更新トークンを含むJSONオブジェクトを返すことで、このリクエストに応答します。

応答には次のフィールドが含まれます。

田畑
access_tokenアプリケーションがGoogleAPIリクエストを承認するために送信するトークン。
expires_inアクセストークンの残りの有効期間(秒単位)。
id_token注:あなたの要求のようなアイデンティティスコープ、含まれている場合、このプロパティは、返されたopenidprofile 、または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"
}

GoogleAPIの呼び出し

アプリケーションがアクセストークンを取得した後、APIに必要なアクセス範囲が許可されている場合は、トークンを使用して、特定のユーザーアカウントに代わってGoogleAPIを呼び出すことができます。これを行うには、いずれかを含むことにより、APIへのリクエストにアクセストークン含むaccess_token 、クエリパラメータまたはAuthorization HTTPヘッダーBearer値。クエリ文字列はサーバーログに表示される傾向があるため、可能な場合はHTTPヘッダーを使用することをお勧めします。ほとんどの場合、あなたは、GoogleのAPIへのあなたの通話を設定するには、クライアントライブラリを使用することができます(例えば、時にドライブのファイルAPIを呼び出します)。

あなたはすべてのGoogleのAPIを試してみるとで彼らのスコープを表示することができOAuth 2.0の遊び場

HTTPGETの例

呼び出しdrive.filesエンドポイント(ドライブファイルのAPI)を使用してAuthorization: Bearer HTTPヘッダーには、次のようになります。独自のアクセストークンを指定する必要があることに注意してください。

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

ここで使用して認証されたユーザーのために、同じAPIの呼び出しですaccess_token 、クエリ文字列パラメータは:

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取得したクライアントID API Console
client_secret取得したクライアントシークレット API Console。 ( client_secretアンドロイド、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つの制限、およびすべてのクライアントにわたるユーザーごとに別の制限。更新トークンは長期保存に保存し、有効である限り使用し続ける必要があります。アプリケーションが要求する更新トークンが多すぎると、これらの制限に達する可能性があります。その場合、古い更新トークンは機能しなくなります。

トークンを取り消す

場合によっては、ユーザーはアプリケーションに与えられたアクセスを取り消すことができます。ユーザーが訪問してアクセスを取り消すことができるアカウント設定を。参照してください。アカウントへのアクセス権を持つサードパーティのサイト&アプリを削除サイトやアプリのアクセスセクションを詳細については、サポートドキュメント。

アプリケーションが、与えられたアクセスをプログラムで取り消すことも可能です。プログラムによる失効は、ユーザーが登録を解除したり、アプリケーションを削除したり、アプリに必要な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は、ここに文書化のベストプラクティスの多くを確立します。