モバイル / デスクトップ アプリ用の OAuth 2.0

注: OAuth 2.0 を初めて使用する場合は、 始める前に、OAuth 2.0 の概要を確認してください。「 に、Google がサポートしている OAuth 2.0 フローの概要が記載されています。 アプリケーションに適したフローを選択している。

このドキュメントでは、スマートフォン、タブレット、Android スマートフォンなどのデバイスに コンピュータは、Google の OAuth 2.0 エンドポイントを使用して、 Google API

OAuth 2.0 を使用すると、ユーザーは特定のデータをアプリケーションと共有する一方で、 他の情報を保護します。 たとえば、アプリケーションは OAuth 2.0 を使用して、 ユーザーが自分の Google ドライブにファイルを保存できるようにしています。

インストール済みのアプリは個々のデバイスに配信されるため、それらのアプリは シークレットを保持できません。ユーザーはアプリを開いているときや バックグラウンドで実行されています。

この承認フローは、Terraform ワークフローの ウェブサーバー アプリケーション。主な違いは システム ブラウザを開き、ローカル リダイレクト URI を指定して Google の承認サーバーから返されるレスポンスを照合します。

代替手段

モバイルアプリでは、Google ログインを Android または iOS:Google ログイン 認証とユーザーの認可はクライアント ライブラリで処理します。また、使用が簡単なほうが 実装されているプロトコルよりも優れています。

システム ブラウザをサポートしていないデバイスまたは入力が制限されているデバイスで実行されているアプリの場合 機能（テレビ、ゲーム機、カメラ、プリンタなど）については、 テレビおよびデバイス または「テレビや入力が制限されているデバイスでログインする」といった機能を試します。

ライブラリとサンプル

OAuth 2.0 フローの実装には、次のライブラリとサンプルが役立ちます。 次のとおりです。

• Android 用 AppAuth ライブラリ
• iOS 用 AppAuth ライブラリ
• アプリ用の OAuth: Windows サンプル

前提条件

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

Google 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.

承認認証情報を作成する

OAuth 2.0 を使用して Google API にアクセスするアプリケーションには、認証情報が必要です。 アプリケーションを識別する API を Google の OAuth 2.0 サーバーに提供します。次の手順では、 プロジェクトの認証情報を作成します。これにより、アプリケーションは認証情報を使用して API にアクセスできるようになります。 有効にする必要があります

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

Android

1. アプリケーションの種類として [Android] を選択します。
2. OAuth クライアントの名前を入力します。この名前はプロジェクトの Credentials page : クライアントを識別します。
3. Android アプリのパッケージ名を入力します。この値は <manifest> 要素の package 属性 追加します。
4. アプリの配布物の SHA-1 署名証明書フィンガープリントを入力します。
   • アプリで Google Play アプリ署名、SHA-1 フィンガープリントを作成します。
   • 独自のキーストアと署名鍵を管理している場合は、keytool ユーティリティを使用してください を使用して、人が読める形式で証明書情報を出力します。「 「Certificate fingerprints」セクションの SHA1 値 keytool の出力。詳しくは、 クライアントの認証の Android 用 Google API のドキュメントをご覧ください。
5. （省略可）Android の所有権を確認する 説明します。
6. [作成] をクリックします。

iOS

1. アプリケーションの種類として [iOS] を選択します。
2. OAuth クライアントの名前を入力します。この名前はプロジェクトの Credentials page : クライアントを識別します。
3. アプリのバンドル ID を入力します。バンドル ID は CFBundleIdentifier キーをアプリ情報プロパティ リスト リソース ファイル（info.plist）に追加します。この値 [全般] ペインや [署名と署名] ペインで[Capabilities]ペインでは Xcode プロジェクト エディタです。バンドル ID は、Google Cloud コンソールの [全般情報] セクションに アプリの [App Information] ページを Apple の App Store Connect サイト。
4. （オプション）。

   アプリが Apple の App Store で公開されている場合は、アプリの App Store ID を入力します。店舗 ID: すべての Apple App Store の URL に含まれる数値文字列。

   1. アプリ Apple App Store アプリ iOS または iPadOS デバイスでダウンロードしてください。
   2. 自分のアプリを探します。
   3. [共有] ボタン（四角形と上矢印）を選択します。
   4. [リンクをコピー] を選択します。
   5. コピーしたリンクをテキスト エディタに貼り付けます。URL の最後の部分が App Store ID です。

      例: https://apps.apple.com/app/google/id284815942

