In another thread we have been advised that to use the conversations API, we need to be using auth code version of OAuth to get a per-user token.
When doing so on the browser side, we want to pass this token from browser to java server in-house, which will then make further calls to the InIn REST API (via java) using the java API.
However, we need to change the authorization token on a per-request basis, however the java API seems to only allow global specification of the java API:
From the java docs: "The consuming applicaiton must complete an OAuth flow to get an access token outside the scope of the SDK. Once an access token is obtained, it should be set on the SDK via Configuration.getDefaultApiClient().setAccessToken(token)."
This is a global setting.
I can construct an ApiClient instance, then set the auth token, then set the ApiClient instance on the API that I wan to use - however I am wondering if the default configuration does any additional config?
In a multi-user server-server environment, is there a common pattern to use for managing per-user auth tokens.
As an aside - it is our strong desire is to allow for client credentials OAuth to allow access to conversations API on a per-user basis, with an appropriate role grant within the console. However our best information today is that this is not possible.
Also - is there a large internal overhead to maintaining a number of ApiClient instances - on the order of the number of users on the system?
In a multi-user server-server environment, is there a common pattern to use for managing per-user auth tokens.
Currently, the only possibility is to construct an ApiClient instance for each user (each token) and then create instances of each API class (like ConversationsApi) for each ApiClient. I do have a task to add overridden methods to accept headers to override the default settings. This would allow you to only keep a map of authorization headers and pass the appropriate one with each API request. I have several other things I'm currently working on, but I'd like to get that implemented in the next couple weeks.
I am wondering if the default configuration does any additional config?
No. It's just a design pattern to make setup easy for the typical use case;
is there a large internal overhead to maintaining a number of ApiClient instances - on the order of the number of users on the system?
The overhead is just memory usage in your application.
As an aside - it is our strong desire is to allow for client credentials OAuth to allow access to conversations API on a per-user basis, with an appropriate role grant within the console. However our best information today is that this is not possible.
This is currently not on the roadmap, but is a continued point of discussion. Would you mind posting your use case in the API Enhancement Requests category and include a description of why using the existing OAuth flows aren't suitable for your application?