4

I'm developping a web application which will be communicating with a server over WebAPI. The server side will be on Azure and the client side will be on custom hosting with a JavaScript application (for example with ReactJS).

I want to authentificate the user like this:

  1. User enter login and pass in client app.
  2. Pass and login are sent to server over HTTPS with AJAX.
  3. If authentication succeed, server return a token to the client.
  4. Token is stored in local storage.
  5. All future requests to the server will contains the previously stored token as a parameter.

Is that authentication model secure enough? We always use .NET MVC for now, and store user information in server session, but this is new situation, where client didn't run on server directly, but only communicate with it over HTTPS.

Improve this question
5
  • 3
    This is a very broad quesiton. A few thoughts, though. This is a fairly standard solution, but the devil is in the details when you implement it. For instance, why use locla storage instead of an ordinary cookie? And you seem to suggest that the token will be sent over HTTP without TLS - that would be a problem.
    – Anders
    May 5, 2017 at 8:57
  • My bad, I forgot mean that HTTP communication will be secured by SSL. And second ad. I do not have reason to use localStorage over cookies, so if you suggest to use cookies, I can do that. I do not have a lot of experiences with this, so cookies oka?
    – Denis Stephanov
    May 5, 2017 at 9:29
  • If you do not have a specific reason to use local storage I would use cookies instead. But that is only one of many, many issues with implementing anything like this.
    – Anders
    May 5, 2017 at 12:18
  • One other consideration would be to hash the password on the client and only transmit the hash. Sending the actual password shouldn't be necessary.
    – Jean-Michel Florent
    May 5, 2017 at 13:43
  • 2
    @Jean-MichelFlorent That would not be good for security. If the hashes ever leak it will be possible to log in as any user. There are ways to authenticate without the server being able to see the password, but those are more complicated and thus more prone to implementation flaws.
    – kasperd
    May 7, 2017 at 8:04

1 Answer 1

Reset to default
1

What you describe here is pretty much the equivalent of classic cookie management (besides the parameter issue, see under)

When done on SPA applications like yours, usually the session ID (the token you describe) is part of an HTTP header.

I strongly advise you to avoid sending the session ID as a parameter as you are currently describing. Notably, because :

  • browsing history (client-side) would disclose the session ID and facilitate session hijacking
  • server logs would contain session ID's and facilitate session hijacking

Using HTTP headers instead mitigates those issues.

We always use .NET MVC for now, and store user information in server session, but this is new situation, where client didn't run on server directly,

About this : make sure that all your validation always happens at least server-side (and optionally client-side), and that sensitive session information stays server-side as well.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .