2

I have a REST API that will be called by other external 3rd party servers over the internet and be used only for machine to machine communication. I am looking for mechanisms to secure this API such that only servers that I designate will be allowed to use this API. I do not control the servers and cannot guarantee the IP addresses that these servers use.

I thought of using the OAuth client credentials flow to secure the API by giving each external server a client id and a client secret. But that made me realize why use OAuth at all and not directly deal with client id and secret i.e. when the external servers call my API they will pass the client id and client secret and if a compromise happens I will revoke the client secret and the communication will no longer be allowed. For the communication to start again, I will issue them a new client ID and secret.

Is this approach correct? If not, what is the advantage of using the client credentials flow in OAuth if the external server has to store and pass the client id and secret to get a token anyway.

Improve this question

1 Answer 1

Reset to default
2

Using client credentials flow would make sense if

  • there is need for separation of authorization server (which grants access) from resource server (which server API)
  • there is a need for separation of more trusted client part (which knows credentials) from less trusted (which uses token to call API)

if it is not a case then there is no need to complicate the API with OAuth.

I would also suggest considering client certificates for securing API access instead of id/secret combination. They have the benefit that the private key never needs to leave client machine, while secrets need to be transferred over the wire and received by the server every time they are used.

Improve this answer
6
  • What would be the security benefits of client certificates over client id / secret? These are both secrets ultimately stored on the disk
    – Tangui
    Oct 25, 2019 at 18:16
  • 1
    @Tangui - the private key of the certificate never needs to leave client machine - while secrets need to be transferred over the wire and received by the server every time they are used.
    – AGrzes
    Oct 25, 2019 at 18:29
  • The transfer of the client id and secret will be over SSL and TLS for each API call. Do client certificates still provide a benefit in this case?
    – Salman Hasrat Khan
    Oct 26, 2019 at 7:11
  • @SalmanHasratKhan as the secret still reaches server there is a chance to accidentally misplace it - for example in logs. If you add SSL termination in front of Your server later then suddenly secret traverse your internal network in plain. I'm not saying client certificates are silver bullet and should be always proffered - in many cases client id+secret is "secure enough" - I'm only asserting that client certificate authentication is more secure.
    – AGrzes
    Oct 26, 2019 at 7:31
  • @AGrzes you have a point. At the end of the day, it's about cost / benefit analysis. Also note that HTTP authentication schemes like HTTP Digest don't send the client id / secret in cleartext. Implementations, though, are often missing or bad in my experience.
    – Tangui
    Oct 26, 2019 at 14:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .