Publics API authenticate
Published: 2021-05-10 12:58:10


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kv6iljakbod7hh277evz.jpg)

### Scenario:

Some time ago, a new project was presented to me. I had to design the solution.

Among other stuff, that I will talk later, one of the challenges was about communicate a set of services that were expose to the public internet. Despite I was not comfortable about that, it was one of the requirements; a custom app had to be able to talk to the API directly, while most of the apps will talk to a specific API (entry point, **EP**). This **EP** then will have to talk to other services as well.

Then, the problem was: How do I control that every request between two APIs were actually allowed to ask and read information?

Every auth I had used at that time were in the form of: 1. I were provided a pair of key values to send in headers every time. 2. I had to ask for a new token every time I want to send a message.

But this time I wanted to make something different, and put in practise an advice given to me by an older college: triangles tends to be safe.

### The third guy:

To make my triangle, I created a new API that was going to be the source of true for permissions. Lets name it **SoT**.

Then, the general algorithm was:

1. Every API will have its own secret key.
2. **SoT** will have everybody’s secrets key.
3. When a request comes from **EP**, a transaction will be created on **SoT**.
4. Every request will be signed by emitter with secret and transaction.
5. **SoT** will be the only capable of tell if a signature is right or not.
6. Every time an API receives a requests, will ask to **SoT** if request’s signature is valid.

### Implementation:

Actually, coding that solution was quite straight forward; I needed two clients components and the SoT controllers:

From **EP** ask for create and sign a transaction

      transactionId = new uuid()
      sign = new Hash(EP_SECRET_KEY, transactionId)
      
      // EntryPoint as requester API name for signer field
      ok = sot.create(‘EntryPoint’, transactionId, sign)

Into **SoT**

     remoteKey = keys.get(input.signer)
     if input.sign == new Has(remoteKey, input.transactionId)
       createTransaction()
     else
       Error(403, ‘Can not create transaction’)

From a requested API (as endpoint middleware)

      if !sot.validate(input.sign, input.transactionId, input.signer)
        Error(403, ‘Invalid signature’)
      
      continue()

Once a request was authenticated, other internal calls can be authed in the same way.

About the secrets, they should be generated randomly in deploy time. Every time we deploy an API, we renew its secret and let **SoT** know about the change. They are stored in env vars.
Risks:

Not really found a lot to concern about. As we keep secrets real secrets, we should have no concern. Who want to make unauthorized requests should know the secrets and the hash function implemented.

### Sum up:

It’s quite easy to implement triangle authentications by our own with certain security level. What we need to care about is keep keys secrets and don’t expose our hash functions.

### Gretings:

Thanks for the read. Any suggestions or comments are appreciated.