4

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/

  • SSL should not be used by anyone, TLS 1.0 and later should be deployed by all services. – rook Feb 16 '15 at 14:54
2

Giving the desktop client the keys to the kingdom is by definition a violation of CWE-602: Client-side enforcement of server-side security. Any piece of software running on an attacker's machine cannot be trusted.

There needs to be an intermediary API, a web service that you control, and provides the ability to enforce user-based access control to a communal resource (files on DropBox).

You may also want to read the DropBox Terms and Conditions , which forbids resale of their service.

  • I think this has nothing to do with reselling their service, it is about restricting the type of API calls the user can make with an access_token that is stored on his computer. – ThePhysicist Feb 16 '15 at 15:41
  • @ThePhysicist ok, you still can't give the attacker the access_token, which means you can't send it to the desktop client, this must never happen. Crypto isn't magic, you can't hide in plain sight. – rook Feb 16 '15 at 15:44
  • Yes I know that, that's the whole point of my question. Sorry if it was unclear, but I'm looking for a way to grant the user API access without providing him with the access token. – ThePhysicist Feb 16 '15 at 16:04
  • 1
    @ThePhysicist and the answer was clearly provided. In order to restrict access, you need something you control. – rook Feb 16 '15 at 16:06
1

In your case, there really is no avoiding policing the API use yourself. Since the API is assigned to (you) the developer you will need to host some sort of server to provide access control to dropboxes API. Read Drop Boxe's terms of service carefully.

  • Well the problem I described is that I have no way to police the API use myself, since the user can make API calls using the access_token from his computer without my knowledge. – ThePhysicist Feb 16 '15 at 15:40
  • As in host a server, and make people tunnel though that. – baordog Feb 16 '15 at 15:41
  • I understand that, but funneling all the traffic through my own server is a security risk and not scalable, as I pointed out in my question. – ThePhysicist Feb 16 '15 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.