主にアプリを介してアクセスされるWebサイトを開発していますが、ユーザーの登録と認証にOAuth2を使用したいと思います。これはAndroidアプリであるため、Androidで適切なUIを提供するため、GoogleのOAuth2の使用を開始します。
Googleは、 「アプリケーションのユーザー認証を外部委託する方法として、Googleの認証システムを使用することを選択できます。これにより、ユーザー名とパスワードストアを作成、維持、保護する必要がなくなります。」 which私がやりたいことです。 ただし、彼らのすべての例を見てみると、ウェブサイトまたはアプリは、Googleのサービスに対してユーザーを認証します。
実際、GoogleのOAuth2にアプリ(「クライアント」)を登録する場合、ウェブサイトクライアントと「インストール済み」クライアント(モバイルアプリ)のオプションがありますが、両方はありません。 2つの別個のクライアントを作成できますが、OAuth2ドラフトを読んで、問題があると思うので、これについて説明します。
私はそれがどのように機能するかを想像しました:
AccountManager
クラスを使用して、GoogleのAPIのアクセストークンを要求します。AccountManager
は、電話に保存されている資格情報を使用してGoogleのOAuth2サーバーに接続し、アクセストークンを要求します。AccountManager
は、MyAppにアクセストークンを返します。それで、どうすればいいですか?また、「OpenIDを使用」や「OAuth2を使用しない」などの役に立たない答えを言わないでください。ああ、私は本当にくだらないポップアップAccountManager
sではなく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)が見つからない場合、新しいユーザーを作成できます。次に、アクセストークンのハッシュ値をキャッシュします。
認証にOAuthトークンを使用するOpenID Connectがおそらく必要です。 AccountManager
に関しては、現在のOAuthのサポートは少しハッキーです。新しい Google Play Services がリリースされる予定であり、すぐにこれが改善されるはずです。 デモ についてはこちらをご覧ください。
同様の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> ...
モバイルアプリケーションによって取得されたアクセストークンは、他のどこでも使用できます。 Drive SDKには、 https://developers.google.com/drive/quickstart-Android
それはあなたが望むものを正確に記述します: https://developers.google.com/identity/protocols/CrossClientAuth
少なくともGoogleでは、アクセストークンは最終的に期限切れになります。これがAndroid AccountManager
にinvalidateAuthToken
メソッドが含まれている理由です。キャッシュされたアクセストークンの有効期限が切れているため、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
を使用できると考えています。
Google以外のOAuthサーバーで同様のことを行う必要がある場合、WebサイトのDBにトークンを保持しました。必要に応じて、アプリはWebサービスを使用してトークンを要求しますデータを要求します。
ユーザーは、WebまたはアプリのいずれかでOAuth登録を行うことができます。同じアプリケーショントークンを共有するため、同じアクセストークンを共有できます。登録後、アクセストークンと更新トークンを保存します必要なアプリから使用するためのDB内。