27

OAuth 2.0 がモバイル アプリまたは Web サイトのコンテキストでどのように機能するかを理解していると思いますが、私の場合もそうではありません。

Google サービスの 1 つ ( Google Fusion Tables )へのアクセスを許可したいC++コマンド ラインアプリケーションがありますが、この質問は Google サービスのいずれにも当てはまると思います。 OAuth2 で。

私はユーザー名を持っています。パスワードを知っています (ユーザーが入力しました)。Curl を介して呼び出しを行うには、トークンを取得する必要があります。これを達成する最も簡単な方法は何ですか？

更新 1:

ドキュメントを読んだ後、最も苦痛の少ない OAuth2 フローは「インストールされたアプリケーション」になるようです。

私が考えているのは、私のコマンド ライン ツールはトークンを必要とせずにパブリック テーブルのリクエストを行うということです (ただし、Google API ダッシュボードから取得できる Google から AppID を送信する必要があるようです)。

コマンド ライン ツールでプライベート リソースを使用する必要がある場合は常に、そのユーザーは Google 提供の認証コードを提供する必要があります(コマンド ライン ツールは使用可能なトークンを取得するために使用できます)。ユーザーがコマンド ラインで認証コードを指定していない場合、私のツールは、ユーザーが URL に貼り付けて認証コードを生成できるリンクを出力するだけです。リンクは次のようになります。

https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/fusiontables&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&client_id=812741506391-h38jh0j4fv0ce1krdkiq0hfvt6n5amrf. apps.googleusercontent.com

ユーザーが同意したら、その認証コードを端末に貼り付けて、コマンド ライン ツールで使用できるようにする必要があります。コマンド ライン ツールは認証コードを使用して Google にトークンを要求し、最後に Google トークンを使用して API 呼び出しを行うことができます。

いくつかのことはまだ私には不明です。認証コードは変更されますか? もしそうなら、トークンの有効期限が切れるたびに更新トークンを再利用できるように、トークンと更新トークンをどこかに保存する必要があるようです。

それは私だけですか、それとも、コマンド ラインから Google API を使用できるようにするためだけに、このすべてがクレイジーな話のように思えますか?

私は通常ClientLogin フローを使用しますが、すべてがすぐに非推奨になることを指摘しているようです。

4

1 に答える 1

43

「インストール済みアプリケーション」フローに関する質問に答えるには:

認証コードは一度だけ有効です。交換後、リフレッシュ トークンとアクセス トークンを取得すると、使用できなくなります。捨てるだけ。1回限りの使用で、もう必要ありません。あなたがする必要があるのは、再利用のためにローカルファイルにリフレッシュトークンを保持/保存/永続化することだけです。

リフレッシュ トークンは重要なトークンです。API を使用して新しいアクセス トークン(有効な 1 時間)をプログラムで取得できるため、無期限に API にアクセスできます。その操作については、更新トークンのドキュメントを確認してください。

Google API クライアント ライブラリは通常、トークンの更新を自動的かつ透過的に処理しますが、C++ クライアント ライブラリがないため、自分で行う必要があります。私たちが使用するテクニックの 1 つは、API へのリクエストを行うときに 403 エラーをキャッチすることです (無効なアクセス トークンを示します)。その場合、更新を行って新しいアクセス トークンを取得し、最初に失敗した操作を自動的に再試行します。

私のアドバイス:

最高のユーザー エクスペリエンスを提供するフローは、サーバー側の Web アプリケーション フローを使用することです。より多くの作業が必要ですが、インストール済みおよび/またはコマンド ライン アプリケーションで使用することが可能です。方法は次のとおりです。

  1. 空きポートをリッスンしているユーザーのマシンでローカル Web サーバーを開始します (例: http://127.0.0.1:7777)
  2. ユーザーを Google OAuth 2.0 許可ページにリダイレクトする Web ブラウザー ウィンドウを生成 (またはアプリに埋め込む) し、リダイレクト URI を次のように設定します。http://127.0.0.1:7777
  3. ユーザーがアプリケーション アクセスを許可すると、 でリッスンしているサーバーにリダイレクトされますhttp://127.0.0.1:7777。
  4. ローカル Web サーバーで、URL クエリ パラメーターにある認証コードを取得します。保持するアクセストークンとリフレッシュトークンの認証コードを交換できるようになりました
  5. 手順 1 で開始したローカル Web サーバーを強制終了/終了します。
  6. 手順 2 で生成したブラウザー インスタンスを強制終了または閉じます。

以上で、リフレッシュ トークンとアクセス トークン (手順 4 から) が取得され、ブラウザーを強制終了した後、アプリに戻ります。

なぜこのすべての混乱？

クライアント ログインは廃止されました。これは廃止され、新しい API では機能しません。Google は、ユーザーがパスワードを教えてくれることを望んでいません。パスワードを保存したくなるかもしれませんし、ハッキングされる可能性もあります :)) また、Google チェックアウト アカウントで商品を購入したり、パスワードを変更してアカウントを盗む。現在、セキュリティの観点から行く唯一の方法は、OAuth2 のようなこれらの 3 つの認証システムを使用し、パスワードの使用を思いとどまらせることです。これにより、ユーザーはユーザー名とパスワードをサード パーティに提供する習慣から抜け出すことができます。もちろん、OAuth2 はデスクトップ/コマンドライン アプリケーションで使用するのがはるかに困難です...

OOB の代替手段

コードをリッスンする Web サーバーを起動したくない、または起動できない場合は、oobOAuth フローを使用できます。oobリダイレクト URI として指定するだけで機能します。この場合、特定の URL にリダイレクトされる代わりに、「認証コードはこちらです。コピーしてアプリに貼り付けてください」というページがユーザーに表示されます。アプリでは、ユーザーに認証コードをテキスト フィールドに貼り付けるだけで、出来上がりです。これはユーザー エクスペリエンスが低下しますが、場合によってはより堅牢になり、より多くの環境、特にローテク環境で機能する可能性があります。

すべての OAuth 2 プロバイダーがサポートしているわけではありませんが、少なくとも Google と Facebook はサポートしているので注意してください。

于 2012-11-14T15:30:07.307 に答える