OAuth client design

@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:

  1. 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.

  2. 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 :slight_smile: and help figure out the best way to proceed.

Possible Advantages of having an OAuth Client :

  1. This would enable our modules/services to connect and authenticate with other external OAuth servers to retrieve information.

  2. 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.

  3. @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.

2 Likes

Great explanations @maany. Definitely we need to figure out client design and need to focus on the OAuth server implementation which will be the primary goal of the project. :slight_smile:

As I mentioned earlier, having a generic client for all oauth providers is some what unrealistic.

Token endpoints provided by OAuth servers have both browser redirection and direct token generation endpoints.

If I explained more, you can use Twitter as OAuth provider, which your application first requests for token for Twitter API which causes a redirect to Twitter’s site to provide your username and password, which will redirect back to your application with the token which highlights the browser based approach.

Some OAuth providers takes application key and secret along with credentials to the OAuth server and returns token in JSON format which there is no browser. You may write client for this kind of scenario and having a client which involves browser redirection cause things complex. Which will take time and we will be at risk of focusing on our primary goal.

Please finalized the things with the client soon. Maybe we can discuss in tomorrow call and fished on client things. :wink:

Perhaps I’m being obtuse here, but would you mind taking a step back and giving the big picture here?

Why are we trying to do this? What (end-user-focused) business use case are we going to solve?

1 Like

@darius Sorry for the delayed response. We was first about to write a generic client who can talk to OAuth Provider (may be Twitter, Google) and get us a access token without letting user to handle those complex redirection. Actually there is no standard for API implementations for a OAuth provider. Different vendors have their own implementation to get token for given grant type which makes us complicated to write a generic client.

For example, if user need to use Twitter for FHIR API access through OAuth, with client we can expected to get the token for the user and access the FHIR APIs without much complexity. But I also search more on this and found that getting a token is a responsibility of a application Supporting for particular OAuth provider is a responsibility of FHIR. :).

So we now do our main focus on design our OAuth provider implementation, During the implementation we may look at possibility of writing a some generic OAuth client. Oauth also associated with both browser based redirection and non browser based token retrieval functions.

Hopefully @maany will explain our current progress in tomorrow design call.

Thanks, Harsha

1 Like