Understanding ASP.NET MVC5 new authentication mechanism

Question

Hi I am trying to get a hang of how the new authentication mechanism works in MVC5 in the SPA template and I seem to be left confused.My end goal is to create an API that will be exposed to a SPA , iOS , Android and Windows Phone clients

Here is what I understand:

I understand that somehow at startup the class decorated with:

[assembly: OwinStartup(typeof(WebApplication1.Startup))]

is magicly calling ConfigureAuth method:

Inside this method I have 3 lines of code and inside the startup class constructor I have initialized the OAuth authentication options:

 static Startup(){
      PublicClientId = "self";

      UserManagerFactory = () => new UserManager<IdentityUser>(new UserStore<IdentityUser>());

      OAuthOptions = new OAuthAuthorizationServerOptions {
                TokenEndpointPath = new PathString("/Token"),
                Provider = new ApplicationOAuthProvider(PublicClientId, UserManagerFactory),
                AuthorizeEndpointPath = new PathString("/api/Account/ExternalLogin"),
                AccessTokenExpireTimeSpan = TimeSpan.FromDays(14),
                AllowInsecureHttp = true
      };
}

public void ConfigureAuth(IAppBuilder app)
{
     app.UseCookieAuthentication(new CookieAuthenticationOptions());
     app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
     app.UseOAuthBearerTokens(OAuthOptions);
}

The first two lines in ConfigureAuth seem to set my application and external application to use cookies for storing authentication state, while the third seems to state that it is using bearer tokens for my application.

From what limited knowledge I have so far about mobile devices native apps do not understand cookies and I should use tokens for authentication.

If that is the case shouldn't the externalSignIn be set to Bearer tokes instead of external cookie?

While debugging I also noticed that in the OAuthProvider the authentication type is actually set to bearrer tokens.If that is the case what does this line of code actualy do:

app.UseCookieAuthentication(new CookieAuthenticationOptions());

Some clarification to how this works would be grattely appreciated I could only find information online that shows me how tu use external logins.

Answer 1

It seems to me that the MVC 5 SPA Template is a demonstration of what is possible more than a commitment to a particular best practice.

I have found that removing the line app.UseCookieAuthentication(new CookieAuthenticationOptions()); has no effect on the SPA at all because, as is typical with SPAs, all HTML needed is retrieved anonymously and all authentication is, thereafter, done on any subsequent requests for data. In this case data would be retrieved from WebAPI endpoints and protected with Bearer Tokens.

I don't know why it has been done this way. There are a number of other areas like this where two different concerns are a bit muddled. for example the traditional Global.asax MVC Application_Start is still in place but the newer OWIN Startup mechanism is also present. There is no reason why everything in Application_Start (Filter / Route / Bundle registration, etc.) couldn't have been handled in OWIN Startup.

There are other issues too. If you turn on External Auth (e.g. with Google) and then reduce the AccessTokenExpireTimeSpan, you'll find that when the Token has expired your SPA presents a 'Authorization has been denied for this request.' message. In other words, there is no mechanism in place for Token refreshes. This is not immediately apparent out of the box because the Access Token timeout is set to 14 days, which is rather insecure when considering Cross-Site Request Forgery attacks and the like. Furthermore, there is no enforcement of a transport security mechanism, such as SSL. Tokens are not inherently secure and need to be secured in transport to prevent CRSF attacks and data being extracted en route.

So, MVC 5 SPA is good as a demo, I think, but I wouldn't use it in production. It shows what the new OWIN Middleware can do but it is no substitute for a comprehensive knowledge of Token-based security.