Handle authentication callback

[CodedOre]

OAuth allows to hand the access token over to an redirect url, which can then be automatically handled by the application.

This is something I would like to include, as it would make the authentication more streamlined (removing the necessity to copy paste the auth code), and also because as of now Twitter's OAuth 2.0 process does not provide an "out-of-band"-option.

It should be possible to include, as we can assign our application an url-scheme (like cawbird://), which would lead to an url of this scheme to be called by the application. I've done some initial work at the auth_callback branch, but there are two big issues that need to be resolved:

• My idea of using a signal to sending the auth code to BrowserPage is not working for some reason
• Unlike when called from the command line, it does not seem that a link from the browser is actually calling the open instance of the application, when it should do it (but may be an issue with my sandboxed flatpaks).

[IBBoard]

Will that work? I always assumed that the OAuth callback was done from the server - e.g. see the diagram on https://blog.codecentric.de/en/2020/05/paypal-integration-with-react-native/ where the "webhook API event notification" is done asynchronously from the client.

[IBBoard]

Also, I've always been slightly averse to the in-client option on the basis of 1) there was a time that the Twitter instructions explicitly told you not to do it because of the risk of dodgy apps snooping on passwords (which is what OAuth is meant to avoid!) and 2) my passwords are in my browser, and I'm already logged in on my browser, so using your own browser is going to be inconvenient for me as a user because none of my existing authentication and passwords are there.

[CodedOre]

The method with setting a custom url schema and using this as an redirect url does work, I've tested this already.

We also still open the browser the user has set, it's just that after authenticating Twitter or Mastodon tells the browser to open cawbird://authenticate, which is then redirected back to Cawbird, so we can circumvent to implement a browser in the app.

[IBBoard]

Okay, that's cool 🙂 Hopefully there's a fall-back position for "and if the message didn't get back (because your protocol handlers aren't in place etc) then here's a code"

[CodedOre]

Hopefully there's a fall-back position for "and if the message didn't get back (because your protocol handlers aren't in place etc) then here's a code"

Just something we need to take into account, but as of now Twitter's OAuth 2.0 implementation does not provide an "Out-Of-Band" redirect, so Twitter itself does not offer the user to copy the code...

As of now I redirect to example.com (so you can copy the code from the URL-parameter), but we might need to put up an site that retrieves the auth code and offer it to the user so he can paste it into Cawbird...

[IBBoard]

Reading the docs (and the RFCs that they link to), is it because of this section?

In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code is identical to the redirection URI provided when exchanging the authorization code for an access token. The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. If a redirection URI is provided in the request, the authorization server MUST validate it against the registered value.

https://datatracker.ietf.org/doc/html/rfc6749#section-10.6

We could host something on the Cawbird site, but it still feels like it's less secure for our use case, because we're funnelling everything through a site that I control rather than doing it purely on the individual's device!

[CodedOre]

Well yes, it could be considered less secure, but I don't see another option for allowing a fall-back when using Twitter OAuth 2.0 until they provide an "Out-of-Band" solution...

[CodedOre]

So, the authentication callback is included in the main branch.

I'll keep this open for now, as the fallback to code is not included yet...

[CodedOre]

This can now be closed, we have an fallback.