Need some help understanding how to design Server-to-Server Authentication | Hacker News Reader

Need some help understanding how to design Server-to-Server Authentication

1 pointatif0892 comments

I'm writing a SaaS application that should work in the following way

  - the service takes input requests
  - checks if the API Key / Referrer is valid
  - sends out a response

At the same time there is the business user who can control what the output is in the response.

I want to make the onboarding/ authentication as smooth as possible but also maintain that is both secure and robust enough.

For example, the use case would look like this

  - The customer installs the plugin / code on their website
  - The website reaches out to the SaaS server and authenticates itself (tells the SaaS app that it is contacting from xyz.com)
  - The SaaS app does a Reverse IP check to see if the request from the IP was same as xyz.com
  - A record is stored in the DB which maps the API key to the customers domain name, and the API Key is stored on the customers website.
  - All the requests from customers website to the SaaS server now uses the API Key that was generated

So far it looks very straighforward for me to implement. Here is what complicates things and I don't know

  - How do I authenticate correctly and eliminate fraud if there is more than 1 website hosted on the same ip
  - If a user changes their webhost / ip address, how do I authenticate them again?

More Questions

1. Is this a good practice (secure) ? 2. Are there any tools/libraries out there that provide this out of the box? 3. The whole post sounds very stupid and I should simply read how OAuth 2.0 works

There is naturally more than one way to skin this cat, and we could argue over the finer points of this question all day but the basic process looks like this:

1 - Some business process that assigns a customer an API Key and allows them to setup a Webhook destination on their own server ( mapped to their domain name - such that IP address management is a customer burden ).

2 - The customer hosted Webhook destination the user inputs is what your platform uses as a callback to inform the users system of some change.

3 - Requests to your system are made via HTTPS POST such that the API key is included in the body of the POST request ( likely some JSON ).

4 - The request is processed on your side, the API key is validated and used to look up the customers Webhook ( callback ) URL.

5 - The requested action is performed and some JSON structure is POSTed to the customers HTTPS Webhook ( the JSON format is a documented agreed on data structure - the customer is expected to parse this ).

Note that:

Customer API Keys are assigned by you, stored in your database such that they can be mapped to a customer hosted URL. An API key in this case might be a CustomerID and some significantly complex auth token such that the two of them in combination represent a significant burden to guess.

Customer API Keys are presumed to be stored on the customers machine and are NOT publicly accessible ( not stored in /var/www/secret_keys/myApiKey.txt ).

Customer API keys are sent via HTTPS in the body of a POST request - they're not getting logged anyplace and the data is encrypted during transport.

The use of a Webhook ( callback ) is not strictly necessary - but since you don't mention how long a request might take its worth considering making the whole process asynchronous.

The customer request could just as well return the resulting output over the same connection that initiated the request in the situation where the request takes a reasonably short amount of time.

A good example of something like this in action is https://www.twilio.com/sms - the Programmable SMS product. This product makes use of a process like the one I describe here and it's a great example to emulate.

For a learning experience, the docs are good, the API is clear, its cheap to play with and generally a nice tool.

This was extremely helpful. Thanks for taking out time to write this.

Reply on news.ycombinator.com