Secure connection between 2 servers

Question

I want to have some user-facing server, say server A. For certain tasks server A should submit a job request on server B. When server B is done, it should write the results to the database or maybe make a call on server A and let server A handle the result (not quite sure about this part right now).

The question is: how to securely connect server A and server B?

• On the endpoints on server BI only want to allow calls from server A.
• On server AI want certain end-points to only be available for server B (and maybe at some point some other worker machine server C, D.. etc).

I just don't find the right words to google for this. I suppose there are some really obvious buzzwords for this, but googling "Secure connection between 2 servers" does not yield what I am looking for.

I'm interested in the general name of this, but for the sake of completeness:

• The user-facing server will be using php
• The job-machines will be some node-apps

My own idea (but I don't know how to exactly implement it), would be something similar to when I connect via ssh to some server, where I just add my pub-key to the server. So it should be something along the lines: have a pub-key for server A stored on server B and vice versa. And then ensure, that only authenticated calls can be made to server B.

A full-fledged answer would be nice, but actually I am already happy to get a pointer into the right direction about what I should be googling for or maybe another question on SO.

Answer 1

The technical word you're looking for is "authentication" which is the process of establishing that a party is who they say they are. Closely related is "authorization" which is the process of determining if a party is permitted to do something.

For this problem, standard authentication techniques apply, very similar to how they would for a user. Generate a long, random authentication token and store it on server B. Connect from server B to server A using HTTPS, and pass the authentication token. A popular way to do this is with Bearer Authentication. Add the header:

Authorization: Bearer {access_token}

On server A, verify the token and execute the request if authorized.

This is just a specific way of implementing an API key. You could just as well put the access token (API key) directly into the request. It would be identical.

Typically these keys are stored in environment variables if you have a containerized or virtualized setup. I don't recommend storing them directly in the code (there are too many small mistakes that can lead to the code being visible).

There are more complex ways to do the same thing, and if you already have a good system for authenticating users, you can also just create a "service account" for server B and use your normal authentication scheme. But bearer tokens are a nice, simple way to handle machine-machine authentication without creating fake accounts.

Note that all approaches require that you be able to secure server B. Anyone who can access server B will be able to steal the token and impersonate the server. Mitigating this generally requires specialized hardware (such as an HSM), and is beyond the needs of most systems.

Though a bit more complex, another common technique is signing your requests. The advantage of signing is that you never have to send your authentication token over the network (even using HTTPS), and you only have to store the private key in one place (server B). This means that not even server A can masquerade as server B like it can with bearer authentication. I've often used JWS (JSON Web Signature) for this, but it is fairly complicated if you don't have a good library that handles it for you. Signing without JWS is tricky to get right, since you have to be very careful to sign everything that matters, and it's easy to overlook parts of the requests (headers for example). If you go down that road, you'll probably want a security expert to look it over.

Moving up from that, as Mikah notes, is OAuth2, but I generally don't recommend that for point-to-point authentication where you control everything and there aren't many entities. It's just a lot of complexity for little benefit. The point of OAuth2 is allowing centralized management of complex authentication environments. If you don't have those problems, complexity tends to reduce security, not improve it.