5. （オプション）。

   チーム ID を入力します。詳しくは、 チーム ID を確認する を参照してください。

6. [作成] をクリックします。

UWP

1. アプリケーションの種類として [Universal Windows Platform] を選択します。
2. OAuth クライアントの名前を入力します。この名前はプロジェクトの Credentials page : クライアントを識別します。
3. アプリの 12 文字の Microsoft Store ID を入力してください。この値は Microsoft パートナー センター 日付 アプリ ID [アプリ管理] セクションで
4. [作成] をクリックします。

UWP アプリの場合、カスタム URI スキームは 39 文字以下にする必要があります。

カスタム URI スキーム（Android、iOS、UWP）

カスタム URI スキームはディープリンクの一種で、カスタム定義のスキームを使用してアプリを開きます。

重要: カスタム URI スキームは新しい Chrome アプリではサポートされなくなり、 アプリのなりすましのリスクがあるため、新しい Android クライアントではデフォルトで無効になっています。

Android でのカスタム URI スキームの使用に代わる方法

こちらの Android 向け Google ログイン SDK この方法では、OAuth 2.0 レスポンスがアプリに直接配信されるため、 指定します。

Android 用 Google ログイン SDK に移行する方法

現在 Android で OAuth 統合にカスタム スキームを使用している場合は、次の操作を行う必要があります。 推奨される Google ログインの使用に完全に移行するには、以下の対応を行ってください Android SDK:

1. Google ログイン SDK を使用するようにコードを更新します。
2. Google API Console でカスタム スキームのサポートを無効にします。

注: コードの更新を完了してデプロイする必要があります（導入時期も考慮してください）。 古いデバイスへの更新を行ってから、カスタム スキームのサポートを 使用しないように、Google API Console を使用して、 invalid_request エラー メッセージ ユーザーがアプリを使おうとした場合に 通知されるようになります

Google Sign-In Android SDK に移行する手順は次のとおりです。

1. Google Sign-In Android SDK を使用するようにコードを更新します。
   1. コードを調べて、現在の状態を特定する 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 です。 使用します。詳しくは、 形式の詳細に関する redirect_uri パラメータの定義 カスタム URI スキームの値です。
   2. リクエスト パラメータをメモする scope と client_id をメモします。 Google ログイン SDK を構成する必要があります。
      注: サードパーティ ライブラリを使用している場合は、ライブラリの 構成ファイルを開いてこれらの情報を探します。
   3. 詳しくは、 Android アプリへの Google ログインの統合を開始する SDK の設定手順が表示されます。スキップして 再利用する手順と同じように、バックエンド サーバーの OAuth 2.0 クライアント ID を取得する手順を使用します。 前の手順で取得した client_id。
   4. 詳しくは、 サーバーサイドの API アクセスを有効にする できます。これには次の手順が含まれます。
      1. getServerAuthCode メソッドを使用して、認証コードを取得します。 スコープを指定します。
      2. 認証コードをアプリのバックエンドに送信して、アクセスと引き換えに更新 あります。
      3. 取得したアクセス トークンを使用して、ユーザーの代わりに Google API を呼び出します。
      注: アプリケーションでオフライン アクセスが不要な場合は、 こちらの手順に沿って、クライアントサイドの API アクセスをリクエストしてください。
2. Google API Console でカスタム スキームのサポートを無効にします。
   1. 次に移動してください: OAuth 2.0 認証情報 Android クライアントを選択します。
   2. [詳細設定] セクションに移動し、 [Enable Custom URI Scheme] チェックボックスをオンにして、[Save] をクリックして カスタム URI スキームのサポートを無効にします。

カスタム URI スキームの有効化

推奨される代替方法が使用できない場合は、カスタム URI スキームを 次のとおりです。

1. 次に移動してください: OAuth 2.0 認証情報のリストと Android クライアントを選択します。
2. [Advanced Settings] セクションに移動し、 [Enable Custom URI Scheme] チェックボックスをオンにして、[Save] をクリックして有効にします。 サポートしています。

Chrome アプリでカスタム URI スキームを使用しない方法

こちらの Chrome Identity API この方法では、OAuth 2.0 レスポンスがアプリに直接配信されるため、 指定します。

アプリの所有権を確認する（Android、Chrome）

アプリの所有権を確認することで、アプリのなりすましのリスクを軽減できます。

