I've been using a custom membership provider for authentication in all my web form applications till now. I'm about to start developing my first website using MVC. I'm wondering if I should I use the built-in membership provider that ships with ASP .NET MVC, or if I should create my own. My site needs to integrate with openid, facebook, google etc for authentication and openauth for api access. I'm wondering how easy it would be to use the built-in one for my needs.

I think your asking two questions. Building a customer Membership Provider and using a library like Janrain are two different things.
–
jfarJul 21 '10 at 17:54

Actually I'm not wondering about 3rd party libraries like Janrain...I wanted to know mainly whether I should use the built in membership system or implement my own (for ordinary authentication). Down the road, I may consider integrating with openid, etc. But I need a basic login system going right now that can scale later. StackOverflow, for instance is built using MVC. How did they implement their login system?
–
PrabhuJul 21 '10 at 18:37

5 Answers
5

Personally, I hate using the ASP.NET Membership provider that's available in the core framework ... when it persists to a SQL SERVER database. All the tables and views are such an overkill for a single website. For a hosting company? .. maybe ... but for all the enterprise sites I've done .. it's been such a fraking overkill and hassle. As to the actual provider interface, etc ... it's very good .. but still very hardcore, etc. An overkill for simple-medium sites, IMO.

So personally, I would use some simple custom code to handle membership persistence for most basic-medium websites.

This then segues to your second question: OpenId. Use Andrew Arnott's DotNetOpenAuth .NET framework -> it litterally Kicks Serious Ass (tm). Using this is independent of HOW you save the user membership data to a repository. Ie. if you go ahead and use the Sql Server + ASP.NET Membership provider, you can still (and should) use DotNetOpenAuth. If you have a simple, custom way to save user details to a database (which is what I do), you can also still use DotNetOpenAuth -- the two are independent of each other.

So, IMO, don't use the overcomplicated ASP.NET Membership + Sql Server stuff but a simple table or two to save your own user details. Next, you MUST use DotNetOpenAuth for any OpenId stuff (StackOverflow uses DotNetOpenAuth to handle their OpenId login).

Good Luck :)

(I'm sure my opnions of the ASP.NET Membership provider + Sql Server to persist that info will cause a few people to nerd-rage, here).

+1 - I really like your answer because it demonstrates using the correct tools for the job. I have seen lots of projects where they contain overly complicated add-ons which are totally overkill for what the application needs. In nearly all cases where I have experienced this it usually turns out that the dev wanted a new toy to play with... without actually thinking about whether it is correct for the job.
–
DalJul 22 '10 at 8:04

If you have to ask, you shouldn't be writing your own provider. Doing security well is really hard. Doing it wrong is incredibly easy.

But the good news is that what you want is incredibly common, and there are tested, off-the-shelf tools which already do it. An example is Janrain. There are others, too. Use an existing, proven tool whenever possible.

Take a look at what's happening with NerdDinner. They've recently (6 months ago) integrated with OpenID, with Google, Yahoo as featured providers. They're still allowing all their 'native' logins as well. Here's an example of a site allowing the user to authenticate in different ways.

If you can mirror some of their functionality, you'd be able to roll in Facebook, OpenAuth, etc. The big benefit is that it's already been implemented in ASP.NET MVC, and you'd just have to borrow some of that implementation.

Awesome. The NerdDinner tutorial is one of the best written tutorials ever. Do they have a tutorial for the login mechanism?
–
PrabhuJul 21 '10 at 23:57

@Prabhu: I haven't seen a tutorial or walkthrough of the login, but I suspect you can get in touch with Jon Galloway. He'll likely be able to point you to some/any resources on getting familiar with the login system they've got. twitter.com/jongalloway
–
p.campbellJul 22 '10 at 0:02

You essentially have a single user which can be authenticated multiple ways.

Using the built in provider, which you could of course switch out at any time, does not preclude you from authenticating that user multiple ways.

When a user authenticates with OpenID, Facebook, etc. match that login against a table that matches the specific login method and identity to the Forms identity and just set the set the user as logged in with their canonical Membership user name.

If a new user authenticates to your site and doesn't have an account just create one in the membership provider automatically. Set the password to some random garbage because they'll never use it. Let them continue to associate multiple login types with it as well.

If a user wants to then also have a direct login just use the standard Membership provider password reset mechanisms and provide them with one.

Long story short: use the built in mechanism for now. It doesn't stop you from doing what you want to do.

The recently introduced SimpleMembershipProvider addresses many issues with the old asp.net membership. Namely ease of use and control over User table schema. This should be the starting point for any new apps (as of 11/2012).

See the below link for a primer on SimpleMembershipProvider along with a decent history on asp.net membership.