Question

I've been playing with the new ASP.NET identity offerings in the VS2013 RTW MVC template (for "indivual user accounts"), and it works great: I am able to integrate Facebook login while customizing the way the data is serialized.

All well and good, but I noticed that if I create a new SPA app (instead of MVC), the authentication story seems very different. As an example:

From the SPA template:

    public AccountController()
        : this(Startup.UserManagerFactory(), Startup.OAuthOptions.AccessTokenFormat)
    {
    }

    public AccountController(UserManager<IdentityUser> userManager,
        ISecureDataFormat<AuthenticationTicket> accessTokenFormat)
    {
        UserManager = userManager;
        AccessTokenFormat = accessTokenFormat;
    }

From the MVC template:

    public AccountController()
        : this(new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext())))
    {
    }

    public AccountController(UserManager<ApplicationUser> userManager)
    {
        UserManager = userManager;
    }

This is just the difference in constructors of the Account controller. There are many, many other differences as well. With the MVC version I was able to easily derive my own context class from ApplicationDBContext, and use that to store my own tables alongside the authentication tables. I couldn't figure out how to customize the data storage in the SPA template.

Also, the SPA template includes and uses this class: public class ApplicationOAuthProvider : OAuthAuthorizationServerProvider

The MVC template doesn't define (or use) this class.

I don't understand why there needs to be any differences at all between an MVC template and an SPA template.

Could anyone give me some guidance as to why authentication is handled so differently in these two templates? Starting a project from scratch, is there a preferred path to follow between the two? (It seems like the code in the MVC template is best, especially in terms of customizing how the data is stored by defining a custom EF Context class.)

Thanks...

-Ben

Was it helpful?

Solution

Take MVC and SPA project templates as Controller vs ApiController implementation sample. As well as CookieAuthentication and oAuthAuthentication.

  • MVC uses Controller at the first request as well as all subsequent requests (having request defined Action Methods).
  • SPA uses Controller at the first request to SPA and all other interactions are handled by ApiController.
  • MVC uses cookie authentication.
  • SPA uses oAuth authentication.

Now in real apps, we need to take mix of both. Stating this, you can use the IdentityModel.cs (ApplicationDBContext) and it's customized copy of MVC project in your SPA too.

In oAuth implementation, the token is issued in GrantResourceOwnerCredentials method of ApplicationOAuthProvider. The user verification uses the same database of Identity framework by default. Moreover, oAuth provide authentication check in ApiController. In the sample implementation, oAuth's ResourceOwner flow is provided where user's username and password are verified.

In my opinion, templates are starting point examples.

OTHER TIPS

I did notice the same thing when I first looked at all the posts about changing the model for the user and I couldn't find the model in the SPA template. Of course, the difference as @jd4u pointed out is that one is based on Controller and the other on ApiController.

So, I decided to see what it would take to make the SPA solution use the same Identity Model extension as the MVC template. I created a post that goes through the process that I went through. There is a link at the bottom to download the code from GitHub.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top