web-dev-qa-db-ja.com

アプリ*および*ウェブサイトのOAuth2による認証

主にアプリを介してアクセスされるWebサイトを開発していますが、ユーザーの登録と認証にOAuth2を使用したいと思います。これはAndroidアプリであるため、Androidで適切なUIを提供するため、GoogleのOAuth2の使用を開始します。

Googleは、 「アプリケーションのユーザー認証を外部委託する方法として、Googleの認証システムを使用することを選択できます。これにより、ユーザー名とパスワードストアを作成、維持、保護する必要がなくなります。」 which私がやりたいことです。 ただし、彼らのすべての例を見てみると、ウェブサイトまたはアプリは、Googleのサービスに対してユーザーを認証します。

実際、GoogleのOAuth2にアプリ(「クライアント」)を登録する場合、ウェブサイトクライアントと「インストール済み」クライアント(モバイルアプリ)のオプションがありますが、両方はありません。 2つの別個のクライアントを作成できますが、OAuth2ドラフトを読んで、問題があると思うので、これについて説明します。

私はそれがどのように機能するかを想像しました:

OAuth2 flow diagram

  1. ユーザーがMyAppに個人データへのアクセスを要求します。
  2. アプリはAndroidのAccountManagerクラスを使用して、GoogleのAPIのアクセストークンを要求します。
  3. Androidはユーザーに「アプリ「MyApp」はGoogleの基本情報へのアクセスを望んでいます。これでいいですか?」
  4. ユーザーは「はい」と言います。
  5. AccountManagerは、電話に保存されている資格情報を使用してGoogleのOAuth2サーバーに接続し、アクセストークンを要求します。
  6. アクセストークン(緑色の線に続く)が返されます。
  7. AccountManagerは、MyAppにアクセストークンを返します。
  8. MyAppは、アクセストークンを含むユーザーのプライベートデータのリクエストをMySiteに送信します。
  9. MySiteは、アクセストークンを使用してユーザーを確認する必要があります。トークンを検証します ここで説明 、Googleで-「Google、このトークンは有効ですか?」.
  10. さて、私が望んでいるのはGoogleが「はい、あなたに与えたのは誰でもそのユーザーです」と言うことですが、実際には(OAuth2ドラフトとGoogleのドキュメントに基づいて)発生することは、「まさか!そのトークンはMyAppにのみ有効で、あなたはMySiteです。GTFO!」と言うことです。

それで、どうすればいいですか?また、「OpenIDを使用」や「OAuth2を使用しない」などの役に立たない答えを言わないでください。ああ、私は本当にくだらないポップアップAccountManagersではなくNice WebView UIを使い続けたい

編集

Nikolayからの暫定的な回答(機能する場合は報告します!)は、実際に機能するはずであり、Googleのサーバーはアクセストークンの出所を気にしません。私には少し不安に思えますが、うまくいくかどうかを確認します!

更新

GoogleではなくFacebookでこのパターンを実装しましたが、完全に機能します。 OAuth2サーバーは、アクセストークンの出所を気にしません。少なくともFacebookはそうではないので、Googleもそうではないと思います。

それに照らして、アクセストークンを保存することは非常に非常に悪い考えです!しかし、Facebook/Googleのサーバーにアクセスしてeveryリクエストの認証を確認する必要もありません。おそらく最良の方法は、アクセストークンが検証されたときに配布する追加の認証Cookieをサイトに追加することですが、より簡単な方法は、アクセストークンをパスワードのように扱い、そのハッシュを保存することです。アクセストークンは本当に長いので、どちらもソルトする必要はありません。したがって、上記の手順は次のようになります。

9. MySiteは、アクセストークンを使用してユーザーを確認する必要があります。最初に、ハッシュされた有効なアクセストークンのキャッシュをチェックします。トークンのハッシュが見つかると、ユーザーが認証されたことがわかります。それ以外の場合は、Googleでチェックします ここで説明 、Googleで-「Google、このトークンは有効ですか?」.

10.アクセストークンが無効であるとGoogleが言った場合、ユーザーにGTFOを伝えます。そうでない場合、Googleは「はい、それは有効なユーザーです」と言ってから、登録済みのユーザーデータベースを確認します。そのGoogleユーザー名(またはFacebookを使用している場合はFacebook ID)が見つからない場合、新しいユーザーを作成できます。次に、アクセストークンのハッシュ値をキャッシュします。

63
Timmmm

認証にOAuthトークンを使用するOpenID Connectがおそらく必要です。 AccountManagerに関しては、現在のOAuthのサポートは少しハッキーです。新しい Google Play Services がリリースされる予定であり、すぐにこれが改善されるはずです。 デモ についてはこちらをご覧ください。

1
Nikolay Elenkov

同様のStackOverflowの質問に 回答 を投稿しました。