Android

注: 現在、Android アプリの所有権の確認は Google Play でのみご利用いただけます。 。

確認プロセスを完了するには、Google Play デベロッパー アカウントを使用してください ID があり、アプリが Google Play Console:次の 次の要件を満たしている必要があります。

• Google Play Console に、 使用している Android OAuth クライアントと同じパッケージ名と SHA-1 署名証明書フィンガープリントを 確認を完了する必要があります。
• そのアプリの管理者権限が必要です。 Google Play Console。 詳細 Google Play Console でのアクセス管理について学びました。

Android クライアントの [Verify App Ownership] セクションで、 [所有権を確認] ボタンをクリックして、確認プロセスを完了します。

検証が成功すると、成功したことを確認する通知が表示されます。 確認プロセスに関するものです。それ以外の場合は、エラー プロンプトが表示されます。

本人確認の失敗を解決するには、次の方法をお試しください。

• 検証対象のアプリが Google Play Console で登録済みアプリであることを確認します。
• 管理ページでアプリの管理者権限があることを確認してください Google Play Console。

Chrome

確認プロセスを完了するには、Chrome ウェブストア デベロッパー アカウントを使用します。 適格性確認を成功させるには、次の要件を満たす必要があります。

• 登録されているアイテムが Chrome ウェブストア デベロッパー ダッシュボード （完了しようとしている Chrome 拡張機能 OAuth クライアントと同じアイテム ID を持つこと） 確認します。
• Chrome ウェブストア アイテムのパブリッシャーである必要があります。 詳細 をご覧ください。

Chrome 拡張機能クライアントの [アプリの所有権の確認] セクションで、 [所有権を確認] ボタンをクリックして、確認プロセスを完了します。

注: 許可するかどうかを選択できます

検証が成功すると、成功したことを確認する通知が表示されます。 確認プロセスに関するものです。それ以外の場合は、エラー プロンプトが表示されます。

本人確認の失敗を解決するには、次の方法をお試しください。

• Chrome ウェブストア デベロッパー ダッシュボードで、 確認対象の Chrome 拡張機能 OAuth クライアントと同じアイテム ID が必要です。
• お客様がアプリのパブリッシャーであることを確認します（個々のパブリッシャーである必要があります）。 アプリのグループ パブリッシャーのメンバーが必要です。 詳細 をご覧ください。
• グループ投稿者リストを更新したばかりの場合は、グループ投稿者のメンバーシップが Chrome ウェブストア デベロッパー ダッシュボードで同期されます。 詳細 パブリッシャーのメンバーシップリストの同期について ご覧ください

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

重要: ループバック IP アドレス リダイレクト オプションは、 Android、Chrome アプリ、iOS の OAuth クライアント タイプでは非推奨です。 ループバック IP を確認します。 アドレス移行ガイドをご覧ください。

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

承認応答を受け取ったら、ユーザビリティを最適にするために、アプリが承認の応答期限を ブラウザを閉じてアプリに戻るようユーザーに指示する HTML ページを表示する。

推奨される使用方法	macOS、Linux、Windows のデスクトップ アプリ（ユニバーサル Windows プラットフォームを除く）
フォームの値	アプリケーション タイプを [デスクトップ アプリ] に設定します。

注: 詳しくは、 redirect_uri パラメータの定義: 詳細が表示されます。また、kubectl の localhost はループバック IP に置き換えますが、この構成では次の問題が発生する可能性があります ファイアウォール ルールで制御できます。すべてではありませんが、ほとんどのファイアウォールはループバック通信を許可しています。

手動でのコピーと貼り付け

重要: 手動でコピー&ペーストするオプション（別名: 帯域外（OOB）リダイレクト手法であり、 サポートを終了しました。 OOB 移行ガイドを確認する をご覧ください。

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

スコープを使用すると、アプリケーションは必要なリソースへのアクセスのみをリクエストできるだけでなく、 ユーザーがアプリケーションに付与するアクセス権の量を制御できます。したがって、 リクエストするスコープの数と、問題が発生する可能性と ユーザーの同意を得る

OAuth 2.0 認証の実装を開始する前に、 権限が必要であることを通知します。

注: 段階的な承認は、インストール済みのアプリではサポートされていません。 。

OAuth 2.0 API スコープのドキュメントに、 Google API へのアクセスに使用できるスコープのリスト。

