The oaith spec requires a callback URL to work and usually that url has to be “registered”/authorised with the server. Most of these apps are using the api “unofficially” and the only way to do that is with browser automation. Otherwise once the login is complete the redirect with the authorised token won’t get to your app - it will go to the official website or app.
They then pluck the authorised token out of the cookie store.
Not really. The libraries should do what my own app does: render the vendor website (Tesla or whoever) in a browser window and let the user enter their creds securely. You can then capture the auth code from the redirect just fine.
There are right and wrong ways to do OAuth both in server and client, and many, many implementations do it wrong.
That works for GUI apps I agree though doesn’t work for server side stuff. Which I suspect the software the OP meant is. But yes better than storing the password if you are on a desktop.
Right, so my app is an electron app, and you can hook into the redirect. It’s still a little bit hacking the flow but not as bad as full browser automation
If you control the client, you can. Because when you get the redirect response, you then take the auth code that is included there, and you don’t follow the redirect.
Then you send the auth code to your backend instead.
They then pluck the authorised token out of the cookie store.