带有WebAPI和MVC应用程序的AngularJS SPA。 如何使用OWIN设置授权

Question

I am a newbie in AngularJS and WebAPI, and I am looking to create a SPA template for my organization that becomes boiler plate for making quick SPAs involving :

1. WebAPIs 2 - For purely data retrieval and insertion purposes and
2. MVC 5 Controllers - For fetching the views. Basically, all GET requests and nothing else
3. MVC Views : Partial Views that will be eventually loaded into ng-view placeholder
4. AngularJS Controllers - All MVC views will be tied to their respective individual Angular controllers.
5. ASP.NET Identity 2 : For User Store and Roles
6. OWIN Security : For token and cookie based authorization of my WebAPIs and MVC Controllers.

In startup.Auth.cs. I am using following authorization options :

app.UseCookieAuthentication(new CookieAuthenticationOptions());
app.UseOAuthBearerTokens(OAuthOptions);

I have created a small diagram to explain the flow of data

WebAPIs and MVC Controllers for now will sit in 1 tier, but architecture should allow them to be separated.

Now, my questions are

1. Is this architecture reasonable for building SPA
2. Would [Authorize] Attribute on my MVC controllers be able to recognize and decipher the cookie that WEBAPIs returned after authentication, considering that WebAPis and MVC app can be on two different tiers in future.

Answer 1

The [Authorize] attribute checks whether the IsAuthenticated property is set on the Request object that both MVC and Web API use. This property is set by the Identity middleware, as you configured in the startup.cs file.

Each request flows through the OWIN middleware pipeline before arriving at either an MVC or Web API controller. Middleware can then alter, or even completely handle the request. In essence, MVC and Web API are also middlewares themselves, saying "hey, if this url request matches this route, I'll handle it guys". ASP.NET Identity is a middleware which doesn't complete a request, but alters it before passing it on down the pipeline. It checks for supplied credentials in the request (in your case, in the form of a bearer token for the web API or in the form of a cookie for MVC). If they are found, then the authentication details are added to the request object, which is then utilized by Web API or MVC to do the [Authorize] check.

The reason that your app accepts only the tokens it has handed out itself is because it's encrypted with a key known only to the application itself. If you intend to accept tokens encrypted from a different application, these applications should use the same private key for encryption. You can configure these keys in the web.config. Be very careful not to lose these keys (for example, don't add your web.config with these details to a git repository). Alternatively, you can set up a separate authorization server which mediates between the different applications relying on it.

Hope this helps!