but on top of that, it just makes things harder to use. and so the site which provides an api that just works, as opposed to one which (in practice) allows you to queue up actions to do later on the site, is going to fail. easy to cite twitter’s success, even though they don’t support any kind of secure three-legged auth.

we’re going to have to always (for the time being, until computers are magical) rely on the user anyway - if they install random binaries then they’re open to cookie stealing and spoofing anyway, so APIs are moot. so the confirmation-before-issuing-user-tokens seems the correct approach (ignoring that flickr’s has been broken lately *cough*).

In the case of single purpose, trusted origin installed software like the Flickr Uploadr you could make a case that the single most secure option is username-password/ClientLogin over SSL. (we don’t, and we’re comfortable with that choice made for a combination of technological, policy, and customer care issues)

And for the above submitted changeset approach above, when used in a hosted web context sounds like a XSSers dream.

So first, the problem space.

Also, implementing change sets like that would be a total pain in the ass on the server side.

It feels like your frustration is less with delegated auth (which is more secure than basic auth, period), and more with web people who don’t understand security. These people will always exist. Overworked teams who allow logins to the admin site via the normal site login with no VPN or otherwise will also always exist.

In South America, they have phishing attacks too; the difference is that the phishing is done with a gun, your car, and your bank card. So we’re never going to solve all of these problems. It just won’t happen. But we can strive to do better, and we should. Arguing about whether Better is Enough seems counter productive.

That said, it’s important that people understand where the possible attack vectors are with OAuth, and how to guard against them (in this case, don’t trust consumer keys in publicly distributed software as much as you do privately held consumer keys with owners who you can sue). The more writing on this, the better, as long as it’s done in a way that doesn’t throw the baby out with the bath water.

@Richard, as long as you’re sending bits to somebody’s computer it’s fair to assume that they’ll be able to identify whatever information is encoded in there - especially if it’s encoded in an x86 executable Secondly a distributed application binary can never be trusted - at least not without significant OS and hardware support that’s definitely lacking on all the platforms I care to run and are probably lacking in practice on the ones that claim to implemented it. The only solution is to trust users, not software - take a look at my next post.