2

Introduction

So in my developer team, we need two server-based applications one located in my company architecture let's call it company server (i.e. resource and authorization server in OAuth2 terminology) and the second one in customer architecture let's call it customer server (i.e client and resource owner). The customer server is loading data from the company server so my company server needs to authenticate it somehow.

My team decides to apply OAuth2 standard with authorization and resource server in a single monolith application, without even thinking of benefits. This would, of course, take more time to implement than a simple constant key stored in the header. So I wonder what are benefits of that solution.

I know that Basic Authentication needs user:password base64-encoded in every request but the customer server is a single user so token would be in fact constant key stored in the header and I will use that terminology in terms of simplicity.

Argument - Microservices

In M2M (machine-to-machine) communication according to this article, customer server should obtain the token by providing client_id and client_secret from authorization server then you can use with multiple resource servers. The first argument I see is that OAuth2 pattern allows us to use multiple resource servers without additionally reimplementing authorization in each of them (because token is JWT or resource server is checking token against authorization) but in our case we have only one monolithic company server that is responsible for being resource and authorization so I see no benefits of that.

Argument - Man-in-the-middle protection

The other argument of using OAuth2 is protection against man-in-the-middle attack if someone intercepts token. The authorization server can invalidate token (directly in storage or in case of signed JWT by short expiry time) and prevent using compromised token. But...

  1. Connection between servers is SSL secured
  2. There's no way to steal token from storage like in a web-based or mobile-based application because key is located on the server-side itself.

Summary

So I can't think of any security benefits using OAuth2 compared to using the constant key in every request in this situation.

dagi12
  • 449
  • 1
  • 5
  • 20

1 Answers1

0

Security is mostly a chicken-egg problem. You encrypt secrets with encryption key and then again you think how do we handle the encryption key in a secured way. Don't assume here that TLS/SSL is infallible. But the core objective has always been to reduce the attack surface and make it more difficult for malicious users to break the system.

Even when there is no "Man in the Middle", when you send the password with every request, both the receiving side and the sending side keep the password in memory. It leaves more opportunity for an attacker to get hold of the password. A simple memory dump can expose the password.

In case of tokens, you don't always need the private key in memory to verify the token signature. You can cache the valid tokens at the server end and simply do a string match. Or you can use a public private key pair.

So, it's okay not to use OAuth2, if the security requirements are not stringent enough to justify the development effort required for a more secured solution. But it is better to use proven best practices and solutions.

Saptarshi Basu
  • 8,640
  • 4
  • 39
  • 58
  • 1
    If someone can do memory dump it's very likely that he can decompile app or dump cache itself but it's probably more a question of where to keep secret/key/password (or whatever) to be secure, so I won't go into details. My point is that even if security requirements are strength enough OAuth2 isn't a more secure solution in my particular case only more scalable which is completely useless in such a simple architecture – dagi12 Nov 13 '19 at 17:50