A new authentication method should be added to Server, Document and Entity endpoints that allows Servers to autonomously authenticate with each other and authorize their requests.
A Challenge endpoint should be created to return tracked nonces. The remote server makes a request to this endpoint before each operation it does with the local server, to receive a nonce and use as its authentication. The nonce is generated on the local server and saved in a memory cache for a short amount of time. We use nonce challenges in this fashion to prevent replay attacks.
Local servers should accept the X-Sylow-Message and X-Sylow-Signature HTTP headers as an authentication method. The Message is the nonce received earlier and the Signature is a signature created using the remote server's private key and the nonce as signed data.
Full flow:
A remote server wishes to send a new Document to the local server.
The remote server makes a GET request to /challenge.
The local server generates a nonce and saves it in memory, along with a TTL.
If the nonce isn't used by a request within the TTL, the nonce is no longer usable.
The local server responds to the GET request with the nonce.
The remote server creates a signature using its own Server record's private key, and the nonce as input data.
The remote server sends its POSTed Document to the local server, with the X-Sylow-Message header as the nonce, and the X-Sylow-Signature header as the signature.
The local server verifies that both headers are present, and verifies that the signature is authentic using its own copy of the remote server's public key.
From @peakwinter on June 6, 2017 16:51
X-Sylow-MessageandX-Sylow-SignatureHTTP headers as an authentication method. TheMessageis the nonce received earlier and theSignatureis a signature created using the remote server's private key and the nonce as signed data./challenge.X-Sylow-Messageheader as the nonce, and theX-Sylow-Signatureheader as the signature.Copied from original issue: SylowTech/sylow#41