0

So I have built a couple web apps now and I'm not sure if my authentication method is the most secure.

I currently compare the username/password combination to the AD account and if the authentication is successful it creates a session string that contains the user id. Then on page load for every page that requires you to be logged in checks that session string to see if it is null or has a value. If it is null it redirects you to the log in page but if it is not null then it loads the page.

My question is if there is a better way to handle authentication than this? The way I have it currently built works but I'm curious to see if there is a better way to handle this.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Matt P
  • 618
  • 2
  • 12
  • 20

3 Answers3

2

Why don't you use the built-in membership provider framework? You can still authenticate, but use AD as your membership provider? Then, let it return a cookie, which it will get posted ever single time you perform an action or call your API.

Here's a pretty good tutorial on how go about it.

I use a similar approach on some enterprise mobile apps that I'm authenticating users for against AD, and then the Web API automagically checks for the auth cookie. Simple enough.

Of course, if all you need is web apps, server over a browser, a simpler option would be Windows auth (Kerberos/NTLM), and then you won't be have to worry about managing the authentication provider.

napo
  • 869
  • 9
  • 19
2

I would suggest staying away from storing data in the Session. You want your server to be stateless; what happens to your session string if you deploy your web app to multiple servers (say, in a cloud environment), or if your session data expires while the user is still on your site?

The better way to handle authentication tokens is to store it in a cookie that gets sent up with every request.

This has been covered several times on SO, so I'll refer you to this answer first.

Community
  • 1
  • 1
Ryan Erdmann
  • 1,786
  • 10
  • 11
2

The "best" way in my opinion would be to use claims based authentication using WIF.

http://en.wikipedia.org/wiki/Windows_Identity_Foundation

Explain "claims-based authentication" to a 5-year-old

This way you can use AD if you want and users will automatically be redirected to a log in page and the identity will be stored in the user's cookies so they can persist their log in session and this is will all be handled automatically. Also if you later want to switch to using OpenID or some other mechanism for authentication then you won't need to change much at all in your web app other than updating a URL in your web.config for the server you trust to provide authentication.

This will also allow you to do Single Sign On, so if later on you have some other web service you created and you need to call that service from the web app you can easily delegate the user's authentication to authenticate to the web service.

Community
  • 1
  • 1
mclaassen
  • 5,018
  • 4
  • 30
  • 52
  • 1
    This, a thousand times. Security is easy. Good security is HARD. Don't cut corners or roll your own solution. Stick with something proven, built by people smarter than you are. – Rick Liddle Jul 03 '14 at 18:38
  • 1
    I agree with Rick, but claims may be overkill for the OP's use case. Obviously the OP should use an existing framework, (specifically, Asp.Net Membership, as [Napo suggests](http://stackoverflow.com/a/24559874/18192)), but claims is likely to be overkill. The [official documentation](http://msdn.microsoft.com/en-us/library/ff359101.aspx#sec2) acknowledges that claims is less useful if making use of Integrated Windows Authentication, since many of the features it provides are already available via the domain controller. Claims is more effort to setup than generic ASP.Net membership. – Brian Jul 04 '14 at 00:51