公開アプリケーションで、アプリケーションへのアクセスを許可するスコープを 検証プロセスを完了する必要があります。未確認と表示された場合 アプリを画面に表示した場合は、 削除することもできます。詳細情報: 未確認アプリ にアクセスして、<ph type="x-smartling-placeholder"></ph>の答えを確認してください アプリの確認に関するよくある質問をご覧ください。

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 ハッシュです。 検証できます。 code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
プレーン	コード チャレンジは、上で生成したコード検証ツールと同じ値です。 code_challenge = code_verifier

ステップ 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 のいずれかと完全に一致する必要があります。 これは、クライアント センター（MCC）アカウントで API Console Credentials page。この値が一致する redirect_uri_mismatch エラーが発生します。 次の表に、適切な redirect_uri パラメータ値を示します。 次のメソッドがあります。 redirect_uri 個の値 カスタム URI スキーム com.example.app:redirect_uri_path または com.googleusercontent.apps.123:redirect_uri_path com.example.app はドメイン名の逆引き表記です。 管理できます。カスタム スキームには有効なピリオドを含める必要があります。 com.googleusercontent.apps.123 は、DNS のリバース DNS 表記です。 できます。 redirect_uri_path は、次のようなオプションのパス コンポーネントです。 /oauth2redirect。パスは 1 つの文字列で始まる必要があります。 これは通常の HTTP URL とは異なります。 注 : カスタム URI スキームは、Chrome アプリと Android では、デフォルトで無効になっています。 詳細 をご覧ください。 ループバック IP アドレス http://127.0.0.1:port または http://[::1]:port 関連するループバック IP アドレスをプラットフォームにクエリし、HTTP を開始する ポートに 1 つずつ呼び出します。port を実際の値に置き換えます。 アプリがリッスンするポート番号を指定します。 なお、モバイル デバイスのループバック IP アドレス リダイレクト オプションは、 アプリは <ph type="x-smartling-placeholder"></ph> 非推奨。
response_type	必須 Google OAuth 2.0 エンドポイントが認証コードを返すかどうかを決定します。 インストール済みアプリのパラメータ値を code に設定します。
scope	必須 スペース区切り アプリケーションがアクセスできるリソースを識別するスコープのリスト 委任できます。これらの値は、Google がユーザーに表示する同意画面を できます。 スコープを使用すると、アプリケーションは必要なリソースへのアクセスのみをリクエストできるようになります。 付与するアクセス権のレベルも制御できます 説明します。したがって、リクエストされるスコープの数には逆相関があります。 ユーザーの同意を得る可能性などです。
code_challenge	推奨 サーバーサイドで使用される、エンコードされた code_verifier を指定します 認証コード交換の際の課題です。詳しくは、 コードを作成する チャレンジのセクションをご覧ください。
code_challenge_method	推奨 使用される code_verifier のエンコードに使用されたメソッドを指定します 認証コード交換の際に行われます。このパラメータは、 code_challenge パラメータ（上記を参照）。code_challenge_method の値 plain がリクエストに code_challenge。このパラメータでサポートされている値は、 S256 または plain。
state	推奨 アプリケーション間で状態を維持するために、アプリケーションが使用する文字列値 認可リクエストと認可サーバーのレスポンスで構成されます。 サーバーは、送信したコードを name=value ペアとして URL フラグメント識別子（#） redirect_uri ユーザーがアプリケーションの アクセス リクエストだけです。 このパラメータは、ユーザーを アプリケーション内の適切なリソースの確認、ノンスの送信、クロスサイト リクエストの軽減 できます。redirect_uri は推測できるため、state を使用します。 値を使用すると、受信接続が特定のサーバーに対する 構成されます。ユーザーがランダムな文字列を生成したり、Cookie や Cookie のハッシュをエンコードしたりした場合、 クライアントの状態を取得する別の値が必要な場合は、 さらに、リクエストとレスポンスが同じブラウザから発信されたこと、 次のような攻撃から保護します。 クロスサイト リクエスト 偽造。詳しくは、 OpenID Connect state トークンを作成して確認する方法の例をご覧ください。 重要: OAuth クライアントでは、 OAuth2 仕様 。これを実現する 1 つの方法は、state パラメータを使用して、 認可リクエストと認可サーバーのレスポンスの間で、状態がどのように異なるのかを明らかにします。
login_hint	省略可 認証しようとしているユーザーをアプリケーションで認識している場合は、このパラメータを使用できます。 Google 認証サーバーにヒントを提供します。サーバーはヒントを使用して、 ログイン フォームのメール フィールドにあらかじめ入力するか、 適切なマルチログインセッションを選択します パラメータ値には、メールアドレスまたは sub 識別子を設定します。 ユーザーの Google ID に相当します。

