Resource authorization on multiple services

Question

I have a client facing micro-service where user logs-in and initiate actions against their resources. After authorization of the resource against the logged in user, the client facing service forwards the request ( with parameters Logged in user Id, Resource Id and requested action) to backend micro-service. Before performing the requested action, the backend micro-service again authorizes the request. Resource ownership data is replicated on both services DB.

Is that an anti pattern to double check resource ownership. If yes then should I remove authorization code from backend service?

Answer 1

The more common pattern will be to use two separate authentications mechanisms:

1. auth for public-facing API (client to 1st microservice)
2. auth for internal API between 1st and 2nd microservices.

This way you can protect internal BE service from the external calls. The visibility of the internal API credentials should be a lot more restricted compared to external API credentials.

However, if your 2nd microservice in some scenarios is public-facing too, then double-check is unavoidable and what you are doing makes sense.

Answer 2

You should try to operate as much as possible in a zero-trust environment. Your FE service should not trust the user and your BE service should not trust the FE service or the user. You are currently doing the right thing, do not remove it.

The FE service has to authenticate the user and authorise use of a resource. It must also authenticate itself against the BE service so that trust can be established -- this is often done with mTLS to encrypt the network traffic between the services, and some form of credential, such as a JWT or a simple username/password.

You have this - it is correct:

user    --->    FE    --->  BE
         |             |
        aa1           aa2

(aa1 == authentication & authorisation of the user, aa2 == a&A of the FE service by the BE service)

You should have at least some authentication and authorisation between all components of your design even if it only mTLS. Once a connection has been made between FE and BE, you can send the user data for the BE to verify before proceeding with the task.

In more sophisticated systems we wouldn't actually reauthenticate the user -- the first time we authenticate the user we generate a short-lived verifiable token and we pass that around along with the principal details needed to identify the user within the system.

In banking systems we go even further. We have many authentication mechanisms (username, password, pin code, finger-prints, facial-recognition, passport, drivers-licence), and because some are more trustworthy than others we give them a score, often called a CAM level. You can combine authentication mechanisms to increase the score. If you want to see your balance you can do so with your username and password, but if you want to transfer a large sum to a new counterparty we'll ask you to authenticate again, using an app or a physical device to generate a one-time password that you can use to validate the transaction.

The reason you need to do this is because our networks are considered insecure (and untrusted) - anything could be calling your BE service so it has to do its best to protect its data. It can use a token-validator service (often called a Secure Token Service (STS)) to do confirm what it's being told by others. Of course, if an attacker has compromised your auth methods then you have no control and you're screwed, but this mitigates a lot of other scenarios where an attacker has control of your network but not your extra-hardened authentication system.