13

I am looking for help creating a Web API with custom username/password authentication.

I have my own database to validate users against, I do not want to use windows authentication.

I am hoping to be able to decorate my web api calls with an attribute like [Authorize], so that calls made without logging in will fail.

I do not want to have to pass credentials as a parameter to every method.

This API is going to be consumed primarily by mobile devices using Xamarin PCL.

The web API must use SSL.

This seems like a simple setup yet my googling does not reveal any super useful hits.

Ideally I'd want a Login controller that authorizes a user and allows subsequent method calls through.

Can someone provide a basic example or some good reading material?

Julien
  • 212
  • 1
  • 18
  • 53

3 Answers3

15

It's a big subject and you probably need to spend some time boning up on the basics, sorry.

That said... In order for subsequent method calls to be authenticated, you need something that can be passed back with every request. If you are calling your api from a website, say because you are using Angular or similar, then a simple cookie (appropriately encrypted and MACed) will work. Exactly how to implement that depends on whether you are using OWIN or not and whether you also have MVC in your project to serve up your pages. Don't create the cookie yourself, use FormsAuthentication or the equivalent OWIN middleware. You don't need to use Microsofts Membership or Identity, but be aware that doing your own password handling is not trivial and you really need to know what you are doing with that stuff - there is no substitute for a lot of research if you want to do that.

If you need to call the api from something other than a Web site, then a cookie is painful. Also be mindful that there are some subtle CSRF vulnerabilities when using cookies and Web api that you need to understand and protect against.