注: インストール済みのアプリに対する段階的認証は、 クライアントが client_secret を機密扱いできないという事実を指摘します。

サンプル認証 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 アカウントはリクエストされた 1 つ以上のスコープを承認できません Google Workspace 管理者が 手動で行う必要はありませんGoogle Workspace 管理者用ヘルプ記事をご覧ください どの第三者と内部アプリが Google Workspace データにアクセスする 管理者がすべてのスコープまたは機密 / 機密情報へのアクセスを制限する方法について詳しくは、 OAuth クライアント ID にアクセスが明示的に付与されるまで、制限付きのスコープを設定できます。

disallowed_useragent

認可エンドポイントが、Google の許可されていない埋め込みユーザー エージェント内に表示される OAuth 2.0 ポリシー

Android

Android デベロッパーが認証リクエストを開くと、このエラー メッセージが表示されることがあります。 android.webkit.WebView。 代わりに、次のような Android ライブラリを使用する必要があります。 Android 向け Google ログインまたは OpenID Foundation Android 用の AppAuth。

このエラーは、Android アプリが ユーザーが Google の OAuth 2.0 認可エンドポイントに移動すると、 できます。デベロッパーは、一般的なリンクを オペレーティング システムには、 Android アプリリンク デフォルトのブラウザアプリを使用できます。「 Android カスタムタブ ライブラリもサポートされています。

iOS

iOS および macOS のデベロッパーにおいて、承認リクエストを Google 管理コンソールで開くと、このエラーが発生する場合があります WKWebView。 代わりに、次のような iOS ライブラリを使用する必要があります。 iOS 向け Google ログインまたは OpenID Foundation iOS 用の AppAuth。

このエラーは、iOS アプリまたは macOS アプリで一般的なウェブリンクが ユーザーが埋め込みユーザー エージェントを作成し、ユーザーが Google の OAuth 2.0 認可エンドポイントに できます。デベロッパーは、一般的なリンクを オペレーティング システムには、 ユニバーサル リンク デフォルトのブラウザアプリを使用できます。「 SFSafariViewController ライブラリもサポートされています。

org_internal

リクエストの OAuth クライアント ID は、プロジェクト内の Google アカウントへのアクセスを制限する Google Cloud 組織。 この設定オプションの詳細については、 ユーザーの種類 （OAuth 同意画面の設定に関するヘルプ記事）をご覧ください。

invalid_grant

複数の コード検証ツールと チャレンジでは、code_callenge パラメータが無効であるか、存在しません。必ず、 code_challenge パラメータが正しく設定されている。

アクセス トークンを更新するとき、トークンの有効期限が切れているか、 無効になりました ユーザーを再度認証し、新しいトークンを取得するためのユーザーの同意を求めます。続行する場合 このエラーを表示するには、アプリケーションが正しく構成されていて、 正しいトークンとパラメータを使用して検証する必要があります。それ以外の場合、ユーザー アカウントに 削除されたか無効になっています

redirect_uri_mismatch

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

渡された redirect_uri が、クライアント タイプに対して無効である可能性があります。

redirect_uri パラメータは、以下を含む OAuth 帯域外（OOB）フローを指すことがあります。 非推奨となり、サポートされなくなりました。詳しくは、 移行ガイドを参照し、 統合されています

invalid_request

リクエストになんらかの問題がありました。これには、いくつかの理由が考えられます。

• リクエストの形式が正しくありません
• リクエストに必須パラメータが含まれていませんでした
• リクエストで、Google でサポートされていない認証方法が使用されています。OAuth を確認する 推奨される統合方法が使用されています
• リダイレクト URI にカスタム スキームが使用されている : エラー メッセージ「 カスタム URI スキームは Chrome アプリでサポートされていません または カスタム URI スキーム が Android クライアントで有効になっていない場合は、カスタム URI を使用していることを意味します。 このスキームは Chrome アプリでサポートされていないため、 Android。カスタム URI スキームの詳細 代替手段

ステップ 4: OAuth 2.0 サーバー レスポンスを処理する

