Authentication (Passport) enough for security with Node js backend server?

Question

Is PassportJS using Facebook Authentication enough for an iOS backend with Node JS?

I have the toobusy package as well to decline requests when things get to busy (I'm guessing it would be good for DDOSes).

I'm thinking of using nginx as a reverse proxy to my Node.JS server as well.

What are some more security measures that can scale? Some advice and tips? Anything security related that I should be concerned about that PassportJS's authenticated session can't handle?

Answer 1

It’s a bit hard to cram in all security-related best practices in one post, but for what it’s worth, here’s my take on the issue.

Providing authentication and securing it are two separate things. PassportJS will be able to handle everything related to authentication, but it’s an entirely different thing preventing it to be fooled or overwhelmed.

One (big) reason for putting PasswordJS behind a reverse proxy (RP) is that you’ll be able to provide a first line of defense for anything related to HTTP: header/body lengths/data, allowed methods, duplicate/unwanted headers, etc.

Nginx/Apache/HAProxy all provide excellent facilities to handle these cases and on the up-side, you get a nice separation of concerns as well: let the reverse proxy handle security and let PassportJS handle authentication. Architecture-wise, it will also make more sense because you’ll be able to hide the number and infrastructure of PassportJS nodes. Basically, you want to make it appear as there is only one entry point for your clients. Scaling out will also be easier with this architecture. As always, make sure that your RP(s) keep as little state as possible, preferably none, in order to scale linearly.

In order to configure your RP properly, you need to really understand what how PassportJS’ protocols (in case you want to provide more authentication methods than just Facebook’s) work. Knowing this, you can set up your RP(s) to:

• Reject any disallowed request HTTP method (TRACE, OPTION, PUT, DELETE, etc).
• Reject requests/headers/payload larger than a known size.
• Load-balance your PassportJS nodes.

One thing to be on the lookout for in terms of load-balancing are sticky sessions. Some authenticators store all their state in an encrypted cookie, others will be a simple session handle, which only can be understood by the node that created the session. So unless you have session sharing enabled for the latter type (if you need PassportJS resilience), you need to configure your RP to handle sticky sessions. This should be the maximum amount of state they should handle. Configured correctly, this may even work if you need to restart an RP.

As you diligently pointed out, toobusy (or equivalent) should be in place to handle throttling. In my experience, HAProxy is bit easier to work with than the other RPs with regards to throttling, but toobusy should work fine too, especially if you are already familiar with it.

Another thing that may or may not be in your control is network partitioning. Obviously, the RPs need to be accessible, but they should act as relays for your PassportJS nodes. Best practice, if possible, is to put your authentication nodes on a separate network/DMZ from your backend servers, so that they cannot be directly reached other than through the RP. If compromised, they shouldn’t be able to be used as stepping stones to the backend/internal network.