>What happened to sending my login info over an HTTPS connection in the background and getting a session token back? I guess that's too simple for Google.
Not exposing an HTTP endpoint that easily lets you check if a Google account with said credentials exists (because it has to work from anywhere) and not maintaining an API that supports all the weird edge cases to logging in to Google (2FA, showing notices, locked out accounts, requiring additional authentication).
You essentially want this mess with application specific passwords back?
There are good, sane, safe ways to hold login credentials. Instead of those ways, Google has picked one that is incredibly inconvenient, and with opening a server on your machine, also opens a new attack surface... I hope they deviated from their aweful coding practices and made the server right...
Sure the interface could be tweaked a little by maybe offering to select which browser to login with or othering the user a “copy sign in link to clipboard” button or something for few people using multiple browser slash containers to keep there accounts separated.
As for the localhost server listening for the code from oauth, it only needs to run for the duration of processing the first login (if you are going to use a keep signed in feature) reducing the window anyone could attack the server. It doesn’t need to punch a hole in your nat, it just needs to bind to localhost instead of your network card so only processes running locally could access the server during the process.
Using a state field could remove any csrf attack surface.
All the server should be receiving in this case is a single use code which can be exchanged for an access token to use the account depending on the scope you have defined during to login process. The data in transit it’s still encrypted all the way back to your browser. It’s only after you have successfully logged in with the auth site send you a redirect header so your browser does the final step of passing the code to the application.
If you captured the code in the redirect you would have to use the code before the application could and if you managed that the application can not use the code to the user in asking the user to log in again, if the user is able to successfully login to the application then your access token will probably be revoked once it’s regenerated when the application exchanges the code it got from the successful login for a account bearer token.
Considering all this I would say it would be easier to just intercept the access token over the network, the application memory or from where ever the application stores it for its next use (it’s keep me signed in functionality) which could be exploited from any other locally running application on your system.
I don’t see how this is any less secure than sending the users password over the wire from your application, having to dead with any 2fa the user has.
Long story short: It's either a really badly written Electron app or no Electron app (well, still obviously not written for 2018).
Badly coded apps (web pages or what have you) are unfortunately the norm in todays society, not the exception. Release now, fix later (if ever).
I often think about this when my boss or clients wants me to rush things (i.e. skip testing, refactoring, write spaghetti code etc). Maybe that will save them money in the short term. But if you look at it from a larger scale, in the long term and also all the other people it will affect, i'm not sure it will actually be cheaper for society as a whole. You can imagine the butterfly effects it will have, and when everyone does it. It's mentality i wish would go away quickly.
... in keeping with Google's disassociative identity in chat apps. It's seriously now worse than Microsoft and syncing applications.
