I have the following use case:

• I want to write a desktop application that makes use of a third-party API (e.g. Dropbox)
• This API requires an access_token to be sent to the server with each request.
• This token gets generated on behalf of the user and my application using an OAuth2 authentication flow, which the user performs on my website.

Now, normally I would pass the generated access_token to the desktop application, where it can be used to make calls to the API. However, since the access_token is stored on the user's computer, he would be able to extract and misuse it for purposes not intended by the application (e.g. exceeding the API rate limit or performing malicious requests).

To resolve this, I could of course tunnel all the API traffic through my own server backend and thus avoid providing the user with the access_token. However, this would create large additional cost and would be a security risk for the client since his data would pass through an additional third-party service before going to the API server.

Is there any other way to keep the client from being able to retrieve the access_token, while still allowing him to use it in order to make requests to the API server?

I read about TCP connection passing, which would allow me to create a connection to the API server on my backend using the access token and then hand over that connection to the client, but this technique seems rather experimental and is probably not production-ready.

Another way would be to use asymmetric cryptography to somehow encrypt the access_token together with the URL on the backend server and let the client transfer this pre-encrypted data to the API server, but again I have no idea how to implement this using SSL.

Any ideas?

Edit:

I have thought about the problem and I think I have a solution, which would require a new API endpoint though and thus would not solve the initial problem:

http://www.andreas-dewes.de/en/2015/securing-api-calls-made-on-behalf-of-a-user-from-an-untrusted-environment/