Implementation agnostic discussion.
Assume the following diagram.
I make the assumption that the client has obtained an access token when the user authenticated with the auth server. Which flow was picked(implicit, authorization code, password) is irrelevant. I would like to start the discussion from the point where the client has already obtained the access token.
From that point on, it is clear to me what happens when the client needs to access a single resource server.
So in that 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 trouble when the client follows the red line in the diagram. So i need to access a service(resource server) which in order to reply needs to access another service(also resource server). How does the flow go in that case?
Scenario 1.
The problem here as i see it is that i loose the user permissions. I will execute the request to the "Data service" with the "Order's service" permissions and not the user's permissions.
Scenario 2.
Here i execute with the user's permissions but now i see that my "Data service" is exposed and open to any other service. (Actually i don't know if oauth2 provides such limitation. Restrict a client only to specific resource servers)
Scenario 3.
Here i see a combination of the above scenarios where the "Orders service" will provide both tokens to the data service. The user access token so that request is executed with the right permissions and the "Order's service" client access token so that i know that the service is allowed to talk to the "Data service".
Implementation
I am using spring boot and spring security in order to setup my oauth2 components seen above. I already have an auth server, a resource server and a client. The client at the moment talks to a resource server without the request being delegated to another resource server.
Depending on the best approach how would i go on the implementation side? What changes do i need to make to my resource servers so that they can talk securely to each other?
Thank you for your time
From my understanding, first approach would seem the correct one, in the sense that "Orders Service" acts as a client to "Data Service" resource server. So it should use an access token provided to it as a client.
OIDC is specifically intended for clients (read here . also look on that page for "why-use-access-tokens-to-secure-apis"), no resource server should use that id_token for anything (but it's true that each implementor follows its own decisions on that matter so it's confusing. i recommend reading here).
So, from my point of view, we have these alternatives to reach what you asked for:
I have only used alternative 4 so far (it was for internal network purposes). So cannot say much more about the other 3 in real world.
I am yet to see a concrete explanation based on 'community accepted standards' on how to reach what you asked for (and that does not directly contradict specifications).
You're mixing authorization and identity concepts.
oauth2 roles (resource owner
, resource server
, authorization server
and client
) are roles and not identities. Your order service has the resource server
role in one scenario and client
role in the other.
The scenario 1 is the right approach.
Oauth2 tokens are indeed tied to some resources identifiers and so restricting a client to a specific resource is a built-in feature.
Client related authorization set is handled using Oauth2 scope
concept
If you want to propagate the end user identity across a request flow you have to propagate an identity token (for example a JWT one) across the flow (see OIDC). However it may not be the data service responsibility to handle end user authorizations.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With