4 ms·
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 “uno
by lathiat 3y ago
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.
- davedx 3y agoNot 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.
- randomdata 3y ago> You can then capture the auth code from the redirect just fine. Not when you don't have an 'official' redirect URL.
- codetrotter 3y agoIf 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.
- randomdata 3y agoTypically if you farm the job out to a browser, per the discussion, then you don't have control over the client.
- codetrotter 3y agoI took it to mean that they render the login page in a web view still controlled by their app
- davedx 3y agoRight, 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
- lathiat 3y agoThat 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.