5

モバイルアプリのバックエンドに取り組んでおり、ASP.NET MVC 4WebApiを使用してRESTfulAPIを構築しています。アプリはiOSとAndroidで動作します。私のユーザーは自分のFacebookアカウントでのみログインでき、ログインした場合にのみ、すべての機能を使用できます。

私はモバイルアプリの経験があまりないので、それは設計上の問題です。2つのシナリオ（または3つ目のシナリオ）のどちらが、Facebook認証の責任者についてあなたにとってより良い設計だと思われますか。

  1. モバイルクライアントが責任を負います。バックエンドにアクセスせずに、Facebookと直接通信し、ユーザーが自分の資格情報を入力できるようにします。Facebookからトークンを取得すると、初めてバックエンドにアクセスし、すべてのリクエストでトークンを渡します。
  2. バックエンドAPIが責任を負います。モバイルクライアントは、そこからリソースにアクセスしようとします。バックエンドはクライアントから認証トークンを取得しないため、Facebookログインにリダイレクトします。ユーザーがクレデンシャルを入力すると、Facebookはトークンを渡してバックエンドに返信します。次に、バックエンドは、目的のリソースに関するクライアントの応答に喜んで応答します。

もちろん、2番目のシナリオは、バックエンドがDotNetOpenAuthなどのパッケージを使用してOAuthを処理する必要があることを意味しますが、1番目のシナリオでは、これらはすべてモバイルクライアントで発生します。

4

1 に答える 1

1

最初のアプローチは、httpのステートレスな性質をより適切にエミュレートするため、より正確だと思います（基本認証などの従来のhttp認証方法と同等です）。呼び出しのたびに、FacebookOAuthトークンをWebAPIに送信します。それ以外の場合、サーバーは、たとえばCookieなどのメカニズムを使用して、認証されたユーザーに関する状態を維持する必要があります。これは、そもそも正しく見えません。サーバー側の認証は、サーバーが認証を必要とする他のサービスを利用する必要がある場合にのみ使用しますが、ここではあなたの場合のように見えます。

于 2013-03-27T12:51:03.650 に答える