Should I use the built-in membership provider for an ASP .NET MVC application?

Question

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

Answer 1

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).