@harsha89, @surangak and I are planning to develop an module that provides capabilities of OAuth client besides being able to act as an OAuth Server this summer. We are well versed on the design the OAuth server, and with the help of discussions and hopefully a design forum we could finalize a way for module developers to easily extend this OAuth module and utilize the OAuth client services it exposes.
Currently we have thought of 2 ways of exposing the OAuth client to module developers:
Generic Client Approach: One involves writing a Generic OAuth client which can then be extended by module developers whenever they want to connect to an OAuth server. The configuration details for connecting to the server are set up in a configuration (XML or annotation based) file.
Interface Per Server Approach: The second approach involves a providing ‘One interface per OAuth Server’ and module developers would implement the interface depending on the OAuth server they are connecting to, as done at @harsha89’s place of work.
An upside of Interface per OAuth server approach is that module developers would need to go through very little documentation (besides the API docs of the OAuth server) as most of the endpoint settings are parameters would be implicitly provided.
A downside could be that if the ‘Interface’ for the requested OAuth Server is not available, module developers might have to wait until it is released.
As a downside of Generic Client Approach, the OAuth server may redirect to a location that is out of control of the OAuth Client API. I feel, we could use Interceptors to forward the response back to the Oauth Client API.
Please share your thoughts and help figure out the best way to proceed.
Possible Advantages of having an OAuth Client :
This would enable our modules/services to connect and authenticate with other external OAuth servers to retrieve information.
Allowing module developers to plug-in both, OAuth Authentication and Resource Servers and OAuth client capabilities would help create information chains. For example, if the FHIR module does have the requested resource, it could use the OAuth 2 client to make OAuth requests to fetch resource from server that has it.
@burke, @darius, @wyclif, and @dkayiwa discussed on the previous design forums on Web Framework that we need REST API’s that do more than just CRUD. Consider that a request is made to a web services module that it does not currently support (non-CRUD). Also consider that there exists another module X that handles such non-CRUD requests. In such a scenario, module developers could utilize the OAuth 2 client and OAuth 2 server APIs to bounce around the request (internally) securely until it reaches the module that can handle the request. On the top level perspective, it could somehow lead to unification of the available web services APIs.