1

OAuth2、WebAPI2、およびインターフェースを使用してプロジェクトをセットアップする際に問題が発生しています。

シナリオ:

基本的にWebApi2であるプロジェクトをセットアップしています。この WebApi は、インターフェイスのビジネス ロジックとデータを提供します。

今のところ、インターフェイスは MVC5 Web アプリケーションですが、将来的には他の「アプリ」を接続できるようにしたいと考えています。ここで CORS の出番です。インターフェイスと WebAPI は異なるサーバーに配置できます。

ユーザーが Google や他のプロバイダーから登録できるように、OAuth2 を使用したいと考えています。

質問：

それはサインアップ部分に関係します：

まずはインターフェースMVCアプリにサインアップして、認証トークンをWebAPIに渡そうとしました。これは、これを実装する正しい方法ではないようです。

現在、WebApi プロジェクトでサインアップ インターフェイスを公開することを考えているため、MVC Web アプリケーションでサインアップすると、ユーザーは Api にリダイレクトされます。ただし、MVC Web アプリケーションでのすべてのアクションに対して、「このユーザーは認証されていますか」という呼び出しが必要になるため、これは心配になります。

2 つのオプション (または 3 番目のオプション) のどちらが望ましいか、誰にもわかりませんか?

私はこれがかなり広いことを知っていますが、優しくしてください;-)

4

2 に答える 2

2

これはアーキテクチャ部分に関するかなりの質問です。

2番目のアプローチは、すべてのアプリケーション（MVC5アプリケーションとサインアップ用のWebAPI）を考慮して2つのUIインターフェイスがあるという点で複雑に思えます

したがって、そうすることで、インターフェイスが API プロジェクトにさらに依存し、緊密に結合されます。

最初のアプローチでは、セキュリティだけが障害になる場合は、Web API プロジェクトへのサービス呼び出しの前後にトークンを暗号化/復号化できます。

最初のアプローチでは、ローカルストレージまたはセッションのインターフェイス/プレゼンテーションレイヤーでユーザーの認証を永続化できます

WebApi 自体は、アプリケーションと、ビジネス レイヤーなどのシステムの他のコンポーネントとの間の分散通信を目的としています。

しかし、あなたはすでにインターフェースレイヤーを持っているので、WebApiをユーザーインターフェースで重くする必要はないと思います。

最初のアプローチは良いでしょう。

于 2013-11-26T07:28:21.133 に答える
1

私たちのプロジェクトは同じアーキテクチャを持っています。

MVC サイト -> Web API(ビジネス) -> Web API(データ)

ビジネス API はサード パーティの開発者に公開されるため、OAuth2 認証が必要です。

Web API はすべてではなく、一部の機能しか開けません。おそらく「スコープ」を使用しますが、私たちの場合、API はサードパーティ用の API とサイト用の API の 2 種類しかありません。

したがって、認証ハンドラーで何かを行いました。認証ヘッダーの「ベアラー」スキームがありますが、なぜ私たちのサイト用に新しいスキームを作成しないのでしょうか?

その後、動作します。MVC サイトの新しいスキームを定義するだけです。「ASPX」、およびサイトからのフォーム Cookie を保存し、解決します。

また、ヘッダーのスキームが異なるため、どこからのリクエストかを知ることもできます。

ところで、スキームの名前に注意する必要があります。

于 2013-11-27T03:14:23.040 に答える