Support authorization for Connectors through OAuth2

[hlxid]

Description

Currently each user has to manually create tokens in some cases also applications at each service they want to use which isn't that user friendly and in my opinion in long-term we need a easier way..
I've thinking about using OAuth2 in the gui to make the connecting to other services easier, but I never actually really used OAuth myself so I have some questions which could also be just me not understanding OAuth correctly:

• Can we make the client_secret public which is required for the authorization code flow? From quick googling some people say yes and some say no. Most services (e.g. Spotify, StreamElements) only allow full access using the authorization code flow, meaning it would not be really worth implementing only for the implicit code flow. With a public client secret everyone could request authorization in our name, should I be worried about that? In case of twitch both the authorization code and implicit code flow allow access to tokens with the same permissions so there the only security is the registered callback url which brings me to my next question:
• Is a registered localhost callback url problematic? Couldn't a malicious actor could start a local server at the same port when ChatOverflow is not running and open a browser with a oauth request and our localhost callback url. If the user is already logged in the malicous actor could get the token of the user by using the client secret (see above).
• A localhost callback url would also be limited to http and couldn't use https meaning the authorization code passed by the callback could be compromised right?

Another idea is to have a separate website on the codeoverflow.org domain where you also get auth tokens and copy them into the gui. That way we can have the client secret actually secret and the callback url would also be https and not on localhost. This idea however isn't that easy and that elegant as a login button right in the gui.

Comments?

[sebinside]

I would appreciate that, but never really used oauth myself 😅

[molikuner]

Can we make the client_secret public which is required for the authorization code flow?

Yes that's absolutely possible, but it completely removes the security introduced by it. Any application would be able to authenticate itself as chatoverflow.

Is a registered localhost callback url problematic?

I think you answered that question on your own. The only way around that, that I know of, is a user defined client_secret. That way, there can't be any application, that uses the same client_secret and this attack would be impossible.

A localhost callback url would also be limited to http and couldn't use https meaning the authorization code passed by the callback could be compromised right?

Yes, absolutely. As far as I know, the only way around that, would be to use https locally with a self signed certificate.

A possible solution to have the client_secret really secret:

One downside of that is, that all re-authentication also needs to be done from the chatoverflow.org domain, as the application doesn't know the clientSecret, which means chatoverflow as application would be (partly) depended on a service from chatoverflow.org

The advantage of this solution over directly publishing the client_secret would be that it's not as simple as copy and pasting the client_secret into a malicious application. The attacker would need to call chatoverflow.org and get the callback.

This solution needs to be discussed, especially as it introduces a dependency to chatoverflow.org.

Personal opinion: I would like to see an option where it's possible to use the provided client_secret (either via the flow from above or directly via published client_secret) and overwrite that flow by providing a custom client_secret. This would allow the user to decide between "full oauth2 security" and convenience.

[hlxid]

I kinda like that idea.

This way we can also solve the problem that the gui doesn’t necessarily is hosted at localhost:2400 but can also be at any other port or host by supplying that information to the proxy.

Security wise this solution also has the advantage that we can limit the oauth scopes in the proxy so an attacker can’t request any additional scopes. Still an attackers could do enough damage if they wanted to.

Supplying a custom client_secret (and therefore also a custom client_id) should definitely be an option for independence in case this proxy fails.

This proxy also needs to be hosted somewhere, so that also needs being solved.

[molikuner]

Spotify just added a new authorization flow. This flow would mostly fix these issues:

Can we make the client_secret public which is required for the authorization code flow?

No need for the clientSecret anymore.

Is a registered localhost callback url problematic?

At least partially this issue still exists. There is always the possibility of implementing the authorization flow manually. There is no way of prohibiting this in an open source client. But this authorization flow wouldn't be as vulnerable as the other authorization code flow anymore, since the callback doesn't contain the access token.

A localhost callback url would also be limited to http and couldn't use https meaning the authorization code passed by the callback could be compromised right?

This issue is fixed, since the callback is just used to return whether or not the request was allowed. If so, the application already has a key to request via https POST the token. That way the actual key will be transmitted encrypted.

[hlxid]

Thanks for the follow up @molikuner! Created a issue about this at nodecg-io at codeoverflow-org/nodecg-io#38 as ChatOverflow is dead and nodecg-io is the replacement for it.