OAuth2 thread from resource server to another

Question

Introducing agnostic discussion.

Suppose the following diagram.

• Black lines indicate which services are protected by the auth server.
• The green lines show the interaction between the services (customers and order services must go through a data service that will access the database. StandAlone does not like other services).
• Red line shows a specific request stream
• The data service is not displayed directly from the outside and can only be accessed by other services that are allowed to do so.

I make the assumption that the client received the access token when the user authenticated on the auth server. Which stream was selected (implicit, authorization code, password) does not matter. I would like to start the discussion from the moment when the client has already received the access token.

From this moment it becomes clear to me what happens when a client needs access to a single resource server.

• Make a request to the resource server and transfer the purchased token
• The resource server checks the token (irrelevant)
• If appropriate, submit a request.

So, in this diagram, if the client was to access the "StandAlone Service" (which does not talk to any other resource server), the flow is clear to me.

I am having problems when the client follows the red line in the diagram. Therefore, I need to access a service (resource server), which, in order to respond, must access another service (also a resource server). How is the flow going in this case?

Scenario 1.

• The Orders service is installed on both the resource server and the client.
• The client makes a request using the access token, but the Orders service will receive another token with its client credentials in order to talk to the Data Service.

The problem here, as I see it, is that I'm losing user rights. I made a request to the "data service" with the permissions "Order the service", and not with user rights.

Scenario 2.

• The Orders service is configured only as a resource server.
• The client makes a request with a user token, and the Orders service sends the same token to the Data Service

Here I execute with user permissions, but now I see that my "Data Service" is open and open to any other service. (Actually, I don’t know if oauth2 provides such a restriction. Client restriction only on certain resource servers)

Scenario 3.

Here I see a combination of the above scenarios in which the Order Service will provide both tokens to the data service. The user’s access token, so that the request is executed with the correct permissions and the client’s access token is “Service Order”, so that I know that the service is allowed to talk to the “Data Service”.

Implementation

I use spring to boot and spring to configure my oauth2 components discussed above. I already have an auth server, resource server and client. The client is currently talking to the resource server without transferring the request to another resource server.

Depending on the best approach, how should I go on the implementation side? What changes do I need to make to my resource servers so that they can talk to each other safely?

thank you for your time

Answer 1

In my opinion, the first approach seems correct, in the sense that the Order Service acts as a client for the Data Service resource server. Therefore, he must use the access token provided to him as a client.

OIDC is specifically designed for clients (read here . Also see on this page for "why-use-access-tokens-to-secure-apis"), no resource server should use this id_token for anything (but it’s true that each developer follows his own decisions in this regard, so he is confused. I recommend reading here ).

So, from my point of view, we have these alternatives to achieve what you requested:

• An “Order Service” acts as a customer with full control within the “Data Service” resources (or at least the “type of resource” you want to access). If you need to provide the “Data Service” with some information about who initiated the “Order Service” to request something, then this is part of the payload when requesting the resource (it is not part of the access_token).
• The owner of the resource (User) previously granted certain access to the “Order Services” to his resources “Data Service”. As in the previous paragraph, but the "Order Service" does not have access to all resources of the data service. Information from the creator is still part of the payload.
• To avoid sending information about the sender as part of the payload, I assume that we will need to generate the credentials of the “Orders” client on demand with some fields associated with the owner of the resource, or some user who previously created them and bindings to his profile so that you can later get the “Order Service.” That where he begins to get confused in my work and the documentation is not clear (OAuth2 RFC does not cover this).
• Look at the whole system as a whole, with only one client. The access_token received from the front client (the one with which the user interacts) contains all the necessary necessary areas. And the “client”, “order service”, “customer service” use the same client credentials and simply forward the “access token” from one to another (so that it no longer provides “customer credentials”). Thus, they both have exactly the same set of permissions. The resource owner will grant these permissions the first time they log in to the authorization server, so this is not so bad. But, obviously, this means that you cannot specify permissions from each “client of a submodule”, and resource servers cannot determine which “submodule” was a request based on a request for user access information (if necessary, it should be part of the payload ) this has security implications for certain .

I used only alternative 4 (this was for internal networks). So I can’t say more about the other 3 in the real world.

I have yet to see a specific explanation based on “generally accepted standards” on how to achieve what you requested (and this does not directly contradict the specifications).

Answer 2

You mix the concepts of authorization and identification.

oauth2 roles ( resource owner , resource server , authorization server and client ) are roles, not identities. Your order service has a resource server role in one scenario and a client role in another.

Scenario 1 is the right approach.

Oauth2 characters are really tied to some resource identifiers, so restricting a client to a specific resource is a built-in function.

Client authorization set is handled using the Oauth2 scope concept

If you want to distribute the end-user identifier in the request stream, you need to distribute the identification token (for example, JWT) through the stream (see RSIN ). However, this does not mean that the responsibility for data processing should meet the requirements of users.