0

I have a requirement to add security between service to API communication. The current implementation is client certificates. The client gets a certificate and just sends it in a cookie to the API. API does zero verification of the certificate. It pretty much is "just there" in the cookie.

The reason is they are concerned with additional overhead in any server validation as they need calls to be instantaneous. 3 seconds is too long. Think stock trades. Calls need to be real-time and instant.

So would implementing something like an OAuth JWT token and validating it on the API server add additional overhead that will slow down a transaction?

What about an API gateway? Does that also introduce additional overhead?

I'm looking for the fastest available solution that will not increase processing time but I can also validate incoming requests on the server.

Soufiane Tahiri
  • 2,667
  • 12
  • 27
tjax03
  • 103
  • 1

2 Answers2

0

Oauth is designed as a means of communicating identity between servers that don't necessarily trust each other. This is useful for third-party login scenarios. However, this lack of trust introduces overhead, since the authentication credentials cannot be sent directly. Typically, this involves the use of a middleman (i.e., the user).

Whether this involves additional overhead is typically irrelevant, since you only use Oauth to initiate a session. Once the user is identified, you should use some other system to identify the user (e.g., an authentication cookie).

Brian
  • 932
  • 5
  • 17
  • Yes so the issued comes with validating the Oauth Token. Doesn't validating it cause additional delay and overhead? – tjax03 Jan 19 '21 at 01:41
  • @tjax03: There is some overhead for Oauth (i.e., extra back-and-forth between servers and between server/client), but it is eclipsed by the time taken for the user to provide their credentials. You use Oauth if you want to identify a user using a third-party server. Once that identity is in place, you can stop using oauth for the rest of the session (which can last hours or days). – Brian Jan 19 '21 at 14:18
  • @tjax03: In other words, you only need to validate the Oauth Token once, not on every request. – Brian Jan 19 '21 at 14:22
0

I assume "service to API communication" refers to connections between two backend applications/services, correct me if you meant something else.

This phrase:

The client gets a certificate and just sends it in a cookie to the API.

...sounds a bit off. "Client certificates" refers to x509 certificates that are used to establish mutually authenticated TLS tunnels between two hosts, and certainly have nothing whatsoever to do with cookies. So perhaps you are talking about tokens of some sort?

Anyway, OAuth client credentials grant flow for authenticating server-to-server connections is a perfectly good approach. You can cache the access token for some time so you won't have to retrieve a new access token during the lifetime of the previous one.

Just remember to encrypt the connections in addition to authenticating them (that is, use HTTPS and validate certificates).

Note that client certificates (the actual x509 thing) can also be used for server-to-server authentication, although you would need a PKI and something like HashiCorp Vault for automating the key management, otherwise it becomes a hassle. The up-side is that this approach authenticates the peers on the network level, so an attacker on the network couldn't even reach your application stack to try and find vulnerabilities in it.

Teo Selenius
  • 41
  • 3