October 31, 2012, 8:00 AM —
Membership is a basic need for all applications which require personalization. Today more than ever, mobile applications are built either along side the web app or as the primary application platform. Where user accounts are concerned, the experience should be seamless regardless of the delivery method.
In .NET MVC (I’ll be referring to .NET 4 but most of this should apply to older versions) you are provided with some quick and easy ways to get up and running with membership on the web. When you begin a new MVC Web Application in Visual Studio the project is prepopulated with an Account controller and its related models that are hooked up to the default .NET membership provider. When you first run the project, the default .NET membership database is built which supplies the datastore for the default membership provider.
Out of the box, you get a lot of functionality that many applications require without having to write them from scratch. Things like password recovery, account lockout after too many invalid attempts, roles and role management, account personalization , not to mention the account creation and authentication itself. While it may not do everything your application needs it to, it does provide a huge head start for membership. So how do you take it the rest of the way from this foundation?
Here is a summary of how we accomplish this on most of our internal projects. Keep in mind it's only one method, and we have also had success writing our own membership provider. We generally have 3 main projects in our solutions:
Data.project - class library
WebApp.project - MVC Application
API.project - WCF or Web API REST service
We use the built in .NET membership provider as it exists out of the box. This gives us the features mentioned above as well as easy controller based role permission and access control in our MVC and API projects.
We then create our own User and Profile tables and data structure with a foreign key back to the .NET membershipId of the user. This gives us the flexibility to do all of the application specific things we need to do with a user profile while still giving us access to the default provider.
Authentication is straightforward in the MVC project, you can use the .NET Membership methods to authenticate by username and password:
With the mobile app you do not have the luxury of FormsAuthentication, but you can still use the default membership provider to validate the users credentials.
How you handle authentication after that is up to you and your project, but for basic needs we generally go with an authentication token that is returned by the API service after validation. This token is then included with each API request to prove they have been validated, usually in the request headers.
For the API, we base64 encode the username and password when submitting the credentials to the server, then if successful we pass back the auth token:
string decoded = System.Text.Encoding.UTF8.GetString(System.Convert.FromBase64String(Authmodel));
//convert your string into your authentication model here then
//return new authentication token
We also include additional logic during registration that builds out our proprietary user and profile tables at that time. This is handled in the data project so that both the API and MVC projects may access it.
Additionally, the data project handles the linking between our user and profile tables and that of the .NET Membership provider tables so the information can be accessed by both applications.
This is more of a conceptual example rather than a tutorial, but it is one option for handling authentication in a unified way. If you have questions about a specific aspect of this strategy, let me know and I’d be glad to describe it in further detail.