0

let's say I would like to create a service like eToro that allows people to trade stocks but with their own brokers. If I do it just for me, it's pretty straightforward:

  1. create logic that replicates someone's trades (or from my own instructions)
  2. use my API keys to get the best price with my brokers and trade

Now if I want to share this with people I don't know, and who are not technical, the minimum I would need from them is their API key to trade "for them" (let's imagine we put all the legal stuff aside with waivers etc...). How could I, technically do that? Below are my concerns:

  • if I store the keys myself, I could be hacked which brings liability
  • if I store the keys myself, I could use it for my own benefit (not the intention but you know what I mean)

so I am looking for, and haven't found yet, a service or a design pattern that would allow me to mitigate that, do you know what that could be?

What I had in mind:

  • a third party like 1Password, but better, as I need to remove the need to validate the unlock AND sees the passwords (the service is automated)
  • or a technical approach like OAuth but where I can guarantee that I can't decipher the message (whereas in my case if I get the public key only, than the user would need to use manually the private key all the time, so no automation or if I have public + private, then I could decipher the message and get the API key...)

Does this makes sense? Thanks for your help!

3

You can't use a shared secret such as a password without knowing it. And when you know the shared secret, it's impossible to ensure that you will only use it for legitimate purposes.

What you are trying to do is to interact with a third party on behalf of the user. A shared secret like a password or API key is problematic because you would be directly impersonating the user. From the perspective of the third party, there would be no difference between you and the real user. This also means you will have the same access as the real user, and could do stuff the user doesn't want you to do. Note that the only way to revoke your access would be to change the shared secret. This kind of problem is related to confused deputy problems.

A trivial solution is to avoid storing the keys “yourself”. E.g. if all actions are made through an app, the app can store the credentials securely, without ever having to send them to your servers. While this limits what a service can do (e.g. regarding actions in the background when the user's device is offline), keeping secrets local is often the best solution with regards to privacy and security.

The more general solution is something more like a capability-based security mechanism. Instead of impersonating the user, we need a mechanism that ensures that all actions have been authorized by the user. OAuth is such a mechanism, where the user instructs the third party that you are allowed to take certain actions on the user's behalf. You no longer store any user credentials, but merely a token issued by the third party. Since the third party can distinguish between the real user and you as an agent of the user, it is also possible for the third party to later revoke your access.

The limitation of such approaches is that it depends on the third party offering such APIs for delegated authorization. It is against the business interests of a broker to allow access through a third party. Thus, using the user's actual credentials and using scraping techniques might be the only viable choice in practice. However, there are some laws such as the EU Payment Services Directive 2 that try to increase interoperability and Open Banking.

1
  • thanks a lot for the detailed answer! ok at least we are aligned. It's a bit frustrating haha, I will try to either [a] create something local they would have to run on their own server (not optimal + I need to anyway send something to my server to bill them so that could also be a backdoor) or [b] centralised service and they provide API keys with limitations... – ibox Mar 18 at 21:16

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.