I'm developing a simple web application in node.js. Users can log in from any page in the application, so I handle authentication in the server's code and logic, and the application's server-side code checks to see if a couple session variables are set. If they are, the application continues with user-specific information.

I'm unsure if this is the best way to handle the authentication logic. Should I move all authentication completely over to the application's code and only have the server listen and pass requests along, or, since the server is setting the session anyway, should I have it control back-end authentication logic as I'm handling it now?

In the end, what I'm really asking is: Conceptually, where should authentication be handled? In the server's code, or in the application's server-side code?

Edit: To be more specific, it's a public application on the internet. The logic that I'm questioning is entirely the server-side logic. Thank you for pointing that out to me. I edited my title to make it a little more accurate.

  • Intranet, extranet or web? Windows, *nix or other? Active directory, kerberos, pki, other or none-of-the-above? For instance, windows to windows on an intranet with an AD domain might be simpler under some conditions. – TimG May 14 '13 at 16:54
  • Have you considered using something like Passport? It's much easier to pass off the entire "code up an authentication scheme" to a library that's already been tested. – Dan Pichelman May 14 '13 at 17:16
  • The application that I'm creating is a learning experience for myself. It's not a serious endeavor. If I were to create anything that would be entirely open to the public and contain sensitive information, I don't think I would rely on just myself. I would rely on a well-tested library written by and maintained by many other people. Thanks for introducing me to Passport! :) – Nathan Lutterman May 14 '13 at 17:18

First it's good that you are not considering client-side authentication as this can be spoofed.

The main problems I see with using the server's built-in mechanisms for authentication are:

  1. Portability - Moving your application to a different server, becomes significantly more difficult.

  2. A lack of separation between local server users and remote web application users, when looking in your user list could make it harder to administer both the server and the application.

  3. If your application is hacked, they've already gained access at user level to your server. I wouldn't mind betting that this is significantly less secure than using separate authentication methods.

I recommend making your web application perform the authentication, perhaps using a community maintained library or by building it yourself. Store your users in a database table.

This overcomes the downsides listed.

I don't recommend using authentication mechanisms of other sites. The reasons for that are many, but to mention a few are:

  • Your visitor may not want to have an account with the 3rd party site.
  • It's poor practice to have one username/password for everything and this method is essentially doing that but with a veneer that makes people think it's ok.
  • It results in giving too much information to the 3rd party site (who share much of it with other sites which use their authentication mechanism).
  • The list is endless. I could add to it all day!
  • The other answers are really good and have good information, but your answer was made after I made my edits to make it a bit more specific, so it's pretty much the "right" one. I dunno if I mentioned it up top, but I'm building everything myself for the website for educational purposes. :) The "server" is really just a module I made in node.js. I suppose you're right, thought. It wouldn't hurt to keep the authentication separate, so I can re-use the server, if I want. – Nathan Lutterman May 15 '13 at 3:38

When you say "web application logic" you mean on the client side, in the JavaScript on the client's browser? If so, the answer is simple. You can't trust what happens on the client's browser, or even that the client is using a browser. It could be a hacking tool that makes your code think it's running in a browser. Heck, some standard browsers even let you edit JavaScript in a loaded page.

You can do checks on the client side to provide quick user-feedback. But any actual security constraints need to be enforced on the server - even though this sometimes means duplicating code.

Your "couple of fields" are your login tokens. If you store them in cookies, those tokens need to be created on the server in a cryptographically secure way so that someone (or some script) can't guess one in a few million tries. Hope that helps.


Any time you rely on anything coming from the client it can be spoofed. You definitely want to do some kind of hashing with some kind of server side "salt" which is stored securely on the server so you can encrypt / decrypt your client validation tokens without relying on anything "originating" from the client.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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