I'm trying to wrap my head around to following web security question for a while now. Say we have a system set up as depicted in the picture below.
There is one main application with which the user interacts most of the time through a front end. Apart from the main application, there are multiple smaller applications. These applications also have front-ends with which the user can interact. Since we do not want to have a different user database for each of these applications, we decided to use oAuth2 for authentication.
The main application can interact with these other systems and vice versa. Most of the time it's in the context of a user interaction.
The request from main application to other application has to be (1) authorized and (2) we would like to know in "other application" on behalf of which user the call has been initiated (not "Main application", but "User").
It is really tempting to just send the user oAuth token from main application to other application. But this might have serious security implications as "other application" would now have all the rights of the user to temper with the main application (https://www.rfc-editor.org/rfc/rfc6749#section-10.3).
This might not be that bad, since we are managing these services ourselves, but this is certainly not the right approach in case we are dealing with 3rd party applications.
In summary, my question is: If the user initiates a request on an application, which in turn has to call another application to complete the request, how can we:
- Authorize this second call from application to other application (given the user is authorized and we have a central oAuth authentication system)
- And still somehow know on behalf of which user the call was initiated.
Ideally, the receiver end of the call would not even know that the call was initiated by the other application (it would just think it is a direct call from a user). It would just use the oAuth security interceptors already in place.
EDIT:
A thought I have is to add some additional authorization grant type to the Authorization server which takes as input:
- valid resource owner credentials
- a valid token of the user initiating the request
- the id of the resource server we will be accessing
The authorization server knows, given the requesting resource owner credentials:
- which resource server ids are allowed
- which permissions can be retained from the original token
The Authorization server:
- validates the requesting resource server credentials
- validates the user token
- validates whether the requesting resource server is allowed to request a token for the requested resource server
- retains intersection of the user permission on the user tokens and the allowed user permissions for the requesting resource server
The result is a short lived (non-refreshable) token
- on behalf of the requesting user
- only having the id of the resource server we will be accessing as audience
- having a subset of permissions of the original token.
