Comment 2 for bug 387297

I'm not 100% sure by what you mean by "use the web auth", but I doubt that would be any more secure. You'd still have a random program asking for the user's Launchpad password.

I had a long talk with flacoste and mars about this. Here is the problem in a nutshell.

1. The OAuth protocol does not define how to acquire the access tokens. It happens out of band. So any way of getting the tokens is in compliance with the protocol, including manage-credentials.

2. But, if you use an untrusted client to acquire the access tokens, the untrusted client might sniff whatever credentials you use to get the access tokens. So manage-credentials trains users in bad security practice.

3. The only trusted Launchpad client is the web browser. You already type in your Launchpad password to your web browser all the time, so it's presumed to be safe. So when it's time to enter your Launchpad password, launchpadlib delegates to the web browser.

4. From a UI perspective the browser step is not great. It removes control from the application and requires the user to context-switch. The authors of end-user applications don't like or even understand this step. Here's one Leonov developer (http://www.sourcecode.de/content/some-internals):

"For example, the login and approval of Launchpadlib was a bit "strange" at the time when I looked at lplib. So I went and wrote a little wrapper class, which does the authentication and authorization (approval) automatically, without the need of a browser or interactive methods."

It was "strange", so he worked around it by having his users tell him their Launchpad passwords--exactly the thing we designed this system to avoid.

5. This is a common problem. It's happened at least twice for Launchpad: once for the Leonov desktop client and once for manage-credentials (plus anyone who uses manage-credentials this way). The Twitter web service supports OAuth with a system similar to ours, yet pretty much every Twitter client asks for your Twitter password directly.

Our tenative solution is to create trusted clients other than the web browser. We'll create a client program for command-line applications and ask people who know GTK and Qt programming to create analogous client programs for those toolkits. These programs will be similar to pinentry and they will be packaged with launchpadlib.

There are a couple problems with this. First, it doesn't scale. These client programs will only work for Launchpad's OAuth credential workflow, and it locks that workflow in place semi-permanently. That's another advantage of using the web browser--it's a general client that will present whatever interface the server defines.

Second, these client programs will be a lot easier to fake than a web browser. The command-line program, in particular, is just going to be some text on stdout. It would be trivial to hack up a fake version of the trusted client program and sniff users' passwords. So we're effectively giving up on the "trusted client" idea and falling back to the position that you "trust" any application you've installed on your system. The best we can do is provide some easy-to-use clients for various frameworks so that people don't write their own one-off clients.

For web-based applications, you're already in the web browser, so there's no context switch. There's no
reason to trust an application running on a foreign computer, and no reason to write a web application that asks for someone's Launchpad password, rather than redirecting them to Launchpad to log in.