アプリケーションが承認レスポンスを受信する方法は、 リダイレクト URI スキームを指定します。どのようなスキームであっても、 レスポンスには、認証コード（code）またはエラーが含まれます。 (error).たとえば、error=access_denied はユーザーが リクエストを拒否しました。

ユーザーがアプリケーションへのアクセスを許可したら、認証コードを 更新トークンが必要です。

ステップ 5: 認証コードを交換して更新とアクセスを行う トークン

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

フィールド
client_id	API Consoleから取得したクライアント ID Credentials page。
client_secret	API Consoleから取得したクライアント シークレット。 Credentials page。
code	最初のリクエストから返された認証コード。
code_verifier	先ほど作成したコード検証ツールは ステップ 1.
grant_type	OAuth 2.0 の の場合、このフィールドの値を authorization_code に設定する必要があります。
redirect_uri	プロジェクトのリダイレクト URI の 1 つを API Console 指定された の Credentials 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=http://127.0.0.1:9004&
grant_type=authorization_code

Google はこのリクエストに対して、有効期間の短いアクセス権を含む JSON オブジェクトを返します。 更新トークンの 2 つです

レスポンスには、次のフィールドが含まれます。

フィールド
access_token	Google API リクエストを承認するためにアプリケーションが送信するトークン。
expires_in	アクセス トークンの残りの存続期間（秒）。
id_token	注: このプロパティは、リクエストに ID スコープが含まれていた場合にのみ返されます。 （openid、profile、email など）。値は JSON Web Token（JWT）。デジタル署名された ID 情報が できます。
refresh_token	新しいアクセス トークンの取得に使用できるトークン。更新トークンは、更新トークンが ユーザーがアクセス権を取り消します。 インストールされているアプリケーションに対しては、更新トークンが常に返されることに注意してください。
scope	access_token によって付与されるアクセスのスコープ。次のリストで表されます。 スペースで区切られ、大文字と小文字が区別されます。
token_type	返されるトークンのタイプ。現時点では、このフィールドの値は常に Bearer。

重要: アプリケーションでは、両方のトークンを安全な形式で保存する必要があります。 アプリケーションの異なる呼び出し間でアクセスできる、永続的に保存される場所。「 更新トークンを使用すると、持っているアクセス トークンが 期限が切れます。そのため、アプリケーションが更新トークンを失った場合、ユーザーは アプリケーションが新しい更新トークンを取得できるようにするための OAuth 2.0 同意フロー。

次のスニペットは、レスポンスの例を示しています。

{
  "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 の呼び出し

アプリケーションがアクセス トークンを取得したら、そのトークンを使用して Google Cloud API を呼び出すことができます。 API の代理操作です。 ユーザー アカウント（API に必要なアクセス スコープが付与されている場合）そのためには API へのリクエストのアクセス トークン（access_token クエリまたは パラメータまたは Authorization HTTP ヘッダー Bearer 値を指定します。可能であれば クエリ文字列はサーバーログに表示される傾向があるため、HTTP ヘッダーの使用をおすすめします。ほとんどの クライアント ライブラリを使用して Google API の呼び出しを設定できます（例: Drive Files API の呼び出しを参照）。

すべての Google API を試して、 OAuth 2.0 Playground。

HTTP GET の例

呼び出しは、 drive.files エンドポイント（Drive Files API）Authorization: Bearer HTTP を使用 次のようになります。独自のアクセス トークンを指定する必要があります。

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 回 全クライアントでユーザーごとに 1 つずつ 追加する必要があります更新トークンを保存する必要がある 保持され、有効な間は継続して使用できます。アプリケーションで リクエストが多すぎると、これらの上限に達する可能性があります。その場合、古い更新トークン 動作しなくなります。

トークンの取り消し

アプリケーションに付与したアクセス権の取り消しをユーザーが希望する場合があります。ユーザーはアクセス権を取り消すことができます <ph type="x-smartling-placeholder"></ph>にアクセス アカウント設定。詳しくは、 削除 第三者のサイトやアプリの [サイトまたはアプリのアクセス] セクションでアカウントにアクセスできるアプリ サポート ドキュメントをご覧ください。

また、アプリケーションに付与されているアクセス権をプログラムで取り消すこともできます。 プログラムによる取り消しは、ユーザーが登録解除を行ったり、 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 ネイティブ アプリは、ここに記載されているベスト プラクティスの多くを確立しています。