コマンドラインツールがGoogleAPIを使用することを承認する（OAuth2.0などを介して）
私はthinkモバイルアプリまたはWebサイトのコンテキストでOAuth 2.0がどのように機能するかを理解しています-どちらも私の場合ではありません。
Googleサービス（ Google Fusion Tables ）の1つへのアクセスを許可したいC++コマンドラインアプリケーションがありますがこの質問は、Googleサービス、または一体、おそらくOAuth2を処理する必要のあるコマンドラインアプリのいずれにも当てはまると思います。
私はユーザー名を持っています。パスワードを持っています（ユーザーが入力しました）。 Curlを介して電話をかけることができるように、トークンを取得する必要があります。これを達成する最も簡単な方法は何ですか？
更新1：
ドキュメントを読んだ後、最も苦痛の少ないOAuth2フローは "インストールされたアプリケーション" 1つになるようです。
私が考えているのは、コマンドラインツールがトークンを必要とせずにパブリックテーブルを要求することです（ただし、Google APIダッシュボードから取得できるAppIDをGoogleから送信する必要があるようです）。
コマンドラインツールでプライベートリソースを使用する必要がある場合は常に、そのユーザーはGoogleが提供する認証コードを提供する必要があります（コマンドラインツールを使用して使用可能にすることができますトークン）。ユーザーがコマンドラインで認証コードを指定しなかった場合、私のツールは、ユーザーがURLに貼り付けて認証コードを生成できるリンクを出力するだけです。リンクは次のようになります。
ユーザーが同意すると、その認証コードを端末に貼り付けて、コマンドラインツールで使用できるようにする必要があります。コマンドラインツールは、認証コードを使用してGoogleにトークンを要求し、最後に、Googleトークンを使用してAPI呼び出しを行うことができます。
いくつかのことがまだ私にはわかりません。認証コードは変更されますか？もしそうなら、トークンが期限切れになるたびに更新トークンを再利用できるように、トークンを保存してトークンをどこかに更新する必要があるようです。
それは私だけですか、それともコマンドラインからGoogle APIを使用できるようにするためだけに、このすべてがおかしな話のように見えますか？
私は通常 ClientLoginフロー を使用しますが、すべてがすぐに非推奨になることを指摘しているようです。
「インストールされたアプリケーション」フローに関する質問に答えるには：
認証コードは1回だけ有効です。それを交換した後-そしてリフレッシュトークンとアクセストークンを取得しました）-それはもう使用できなくなります。ただそれを捨てなさい。これは1回限りの使用であり、もう必要ありません。あなたがする必要があるのは、再利用のためにいくつかのローカルファイルに更新トークンを単に保持/保存/永続化することです。
リフレッシュトークンは重要なトークンです。プログラムで新しいアクセストークン（1時間有効）を取得するために使用できるため、APIに無制限にアクセスできます。その操作について refresh token doc を確認してください。
Google APIクライアントライブラリは通常、トークンの更新を自動的かつ透過的に処理しますが、C++クライアントライブラリがないため、これを自分で行う必要があります。私たちが使用する1つの手法は、APIへのリクエストを行うときに403エラーをキャッチすることです（これは無効なアクセストークンを示します）。その場合、更新を行います新しいアクセストークンを取得してから、最初に失敗した操作を自動的に再試行します。
私のアドバイス：
最高のユーザーエクスペリエンスを提供するフローは、サーバー側のWebアプリケーションフローを使用することです。それはより多くの作業ですが、インストールされたアプリケーションやコマンドラインアプリケーションで使用することは可能です。方法は次のとおりです。
- 空きポートをリッスンしているユーザーのマシンでローカルWebサーバーを起動します（例：
http://127.0.0.1:7777） - ユーザーをGoogle OAuth 2.0付与ページにリダイレクトする）Webブラウザーウィンドウを生成（またはアプリに埋め込む）し、リダイレクトURIを
http://127.0.0.1:7777に設定します - ユーザーがアプリケーションへのアクセスを許可すると、
http://127.0.0.1:7777でリッスンしているサーバーにリダイレクトされます。 - ローカルWebサーバーでは、URLクエリパラメーターに含まれる認証コードを取得します。これで、認証コードを、保持しているアクセストークンと更新トークンと交換できます
- 手順1で開始したローカルWebサーバーを強制終了/閉じます
- 手順2で生成したブラウザインスタンスを強制終了/閉じます
これで、更新トークンとアクセストークン（手順4から）が取得され、ブラウザーを強制終了した後、アプリに戻ります。
なぜこのすべての混乱？
クライアントログインは非推奨になりました。それはなくなり、新しいAPIでは機能しません。 Googleは、ユーザーがパスワードを保存したくなり、ハッキングされる可能性があるため、ユーザーにパスワードを教えてほしくないです:)）また、Google Checkoutアカウントで商品を購入したり、アカウントを盗むためにパスワードを変更します。現在、セキュリティの観点から進む唯一の方法は、OAuth2のようなこれらの3本足の認証システムを使用し、パスワードの使用を推奨しないことです。これにより、ユーザーはユーザー名とパスワードをサードパーティに提供する習慣から抜け出すことができます。もちろん、OAuth2をデスクトップ/コマンドラインアプリケーションに使用するのは非常に困難です...
OOBの代替
コードをリッスンするWebサーバーを起動したくない、または起動できない場合は、oob OAuthフローを使用できます。oobリダイレクトURIとして。この場合、特定のURLにリダイレクトされる代わりに、「これが認証コードです。コピーしてアプリに貼り付けてください。」というページがユーザーに表示されます。アプリでは、次のことができます。ユーザーに認証コードをテキストフィールドに貼り付けてもらうだけです。これはユーザーエクスペリエンスが低下しますが、場合によってはより堅牢になり、より多くの環境、特にローテク環境で機能する可能性があります。
すべてのOAuth 2つのプロバイダーがサポートしているわけではありませんが、少なくともGoogleとFacebookはサポートしていることに注意してください。