Hacker News Reader

Comment by lathiat | Hacker News Reader

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.

View on HN

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.

> You can then capture the auth code from the redirect just fine.

Not when you don't have an 'official' redirect URL.

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.

Typically if you farm the job out to a browser, per the discussion, then you don't have control over the client.

I took it to mean that they render the login page in a web view still controlled by their app

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

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.

Reply on news.ycombinator.com