A third party service provider is exposing a payment API that we need to integrate on our backend.
As transport communication we will consume this API using TLS with Client Certificate and over a MPLS private network.
As authentication framework, the third party is suggesting Oauth2;
I'm instead suggesting a "ligther" authentication like an APIKey/ClientSecret.
Because, from my "limited" experience, I don't see any benefits in using Oauth2 in this scenario.
- The Api will be consumed by just one single service user used by our backend.
- We don't have any level of authorization (no claims).
- In Oauth2, to protect credentials, you use them just to get an access token and you authenticate to the API using it; in our scenario, credentials are not personal credentials but a single service credentials provided by the third party API provider. Leaking them would be like leaking an APIKey from my point of view.
- In case of some security breach you will just have to revoke the APIKey; having Oauth2, you have to revoke the refresh token leaving the granted access token still valid.
- This will force us to create some utility library (based on Restsharp) and database tables to handle all the back and forth imposed by Oauth2 protocol. One thing that I saw in other projects is that this library need to be "synchronized" in case of concurrent access.
Probably I am missing some important points and my oversimplification is not admittable in an crucial service like a payment API.
In your experience, does Oauth2 have some advantages over a "basic authentication" in this specific scenario?