Googleはこれを Hybrid Apps と呼び、 「AndroidアプリがWebバックエンドのオフラインアクセスを取得する」 の方法を説明します。

その要点は、OAuth2トークンではなく認証コードを返すようにするには、scope文字列をGoogleAuthUtil.getTokenに渡す必要があるということです。その承認コードは、モバイルアプリからサーバーに渡され、OAuth2トークンとリフレッシュトークンに交換できます。これは この図 に従ってください。

scopeパラメーターは次のようになります。

oauth2:server:client_id:<your_server_client_it>:api_scope:<scope_url_1> <scope_url_2> ...
5
Wolfram Arnold

モバイルアプリケーションによって取得されたアクセストークンは、他のどこでも使用できます。 Drive SDKには、 https://developers.google.com/drive/quickstart-Android

2
Burcu Dogan

それはあなたが望むものを正確に記述します: https://developers.google.com/identity/protocols/CrossClientAuth

少なくともGoogleでは、アクセストークンは最終的に期限切れになります。これがAndroid AccountManagerinvalidateAuthTokenメソッドが含まれている理由です。キャッシュされたアクセストークンの有効期限が切れているため、AccountManagerに通知を停止する必要があります古いものを代わりに新しいものを取得します。これにより、トークン自体はそのユーザーとしての永遠のアクセスをあなたに与えないので、トークンをキャッシュするのがいくらか安全になります。代わりに、有効である場合、「最近のある時点で、このトークンは信頼できるソースによって取得された」とのみ表示されます。

トークンを操作するときに役立つことがわかったいくつかのことを次に示します。 1つ目は、Googleのtokeninfoエンドポイントです。トークン自体は、base64でエンコードされたJSONです。これは暗号化されていないことを意味するため、通信には必ずHTTPSを使用する必要があります。ただし、トークンを調べて、何が起こっているかをよりよく把握できることも意味します。

https://www.googleapis.com/oauth2/v1/tokeninfo?id_token=

トークンが「abcdef」の場合、次の場所に移動します。

https://www.googleapis.com/oauth2/v1/tokeninfo?id_token=abcdef

googleがトークンを展開します。これは、トークンがまだ有効である秒数を示す「expires_in」フィールドを含む単純なJSONオブジェクトです。以下のビデオの6:03に、展開されたトークンを見ることができます。

https://developers.google.com/events/io/sessions/383266187

このビデオにはOAuth2の概要が含まれており、OAuthとトークンを扱う場合は、全体を見る価値があります。また、スピーカーは、アクセストークンではなく、期限切れにならない他の形式のOauth2トークンについても説明します。

別の有用なリソースは、OAuth Playgroundです。これにより、リクエストスコープ、リクエストの作成、トークンの取得などの基本的なことを実行できます。このリンクは散発的に機能するようで、ChromeにOauth Playgroundアプリをインストールする必要がありました。

https://developers.google.com/oauthplayground/

また、ビデオのスピーカーであるTim Brayによるチュートリアルでは、アクセストークンを使用してAndroidアプリからサーバーと通信する方法を説明しています。 Google APIコンソールのさまざまな機能がどのように連携するかを理解し始めたため、これは私にとって有用でした。

http://Android-developers.blogspot.in/2013/01/verifying-back-end-calls-from-Android.html

あなたの質問に対する実際の答えに関しては、サーバー上にアクセストークンをキャッシュする必要は決してないと言います。上記のAndroidリンクからのバックエンド呼び出しの検証で説明したように、トークンの検証はほとんどの場合、高速で静的な呼び出しです。つまり、トークンをキャッシュする理由はありません。

ライブラリはGoogle証明書をキャッシュし、必要な場合にのみ更新できるため、検証は(ほとんどの場合)高速な静的呼び出しです。

最後に、AccountManagerを使用してアクセストークンを取得できます。ただし、Googleは代わりにPlayサービスライブラリでGoogleAuthUtilクラスの使用を代わりに推奨しています。

一言で言えば、OAuth2リクエストgetAuthTokenおよびgetTokenを使用することとの違いは何ですか

ここで、上記のリンクのティムブレイと同じ男が、GoogleAuthUtilルートに努力を注いでいると言っていることに注目してください。ただし、これは、Google認証に制限されることを意味することに注意してください。 AccountManagerの場合ではなく、たとえばFacebookトークンを取得するためにGoogleAuthUtilを使用できると考えています。

1
user1978019

Google以外のOAuthサーバーで同様のことを行う必要がある場合、WebサイトのDBにトークンを保持しました。必要に応じて、アプリはWebサービスを使用してトークンを要求しますデータを要求します。

ユーザーは、WebまたはアプリのいずれかでOAuth登録を行うことができます。同じアプリケーショントークンを共有するため、同じアクセストークンを共有できます。登録後、アクセストークンと更新トークンを保存します必要なアプリから使用するためのDB内。

0
Mark S.