0

I am currently developing an HTML5/C# web app to replace an older ASP.NET forms app and after reading many blogs and posts I still do not understand the objectives, purposes, and weaknesses of the built in authentication schemes in ASP.NET. So if I implemented my own authentication/security in the following way, what would you change? IE - how would you be smarter and faster than me. (The app uses SignalR web socket and AJAX requests to drive the HTML5 front end).

  • All users would be anonymous according to ASP.NET.
  • User information would be stored in an app wide dictionary object.
  • Login would be accomplished by server checking provided creds against a user table in the DB.
  • Upon successful login server would generate token for client to store as long as I think is convenient and safe.
  • Token would be sent with all requests so every request could be validated on the server and only appropriate actions be done (not sure if SignalR has a way to automagically add a token to every request)
  • Server would have to manually expire tokens.

Would it be a good idea to enable the session state and store basic user info there so I don't have to manually expire the tokens? But then I would have to manually add the cookie data to SignalR requests right?

Honestly I'm more comfortable just rolling my own, especially since we have other apps (and other developers that don't like auth frameworks) that depend on our custom user table. The app is not public so we don't need anything fancy like OAuth or authentication servers.

Improve this question
3
  • Re-inventing your own (almost certainly insecure) authentication scheme when sturdy, secure, battle-tested and relatively easy to use authentication schemes already exist is not the greatest idea I've ever heard, especially when you admit that you don't understand the fundamental principles of authentication, authorization and accounting.
    – Robert Harvey
    Apr 27, 2017 at 22:38
  • So which do you think makes more sense... spending the time to educate yourself about all of the relevant security implications before you roll your own, or simply adopting an existing authentication mechanism that's already better written than either you or I could accomplish?
    – Robert Harvey
    Apr 27, 2017 at 22:46
  • @RobertHarvey Then what would you recommend for a simple authentication framework that allows my own defined set of privileges stored in my own database table (not Windows auth)?
    – Ian
    Apr 28, 2017 at 2:12

1 Answer 1

Reset to default
1

Ok so that's basically a session token.

Apart for your 'app wide dictionary' which will eat memory and crash your server at some level of users. The problem with your scheme is how to you integrate checking the token with iis so that all requests are authenticated/authorized? (yes that means logo.jpg as well)

Sure there are various ways to do it. But you are bound to leave a hole if you try to roll your own.

Unfortunately the new auth methods can be more tricky to get working than the old ones we are used to. But its worth following a guide through, you only have to learn it once.

Improve this answer
3
  • And what then are the options for whole server authentication when developing a web API? Basic and Forms authentication won't do this and most tutorials don't mention securing every single resource. In my old ASP app I just used HTTP handlers to validate requests to any directory with PDFs or images that I didn't want folks viewing without auth.
    – Ian
    Apr 28, 2017 at 17:08
  • if your doing a web.api project in vs2015 you should get 3 startup options. It will auto create the filters and what not for you
    – Ewan
    Apr 28, 2017 at 17:12
  • I wrote another more specific question: softwareengineering.stackexchange.com/questions/348020/….
    – Ian
    Apr 28, 2017 at 17:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.