...
Requiring two calls to gain access to a resources might not be as bad as it sounds. Here is an extreme example where it could actually be a performance boost. The GET /entity/{id}/bundle service allows a caller to gain access to fourteen different aspects of an Entity in a single call. In this case, each aspect is actually its own service, each with its own integrated authorization. This means a single call to GET /entity/{id}/bundle can trigger at least fourteen separate and redundant authorization checks. If there was a clean separation of authorization and resources access then only single authorization check would be required for this call. So, is the price of the extra web service request to get an access token less than the price of the fourteen redundant authorization checks?
Decoupling authorization from all Synapse service calls would be a monuments task. We might want to consider a path where we support a hybrid approach and slowly transition to the OAuth 2.0 Protocol Flow.
OAuth Client Types
OAuth 2.0 defines two client types. A client's type determines what a client is allowed to do. Synapse, the client types are assigned as follows:
...
- 4.1. Authorization Code Grant - Supports authorization by confidential web clients such as www.synapse.org (see: PLFM-4590).
- 4.2. Implicit Grant - Supports authorization by public (3rd party) web clients (see: PLFM-4591).
- 4.3. Resource Owner Password Credentials Grant - Supports authorization by confidential non-web clients using resource owners credentials (see: PLFM-4592).
- 4.4. Client Credentials Grant - Supports access by a trusted client using the client's credentials and not the resource owner's credentials (see PLFM-4593). Examples in Synapse would be CloudMailIn (when sending an email via a web request) and the Synapse Docker registry (when sending event notifications).
Note: Both 4.1 and 4.2 requires the client to have a web page that the authorization server can redirect a browser to upon success.
...