An alternative to cookies is to embed something like ThinkTecture Identityserver (it's free) and use that to issue oAuth tokens and then attach them to each API request. It has a number of advantages but is also more complex.

Resources
You did ask for pointers on where to start reading. Your task is complicated by the fact that Microsoft has been changing their "default" approach to it several times over the last few years. The current default approach is Identity which replaces the previous MembershipProvider (good riddance). If you are new to this, I'd suggest you go that route to be honest - you can extend it and it ties in with most of the rest of the stack very nicely. Yes, you lose some flexibility and you need to wrap it around your current user store. But you need to ask yourself if the security you get out of the box isn't worth that.

I would also recommend Brock Allen's blog. It's pretty hardcore but he knows his stuff and will often explain the innards of a lot of Microsoft authentication technologies.

I would recommend you try to read up on "OWIN Authentication Middleware". It's where it is all going, not least with ASP.Net vNext. Sadly, most of the documentation out there focus on how super easy it is to use (and it is - for a demo) but lack any in-depth info about how it really works, which can be very frustrating.

In order to get to grips with how tokens and the different standards work, I would recommend you watch this video here: http://www.ndcvideos.com/#/app/video/2651

Then look at Azure Mobile Services which has even got client-side libraries for handling the auth I believe or ThinkTecture Identity Server. Even if you end up not using IdSrv, by going through their tutorials on how to use it, you will learn an awful lot about how this whole thing works in general; it's all based on open standards. Docs here: http://identityserver.github.io/Documentation/docs/ Try working through their tutorials; They use a windows console app in place of an app, but the concept is the same.

I wish you luck but would like to just close by saying please don't just hack something together that seems to work. Web security is increasingly complex and it is very easy to leave vulnerabilities in your code - I talk from experience :)

Don't be a Moonpig.

flytzen
  • 7,348
  • 5
  • 38
  • 54
  • this is intended for mobile devices to consume. – Julien Jan 23 '15 at 19:15
  • If by mobile devices you mean apps on mobile rather than just websites on a mobile browser then you need something like oAuth tokens or the bearer tokens @Noel mentioned... Have a look at IdentityServer. Or if you host on Azure, they have authentication baked in to Mobile Services - but I have never used it so not sure it would do what you want. Or consider letting users just log in with Google/Facebook/Twitter. – flytzen Jan 23 '15 at 19:45
  • social network login is not an option. this is for mobile apps, yes – Julien Jan 23 '15 at 19:47
  • Then look at Azure Mobile Services or ThinkTecture Identity Server. Even if you end up *not* using IdSrv, by going through their tutorials on how to use it, you will learn an awful lot about how this whole thing works in general; it's all based on open standards. Docs here: http://identityserver.github.io/Documentation/docs/ Great overview video of OpenIDConnect here: http://www.ndcvideos.com/#/app/video/2651 – flytzen Jan 23 '15 at 19:50
  • I am writing the mobile apps in Xamarin PCL. Dont think azure mobile services are applicable. IdentifyServer does seem to be the way to go – Julien Jan 23 '15 at 19:59
  • Proof that auth* in ASP.NET is WAY harder than it ever needs to be. – Craig Brett Jun 14 '17 at 13:05
4

Depending on which version you are using. MVC5 Web API 2 implements an approach called bearer tokens. So you basically execute a post with username and password upfront to your https://applicationhostlocation/token endpoint. This will return a bearer token in the payload. You send subsequent https requests to your authorized web api methods with the bearer token in a header. This is all out of the box with the latest version of the web api. This link outlines the approach pretty well: http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api

Noel
  • 567
  • 1
  • 4
  • 11
  • Ohh nice, I wasn't aware they had baked that in. – flytzen Jan 23 '15 at 19:37
  • This article stinks. It focuses almost entirely on the client side, uses the built in membership database, and the sample app doesn't even build.`The Log In button sends a request to the token endpoint.` Where is the token endpoint? – Julien Jan 23 '15 at 19:52
2

Custom Membership Provider my friend!

https://codeutil.wordpress.com/2013/05/14/forms-authentication-in-asp-net-mvc-4/

With custom membership provider You can set a Authorization Cookie Token (aka AuthCookie), and use the Forms Authentication technology in your application. With a Custom Membership Provider, You'll be able to create a custom Validation Method that access your DataBase to match users credentials.

With the AuthCookie, every subsequent request will be authenticated, like a traditional Authorization Cookie technology.

Also, you can use a rewrite Url approach to enforce users to be redirected to the SSL pages: Best way in asp.net to force https for an entire site?

Community
  • 1
  • 1
Vitox
  • 3,852
  • 29
  • 30
  • You can definitely use that, but the MembershipProvider has been replaced with Identity now. Also - MembershipProvider is a leaky abstraction and tends to have little use in MVC/Web API. I wrote a post about that here: http://blog.lytzen.name/2013/03/using-aspnet-mvc-without.html Brock Allens take is here: http://brockallen.com/2012/09/02/think-twice-about-using-membershipprovider-and-simplemembership/ – flytzen Jan 23 '15 at 19:41
  • 1
    There is so much fragmented information out there and this doesn't help. All the Identity examples I found did not use a custom database doing custom authentication – Julien Jan 23 '15 at 19:43
  • @Julien: Aye indeed - too much focus on easy demos :( – flytzen Jan 23 '15 at 19:54
  • @Julien I updated my answer giving you a complete example of implementing a custom membership provider with a lot of extended functionalities. It covers from authenticating the user with your own database, to advanced Role Authorization – Vitox Jan 23 '15 at 20:08
  • 1
    @Frans I agree that this new Identity framework is charming. But It's very important to note that while the default SimpleCustomMembershipProvider is very limited, a well designed CustomMembershipProvider can be extremely powerful. – Vitox Jan 23 '15 at 20:13
  • your example is for MVC. I assume it is nearly identical for web api? – Julien Jan 23 '15 at 20:14
  • Yes. The call of membership methods to validate user / log out the user are being called from the controllers in the example, but the Implementation of the CustomMembershipProvider is the very same, which is the focus. – Vitox Jan 23 '15 at 20:17
  • Don't get me wrong, I hate both Identity and Membership for similar reasons (see http://blog.lytzen.name/2013/03/using-aspnet-mvc-without.html) :) my point was that a) either is superior to rolling your own unless you want to invest a lot of time and b) MembershipProvider is obsolete so if you are doing new stuff you probably don't want to go there. – flytzen Jan 23 '15 at 20:17
  • @Frans I can see your point, and to be really honest, also think that MembershipProvider is a little clumsy. You will probaly not use 10% of the methods implemented in the interface of MembershipProvider. But I also like to follow a Microsoft pattern. It maybe makes things clear for another programmer. Anyone that sees a CustomMembershipProvider class will know what it is for. By the way, what do you dislike about the Identity since it doesn't have the whole "not implemented" ghost methods? – Vitox Jan 23 '15 at 20:29
  • @Julien I have the same feeling about this. There is too fragmented information out there even at this point when Microsoft have released .NET Core 1.0. I still want to know how to connect my current users database with web api – Mr_LinDowsMac Jul 27 '16 at 18:04