5

ユーザーがsimpleauthを使用して認証できるようにする webapp に取り組んでいます。今のところ、私は Google と Facebook をサポートします。ログインとログアウト (webapp2 を使用) 以外に、webapp は Cloud Endpoint API で構成されます。クライアントは、Web、Android、および iOS になります。

私の質問は、Endpoints Proto Datastore を使用して、ユーザーの認証プロバイダーが Facebook (または他のサポートされている OAuth2 プロバイダーのいずれか) である場合に、ユーザーを取得するためにuser_required=True呼び出すことができますか?代わりに、OAuth2 トークンを指定してプロバイダーから永続的なユーザー ID を取得し、それをデータストアに保持し、そのユーザー用に独自の認証トークンを生成し、そのトークンを各要求に渡す必要がありますか?endpoints.get_current_user()@Model.methoduser_required=True

編集:認証トークンを渡す代わりに、認証されたユーザーが API メソッドに渡すことができる「API トークン」を要求することは理にかなっていますか? このトークンは POST または GET 本文に含める必要がありますか、それともヘッダー/Cookie に入れることができますか (Cloud Endpoints のヘッダーと Cookie に関する SO の他の場所でいくつかの質問を見ましたが、それからしばらく経ちました)。これはすべて、Google 以外の認証が機能しないことを前提としています。

4

1 に答える 1

2

この回答はあなたの質問に直接答えるものではありませんが、安全な方法で認証を実装する方法についての良いアイデアを提供するはずです. 私は最近似たようなものを実装し、Google AppEngine 環境で認証を行う最良の方法を見つけるのにかなりの時間を費やしました。

Google は OpenId Connect プロトコルをサポートしています。Getting Started with OAuth 2.0 bookによると、Facebook の実装は非常に似ているはずです。私は Google の実装に精通しているので、Google の実装に焦点を当てますが、他の OAuth プロバイダーを使用する場合の概念は非常に似ているはずです。

id_tokenユーザーの認証に成功すると、OpenId Connect は , を返します。それはまたあなたに与えるでしょうaccess token。アクセストークンは秘密にしておくべきもの. 決して有線で送信しないでください。一方、ID トークンは非常に便利です。ユーザーに関する情報が含まれており、暗号化されているため、ユーザーに関する情報が「そのまま」公開されることはありません。ユーザーについて何かを知るには、id_token をクラックする必要があります。万が一クラックされたとしても、ユーザーにとって重要なことは何も公開されません。できることは、それを Cookie として保存し、それを後続のすべてのリクエストで使用して、id_token と一致するアクセス トークンがあるかどうかを確認することで、ユーザーを確認することです。唯一の欠点は、id_token が非常に長いことです。約 650 バイトかかります。これは、すべての http リクエストがそのペイロードを運ぶことを意味します。それだけの量の情報を送信するのがユース ケースに多すぎる場合は、最初の数文字だけを送信できます。おそらく12個程度で、最初の部分だけに一致します。id_token は、データを分析するときにも役立ちます。http リクエストを分析するときに表示されますが、ユーザーに関する情報は明らかにされず、異なるユーザーからのリクエストを区別することもできます。

また、補足として、AppEngine のユーザー サービスは、どのような種類のカスタム認証でもうまく機能しないため、使用しないでください。

これがあなたにアイデアを与え、正しい軌道に乗せることを願っています.

于 2014-01-06T00:49:12.910 に答える