23

私はこのトピックについてたくさん読んでいますが、私が見つけたのは時代遅れまたは部分的な答えだけであり、それは私をそれほど助けず、実際には私をもっと混乱させます。Webアプリ（APIと同じドメインでホストされている）とAndroidアプリからアクセスできるRest API（Node + Express + MongoDB）を作成しています。

アプリケーションと許可されたユーザーだけがAPIにアクセスできるようにしたい。また、ユーザーが自分のFacebookアカウントのみを使用してサインアップおよびログインできるようにし、名前、プロフィール写真、電子メールなどの基本情報にアクセスできるようにする必要があります。

私が考えている考えられるシナリオは次のとおりです。

  1. ユーザーがFacebookを使用してWebアプリにログインすると、アプリはユーザーのFacebook情報にアクセスするためのアクセス許可を付与され、アクセストークンを受け取ります。
  2. WebアプリはAPIに、このユーザーが実際にシステムに登録されていることを確認するように要求し、Facebookが受信した電子メールとトークンを送信します。
  3. APIは、ユーザーが存在することを確認し、ユーザー名、トークン、タイムスタンプをDB（またはRedis）に保存してから、クライアントアプリに戻ります。
  4. クライアントアプリがAPIエンドポイントの1つに到達するたびに、他の情報以外のユーザー名とトークンを提供する必要があります。
  5. APIは毎回、提供されたペアのユーザー名/トークンがDBに保存された最新のペアのユーザー名/トークンと一致し（注文するタイムスタンプを使用）、これらの情報を保存してから1時間以内に経過したことを確認します（ここでもタイムスタンプ）。その場合、APIはリクエストを処理します。それ以外の場合は、401Unauthorizedレスポンスを発行します。

これは意味がありますか？このアプローチには、私が見逃している巨視的なセキュリティホールがありますか？MongoDBを使用してこれらの情報を保存する際に見られる問題の1つは、コレクションが古いトークンですぐに肥大化することです。この意味で、古い情報がRedisによって自動的に削除されるように、1時間の有効期限ポリシーでRedisを使用するのが最善だと思います。

4

1 に答える 1

35

私はより良い解決策はこれだと思います：

  1. Facebook経由でログイン
  2. Facebook AccessTokenをサーバーに渡します（Androidアプリの場合はSSLを介して、Webアプリの場合はFBログイン後にAPIエンドポイントにリダイレクトするだけです）
  3. 与えられたものをチェックし、fb_access_tokenそれが有効であることを確認してください。を取得user_idし、emailこれを既存のユーザーと相互参照して、新しいユーザーか古いユーザーかを確認します。
  4. api_access_token次に、 WebアプリとAndroidアプリに返すランダムな個別のファイルを作成します。ログイン以外の目的でFacebookが必要な場合は、それを保存し、DBに新しいものとあなたfb_access_tokenのを関連付けます。api_access_tokenuser_id
  5. 今後のすべての呼び出しについて、api_access_tokenそれを認証するために送信します。より多くの情報を取得するためにが必要な場合はfb_access_token、DBから取得することでそれを行うことができます。

要約：可能な限り、を渡すことは避けてくださいfb_access_token。が侵害された場合api_access_token、攻撃者が誰であるか、攻撃者が何をしているのかなどを、攻撃者が把握する場合よりも詳細に制御できますfb_access_token。fb_access_tokenまた、有効期限の設定、 sの延長などをより細かく制御できます

HTTP経由で何らかのaccess_tokenを渡すときは、必ずSSLを使用してください。

于 2013-03-24T20:01:09.137 に答える