OAuth 2.0 In Microservices: When a resource server communicates with another resource server

Question

Currently, the user is passing the access token, with [Scope A] to the web portal. Once the user requests to view a resource, the token is passed to the resource server [Web App A] to obtain the resource. However, to obtain the resource, the resource server must communicate with [Web App B] to obtain a subset of information, therefore it requires [Scope B]. Since the user only authorized [Scope A] the call will fail.

Below are scenarios of fixes that could be applied:

• Scenario 1: The user is requested to authorize [Scope A] and [Scope B]. The problem here is that the user might not want the [Web Portal] to access [Web App B] directly.
• Scenario 2: [Web App A] becomes the client of [Web App B], using it's own access token to request resources from [Web App B]. The problem here is that the user context is lost.

I am looking for the standard solution, I might be doing something wrong from my end.

A few other questions I would like to ask:

• Should the access token be passed around microservices?
• Should there be a different authorization framework for internal requests?

Answer 1

If these are different applications (to the user) then yes, user should be asked to confirm if he is willing to authorise A to access B. If he does not want to that, then A has no biz talking to B on behalf of the said user.

If this is set of microservices then user need to interact with via Web Page and any subsequent calls if being made to n different services is something that user should not be concerned with. As such he is trusting the web page and asking web page for some data. You have set of microservices sitting behind to answer that, is not of concern for user and his token.

So you can make use of second option. Talking about user context, well that can shared in some other forms like passing via headers.

Should the access token be passed around microservices?

Yes, there should be no harm in that. It adds to the payload but certainly can be done. Important thing to note is that users access token can be used by services to mimic a user call to another service. If such calls are threat to your design then you should reconsider. But mostly we feel that what ever you do within your boundary is safe and you can trust other services in that boundary and hence can pass it along.

Should there be a different authorization framework for internal requests?

It depends, if you want to separate it for security reason, you can, if you want to do it for load reason you can.

You can also think of stripping tokens at the gateway (verify the token at the entrypoint) and let go off it. For systems where you can trust other services (amongst your microservices) and ensure no on one can access them directly, other than the API gateways, you can just let the token go. You loose authorization bit, but again our point is we trust services and believe they know what they are doing, so we do not put restrictions to such calls.