I'm writing a broker plugin for an API that authenticates users with OAuth 2.0. Part of this spec is that the application should have a client ID and client secret and the secret in particular should never be disclosed to the user. The secret is needed for initial authentication and for token refreshing.

This means that for Zorro to support this broker, a web service to authenticate users and refresh their tokens would need to be built (by me) and hosted by Zorro.

Is this something that the Zorro team would accept? The current broker plugins don't appear to require any such service so I thought it worth asking.

What broker is that?

Technically it's not a broker. Spotware, the guys behind cTrader, have an open API, (Spotware Connect) that gives you access to any account you have linked to your cTID, which can be from any broker that supports cTrader (IC Markets, FxPro, Pepperstone and Tradersway to name a few).

I've got a decent chunk of the work done through a blob of Qt code for the API and Python for the OAuth server but where to put the OAuth server has me wondering if this will work out.

I am not familiar with OAuth, but if it runs under Linux/Apache we can certainly give it some server space. I only do not really understand why an API plugin needs its own server. When Spotware uses OAuth for their API, then either they or their supported brokers must anyway provide an OAuth server for their clients, or not?

Great, I should be able to get something working then. It'll likely be a Python script.

The basic reason you need a server is that the API wants to control which applications can access its services as well as which users. The way OAuth does this is by giving the application developer a secret, which must be kept from the user. If the secret could be embedded in the application we wouldn't have this problem but also, a user could extract the secret and use it in their own, unauthorized application, which the API developer is trying to prevent.

It might help to know that the OAuth mechanism offered by Spotware is usually intended for web applications. If you have a website that connects to the Facebook API for example, you'd use a similar authentication mechanism (in fact Facebook and Google use OAuth as well). In this case, all the code that interacts with the API is already running on a server under the control of the developer so this isn't really a problem. You can see that the existing Connect API clients (https://www.spotware.com/partners/open-api-partners) are all web based as well.

Spotware and the brokers don't need OAuth servers because they can use internal APIs. OAuth is only for external developers and it's handled entirely by Spotware, which proxies things through to the brokers.

I'm wondering if you've had success in making this happen?