
Need some help understanding how to design Server-to-Server Authentication - atif089
I&#x27;m writing a SaaS application that should work in the following way<p><pre><code>  - the service takes input requests
  - checks if the API Key &#x2F; Referrer is valid
  - sends out a response
</code></pre>
At the same time there is the business user who can control what the output is in the response.<p>I want to make the onboarding&#x2F; authentication as smooth as possible but also maintain that is both secure and robust enough.<p>For example, the use case would look like this<p><pre><code>  - The customer installs the plugin &#x2F; 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
</code></pre>
So far it looks very straighforward for me to implement. Here is what complicates things and I don&#x27;t know<p><pre><code>  - 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 &#x2F; ip address, how do I authenticate them again?
</code></pre>
More Questions<p>1. Is this a good practice (secure) ?
2. Are there any tools&#x2F;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
======
SavageBeast
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](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.

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

